conversations in the cloud
One of the issues of a loosely interconnected network of micro-messages is how to handle conversation threads (aka @replies).
On Twitter, it is easy since that is a centralized service. It started as an ad hoc @ symbol in front of usernames which is how it is often done elsewhere such as IRC. Twitter formalized the functionality and enhanced it with inReplyTo so if a reply link is clicked (as opposed to just arbitrarily typing @username) the thread can be properly constructed so others can view it in context. In other discussion systems like Blogs and Forums, it’s obviously baked into the software. Not so in the decentralized rssCloud network.
Let me also point out that their will be variations to what is published and how it is published with support for rssCloud. The initial focus for me and I think others is on microblogging. These posts can technically be created from any software (like WordPress, Drupal, TypePad etc) or from any other system that generates an RSS feed (ie. any twitter clone or open microblogging software such as laconica etc) which all can contain a reference to an rssCloud hub. That means, it is feasible that a comment system will already exist on a permalink page for each post. This can be considered the answer to my question. But I want to look at this from a more raw perspective. One that does not yet involve such aforementioned publishing software with comment systems and permalinks. I want to focus solely on the RSS feed as the only source of content. In fact, this is how my prototype currently works at http://nudg.es. It is an email based RSS feed generator with support for rssCloud. I want to think about how two such feeds can reference each other’s items with comment text.
So let’s setup a scenario. Two people have their rssCloud feeds loaded with several short messages. It would be nice to rely on using just the web to view a nice direct output of the feed using XSLT (see nudg.es feeds in Firefox) but being unreliable across all browsers, let’s assume the feed is being viewed in a specialized application such as Google Reader or some other RSS aggregator software. I see a post that I want to reply to in the rssCloud feed. Let’s say the feed url is http://myrsscloudfeeds.org/johnsmith/mobile. It’s a short message with a photo attached (enclosure) sent from John Smith’s phone. I like the picture and want to comment on it from my RSS aggregator. How do i do it? How do I associate my short message reply to John’s short message?
So to reiterate, all we have is a feed inside something like Google Reader being read by someone who wants to reply to one of the feed items. How do we get it done? One curious thought I have had involves the RSS channel sub-element called “textInput”. Here are reference links:
http://cyber.law.harvard.edu/rss/rss.html#lttextinputgtSubelementOfLtchannelgt
http://www.w3schools.com/rss/rss_tag_textinput.asp
As it states, it is basically support for a simple form submission. Dave Winer noted at the time of writing (~2001) the following:
The purpose of the element is something of a mystery. You can use it to specify a search engine box. Or to allow a reader to provide feedback. Most aggregators ignore it.
Can this be used for handling conversations across the rssCloud network? Possibly. Let’s delve into it’s potential for a minute.
First we need to keep in mind that this is a CHANNEL sub-element so it’s not associated with each ITEM. Originally, I thought that killed the idea of using this for decentralized @replies but then i felt that…. if a new breed of RSS aggregators need to sprout in order to properly support stuff like rssCloud, then it’s ok to expect these aggregators to support anything that is deemed useful and certainly stuff that is part of the RSS 2.0 spec. So if an aggregator, such as Dave’s own River2, can support the “mysterious” textInput element then things could get interesting. Here is what I am thinking…..
An rssCloud feed can define a base form handler url in the channel textInput element. The form handler would likely be a self-hosted open source script but could also use a cloud service where the script is hosted (another discussion). The form could/should be aware of the feed info and could/should possibly also be aware of the subscriber info (ie. rss url, username etc). Again, this depends on how smart the agregator software is (ie. Google Reader, River2, Web UI etc). Since this is a base url, the script would need some required data passed to it so that it knows what feed/item this comment/reply is referring to. The form handler url would need to be appended with parameters such as the item guid or some other means to identify the item that is being replied to. So, the aggregator would take the base url specified in the feed’s textInput link element and use that as part of a “reply” feature that would likely be exposed in the UI as a “reply” hyperlink next to each feed item. The link would be appended with the item guid + feed channel link, author, managingEditor or other combination of feed data to make sure it is a unique global identifier.
If the subscriber wants to add a comment but does not have their own rssCloud feed/blog then they can login to twitter or facebook or some other preferred centralized service to post the reply. If the subscriber has their own rssCloud feed then they can opt to post the reply to their feed and have it be associated to another feed’s item. It can possibly use the RSS “comments” element to point back to the feed item. How exactly that url would be handled and formatted needs to be discussed but let’s focus on one thing at a time.
Their are other details and of course plenty of discourse to be had around these approaches. But the key is to not have to rely on a centralized service for cross-feed conversations and to also not mandate that certain blogging/CMS software be used in order to achieve this commenting system.
The only software that should be used is a simple form handler script that adheres to RSS standards and facilitates the reply posts accordingly. This could be a role for the rssCloud hubs with the option of self-hosting the form handler app (maybe as a failover/fallback etc.).
What other ideas do people have on this topic?
Please punch holes as I know this has only touched on the surface.
Thanks.
Sull
Related posts:
Trackbacks 5:33 AM on February 6, 2012 Permalink |
Brian Hendrickson 1:37 AM on September 9, 2010 Permalink |
Hey I never chimed in here! Just like me. So, yeah, I’ve come back and read this post a bunch of times over the past year, remembering your idea for in.rp.ly/to and trying to figure out federated comments. I’ve been using textInput (both mailto: and http:) to create a salmon-like upstream flow for replies, while also using StatusNet’s conversation metadata and Activity Strea.ms semantics. before i explain my solution I wanted to get my http://openappstore.com project ready — it’s a place for open source apps [with each app having separate ipad, iphone and desktop versions all-in-one] pretty interesting
It’s working ok now so I should be able to publish my SWAT0 flow this weekend. — Brian
sull 1:45 AM on September 9, 2010 Permalink |
wow, that all sounds sweet. def keep me looped on these developments. thnx for the comment.
Andrew Davis 12:12 AM on September 9, 2010 Permalink |
It may be beneficial to compare nudg.es to the salmon protocol
http://www.salmon-protocol.org/
I’ll be thinking on it. We will chat at #ovc10
sull 1:11 AM on August 28, 2009 Permalink |
dealing with fragmented discussion….. just wanted to include a reply to dave winer over on friendfeed:
Dave Winer:
i replied:
sull 3:20 AM on August 26, 2009 Permalink |
i nudged Brian Hendrickson (http://twitter.com/brianjesse) about this topic and suggested the creation of in.rp.ly/to/
He’ll chime in with valuable thoughts.
Jeremy 12:00 AM on August 26, 2009 Permalink |
I had a lot typed up on this from the other night when I was pondering the same question, but then I just realized… if considering only rssCloud, Dave added a new namespace – http://rsscloud.org/namespace.html – an “rssCloud:item” element that has an identical structure to “item” elements, allowing “you to build a hierarchy”.
This makes it a lot less complicated than I was thinking earlier. I would suggest still using the “comments” element to direct users to leave comments directly with the publisher.
It may be a little more difficult when replying or retweeting into your own feed instead of going back to the original source. Although, when all said and done it should work somewhat like a trackback. The key question is what each side decides to do with that data and how they publish it into their feeds.
sull 12:34 AM on August 26, 2009 Permalink |
That’s true, we could invent new stuff in this namespace to do the things we need to do. But at the same time, it’s kind of fun trying to fit new functionality into a very old spec
And you know… a lot of it is feasible. Dave had a solid vision back when he worked on this spec and it would be cool to see some of the underused (or never used) RSS elements come to fruition with the rssCloud project.
I hope to see more discussion on this. Might be a good topic for your next blog post. Great work on MyStatusCloud.com!
Anon 8:41 PM on August 25, 2009 Permalink |
So basically, if Bob wants to reply to Alice:
1) Bob publishes a reply in his feed
- Does he reference Alice’s username/post ID in the item?
2) Bob pings the server defined in Alice’s textInput element with his username and the item ID of his reply.
- How should Alice store a reference to Bob’s reply in her feed?
Am I on the same page as you?
sull 12:29 AM on August 26, 2009 Permalink |
1) maybe by using the comment element, the proper feed item guid can be used. the guid could be a url representing that feed item. that url should naturally contain the feed url and some global user id (if different than feed url).
2) I think maybe the aggregator should be the handler of this “comment feed” that is created where all your replies are stored. then the aggregator could provide some UI to view all these replies/mentions just like the twitter UI does. So, it would just be another local or remote RSS feed.