What should an open protocol look like?
Since this conversation has gone kinda dead (and even the wiki, supposedly the center of attention, hasn't been updated recently), let's see about trying to foment some useful, if slightly tangential, conversation
( Read more... )
Second, respect ownership, and make it easy for people to back up/export their entire posting history, and make it as tranparent an archive as possible, say, a zip file of date/timestamped text files.
Thirdly, Open APIs are good, and if you're starting from zero, you might want to look at OpenSocial, and XML-RPC to see the sorts of choices they've made with regards to the data in/data out functionalities people have wanted (push, pull, post, export, pingback, etc.) I don't know much here myself, as I'm tool wielder in this field, not a tool-builder.
Reply
Definitely a sensible option for the "pull" side of the equation. Although the relationship of RSS and threading isn't clear to me yet -- the multi-dimensional aspect of the data needs to be clearer. All the RSS applications I can think of so far are essentially one-dimensional: a linear stream of messages. Do you know how to build a threaded structure and updates into that?
How about push? I can see a lot of applications (*especially* anything like CommYou), where you want prompt, efficient distribution of new data, so a push model would be very useful. I'm toying with the idea of seeing whether something could be built on XMPP/Jabber -- that seems to be where the momentum is right now.
One of my biggest beefs with LJ is that it is impossible to get an RSS feed of my friends page. I can get individual feeds for individuals, but that doesn't include locked posts, and throws away all the useful social mangement tools in LJ.
Yep. This is a common problem, far as I can tell: relatively few systems marry RSS and authentication. Indeed, I'm not sure quite how you unify them, although I assume that there is a solution. Authentication is, IMO, absolutely key to building a proper conversation-distribution system.
Second, respect ownership, and make it easy for people to back up/export their entire posting history, and make it as tranparent an archive as possible, say, a zip file of date/timestamped text files.
I think that's more a policy issue than a protocol one, but I agree with the principle. My current guess is that CommYou is going to allow you to get at all of your data, although the *frequency* of that access may be partly a member/non-member thing. (That is, anybody can back up their conversations, but if you really want to hammer the servers regularly, you need to buy a membership.)
Thirdly, Open APIs are good, and if you're starting from zero, you might want to look at OpenSocial, and XML-RPC to see the sorts of choices they've made with regards to the data in/data out functionalities people have wanted (push, pull, post, export, pingback, etc.) I don't know much here myself, as I'm tool wielder in this field, not a tool-builder.
Hmm. Interesting point. Certainly this space relates to OpenSocial, although the relationship's a little fuzzy. (OpenSocial is really an app-construction protocol more than anything else, far as I can tell.) But it is true that it is starting to set expectations, and matching those expectations at the structural levels makes sense...
Reply
Sadly, no. Current systems sometimes do multiple feeds, one for posts, one for comments. But, those tend to throw out context. Atom does have some fields that can bu purposed towards having a relationship between items (category, updated), and of course, is extensible. But just because the feed has the elements doesn't mean the destination can interpret them. May need to insert links right into the textual content, or use twitter's growing '@' reply convention.
How about push?
Well, XML-RPC and Atom both have 'publishing' specs that can be engaged when a post is created to push the data elsewhere (webwise), but XMPP is a good choice, or some other way of connecting it to a realtime communicator that people are likely to have open anyhow. There's also e-mail subscription options.
relatively few systems marry RSS and authentication
There's competing goals here. Much of RSS is used for openness and transparency, but there are plenty of places that do authenticated feeds. I have a couple for paid podcast subscriptions, and there are some for paid news sources as well. These usually generate a unique token which is part of the subscription line, or they use usernames and passwords, but not many RSS readers support authenticated feeds like that. Looking again at Atom (as the latest spec for feeds), they have an authentication element built in. There is definitely more than one way to skin this cat.
Reply
I don't love either option. Links directly in the text tend to lose semantic context. (Although I suppose we could create a microformat for that.) And the @ convention is too coarse-grained. It works for Twitter because that doesn't have real conversation threads, but it breaks down as soon as you try to do any sort of true threading.
Well, XML-RPC and Atom both have 'publishing' specs that can be engaged when a post is created to push the data elsewhere (webwise)
Really? I had no idea Atom had such a thing. I know RSS moderately well, but haven't dug into Atom much. I'll have to look into that.
Looking again at Atom (as the latest spec for feeds), they have an authentication element built in.
Even more interesting. Clearly I need to set aside some time to learn Atom...
Reply
Authentication is in the form of digital signatures and/or encryption, so that element is not for _client_ authentication, is for _publisher_ verification. Although there may be something that can be done with the encryption.
Reply
Leave a comment