Why not ostatus? #4
Comments
|
We originally began by attempting to use and revise the OStatus protocol. These are our main complaints:
We are working on a comparison page that will address OStatus in more detail. |
|
Technically Tent.io didn't have support for those three things (and more) either when it was created. Is it difficult to build on top of ostatus's work? |
|
It's my understanding that since public/private keys are already generated when you use Salmon, private messages in OStatus would be a possibility. Point 2 seems legit, but I'm not sure how often you'd actually want to do that. Three, I'm not sure what you mean. Could you clarify, please? |
|
@krainboltgreene Tent does support all of these features from day 1 (today). We strongly considered Atom, PubSubHubbub, and OStatus before starting Tent. The OStatus spec clearly declares Client APIs, Private messages, syntax, and graphs as out of scope. Because of its reliance on Atom feeds, the protocol would have to be completely reimplemented to support the features mentioned, as @steveklabnik said, it's overcomplicated already. If all you want to do is send public messages out to the world, OStatus works fine and has community support. @steveklabnik In Tent all the server does is provide an API that other apps and servers consume. To implement an rstat.us-like microblogging service, you would write a Tent application that interacts with Tent servers. OStatus doesn't have this distinction and only specifies a limited server communication format. |
|
Leaving everything else in OStatus aside, I think the JSON Activity Streams spec might be helpful for content types, rather than reinventing the wheel and maintaining a list of common types on the tent.io site. You can easily imagine each post being an encapsulated JSON ActivityStreams item. One of the major advantages would be the inherited content types in ActivityStreams: you could have a very specific content type (loaf of bread recipe) that falls back to a generic type (text note) for client apps that don't support it. This would also open the possibility for content compatibility between apps that don't necessarily all support the tent.io protocol. Also definitely worth reaching out to the OStatus community regarding your complaints. These are all things they've been thinking about, and they might have some useful ideas at the very least. |
|
@titanous thanks for clarifying. I think it's really unfortunate that people are building platforms on top of platforms on top of platforms, but I guess we'll all figure it out someday. I'll be reading the spec much more closer later, thanks for putting up with me :) |
|
OStatus cannot have private messaging as the protocol does not manage identity. It also is not concerned with application interaction as it is a communication protocol. Those standards also exist, though, and are used (ALPS, vcard, etc). The creation of another standard only serves to pollute the space, which runs oddly counter to the goals of tent.io. Identity should be detached from service, as it is with something like ostatus. OStatus would have too much privilege if it considered identity this way. The principle of least privilege is used, instead, to encapsulate identity to another protocol (ideally running on another separate server.) A protocol for managing identity is Webfinger. OStatus assumes nothing about keys, identity, etc. That's a good thing. So, we can add things on top of it that can do these things that use existing things phew: Webfinger and PuSH authentication can be used to implement private feeds rather easily: http://blog.romeda.org/2011/03/private-webhooks-private-feeds.html Webfinger and RSA implement private messages. Just sign a salmon notification with your private key and the recipient's public key. You are right, there is no activity for 'private message.' That's not part of ostatus, that'd be part of activity streams if you wanted it to be an activity like other social things. What do you do? Hmm. Maybe it is out-of-scope for Activity Streams, which seems to be really about public events, which may be why it doesn't exist, so you create a content type for a salmon notification (which is just a signed wrapper around json or xml or something) and you do your thing and everybody that doesn't understand ignores it and every one that does uses it. You get that specification reviewed and published. For point 2, I'm not sure what you mean either. Moving your ostatus server location is trivial if your identity is detached, since that identity contains the relationships, urls, etc. Migration of data requires a notification to the hub and end nodes. OStatus isn't concerned with export of this information as it is a communication protocol and doesn't require you to represent or use the data in any particular way. At any rate, you can pull out the information from a server as a client using http and refollow or do whatever to set-up those relationships again. The hard part is migrating your identity. Which is exactly why it is meant to be separate. It's the internet equivalent to changing your name. And that's not trivial. Basically, I don't think it is enough to really warrant the publishing of competing protocols. I am very weary of any group trying to organize and define all of the protocols. I'm very concerned with the monolithic nature, as in these types of designs, if there is a flaw... it stays forever. It is much harder to be flexible. I do sympathize with your complaints about ostatus. It's a slow moving standard. But it is correct to build a standard such as ostatus that simply works on a subset of communication as a booster to the http protocol flexibility. And then build standards around it, and use them together. I'll end by saying HTTP is a federated protocol, and it doesn't seem out of scope to add anything on top of it. Yet, we need more implementations, not more interfaces. :) |
|
this is a pretty high level comment but I think a great implementation that produces a simple set of federated protocols is a lot more practical than a bikeshedded protocol that is hard to implement. it all depends on the team building the implementation and their willingness to be good "open web citizens" |
|
After reading the spec more thoroughly, I'm not sure how 'inability to move relationships when moving servers/identifiers' is solved here at all. Is this in some draft of the spec that's not public? |
|
Just one point here as I think I indirectly addressed a bunch of this stuff in issue #6. The ability to move relationships isn't something that's easily solved. I'm honestly not sure that data/relationship lock-in is or ever was a problem. To that point: Flickr -> [Facebook] -> Instagram is a migration that loads of people have done relatively painlessly. Relationships: My current network on Flickr in no way represents my current network, because I built it seven years ago. I wish I could just press "reset" and start again (without 'unfollowing' people). Moving to a new network would be the easiest way to do that. Data: Data migration is hard, but federation protocols aren't going to make that easier. Data is rich and complex, and federation will help smooth some of that over, but it will be lossy. If I'm going to move data from one network to another, it's more important that it's not lossy (or that I have some way of saving the bits that will be lost). The easiest way to get there is to just have tools that backup/migrate data. Somedaymaybe. ;-) |
|
Tent API is much better than OStatus. Let's compare:
To summarize, tent is a much cleaner web oriented protocol, leveraging the decentralized nature of the web. One thing that is critical is to not confuse a document and an entity (tempting tho it is). in HTTP you are returned a document, which can have 0 or more data items WITHIN it, delimited by the # character. If tent can grok this element of web standards, it can potentially be a kind of glue to knit all the social nets together. |
|
Much of this boils down to preferences, (of which mine are 'implemented, supported protocols are better than theoretical protocols') but...
Citation, please? I've never heard of this, but I'd like to know about it. |
|
@melvincarvalho @steveklabnik I'd be very curious to understand the context of that statement as well. It's true that a number of the larger contributors to ActivityStreams have taken forever to sign the OWFa, and our (Google's) lawyers requested a very minor change to the spec abstract, but that was only to clarify the scope of the spec. I've not heard of anyone's lawyers requesting substantive changes to any part of the spec. |
|
@willnorris Thanks for the clarification. The impression that I got, from following the lists for multiple years, was that there was a heavy involvement from lawyers, relative to other specs that I follow. I'd prefer not to sightly wander off topic, as my comparison was holistic, rather than addressing one particular point. What I wanted to get across is the Tent protocol has better potential aligned to the Web, than OStatus. We're not all the way there yet, and there's some major pitfalls along the way, but Tent has the potential to be to OStatus, what Git was to SVN. When Linus made git, he started with identifiers, then thought about protocols, that's the key, imno. To a degree it does come down to preference, both SVN and git work, but there are subtle architectural differences. Perhaps Tent is 80% the way to being a first class protocol, but that final 20% is often illusive. Perhaps a short trip down the road to MIT, to chat with Tim, could help. Certainly, for the reasons above, I'm really happy to see this alternative, and the conversation moving forward! |
|
I for one welcome our new JSON overlords On Thu, Aug 23, 2012 at 10:38 AM, melvincarvalho
|
|
I don't get this either..
No one said OStatus is 'done'. Work is ongoing (not as fast as we'd hope but that's life) on privacy. See PuSH 0.4 vor authenticated feeds. Salmon can be used already today for private messages. Etc. I'm sure everyone involved in these specs would love more help and especially people who write code instead of waving hands.
Again, not being there today does not mean it can't be done. However there are many technical hurdles in that one. In Jabber/XMPP for example it was explicitly decided not to support such a feature for performance and security reasons (dig the mailing lists or ask Peter). Instead they've opt for a 'I've moved somewhere else' kind of mode.
If you mean third party app interacting with a node on your behalf, look over to OpenSocial which had wide support back in the days (MySpace, Bebo, etc.). Yes, OStatus is not perfect, and things like Salmon interoperability is a pain that needs to be addressed. But I think that you'll have more chances to succeed by building on top of existing specs (would it be OStatus, or XMPP by the way). On the other hand, by designing your own protocol, you'll have a lot of fun and will learn a lot of interesting things around data formats, distributed architectures, crypto, etc... Thus... do whatever you want and have fun :-) Welcome to the party. |
|
Working with existing standards is way less fun than just building your own. NIH is hard to fight. :/ |
Except when the existing standards are supported by comprehensive, robust, well-documented libraries that have a low enough barrier to entry that you can get them up and running in an afternoon, and an easy-to-use hosted service to test against. IMO. Then it's easier to use those libraries than to build something new - after all, what people really want to do is build the actual app. |
|
It's not NIH if the standard sucked. What we are arguing about is our differing opinion of the suckiness of different standards which ultimately boils down to personal taste. If I were building tent right now then I would ignore sucky standards and use non sucky standards but first and foremost focus on making a compelling product. |
|
It's NIH if your reason that the standard sucked is "personal taste." It's not if you can objectively demonstrate that it doesn't solve your problem, or that it's worth losing compatibility with tons of existing code that already implements the standard. |
|
I can't get past the double negative.. "not not invented here" - so Max, sorry but I read "It's invented here if the standard sucked", and Steve ... "It's invented here if you can objectively demonstrate that it doesn't solve your problem." |
|
https://twitter.com/polotek/status/135449834567106560 If you mapped all the decentralized web standards onto an axis going from less abstract to more abstract you would get things like "use JSON and HTTP for everything" on one end and things like "what is so hard about downloading and using Googles Java server that implements this XML standard" on the other. These are subjective decisions that add or remove amounts of time and energy required to complete something. I am personally quite glad that the Tent team has been so good at listening :) |
|
I fully support the OStatus vision of a federated social web. I do understand there is an advantage to try and get as many people as possible to align to one system. But having followed the list, implementations and libraries for many years, I think it would be fair to say that OStatus has not quite met expectations. Firstly, it's not a standard, in the sense that it's recognized by any standards body (e.g. W3C, IETF, OASIS), it's still in a draft stage, as are many of the various components. It may be some time before it becomes a standard, or may indeed, not make it to that far. Tent on the other hand is using well known practices such as REST, HTTP and JSON which have been approved standards for 1-2 decades. It's putting building blocks together of these mature components in I think logical and sensible ways. You could argue that it's NIH, and that OStatus has adoption, but I dont think even that it the case. Facebook open graph, and linked data are more widely deployed on the web than OStatus, which is an interesting tech in principle, but yet to reach any kind of critical mass, imho. It does come down to personal preference to an extent, but I think it's unfair to criticize a young technology trying to do something innovative, just because it's not doing things the way you want. Good luck to tent and the team, v impressed so far! |
|
I would absolutely support an RFC for OStatus, but it has multiple implementations that are deployed widely, which is one of the first steps towards doing such a thing. JSON has not been a standard for decades. Tent is NOT RESTful. OStatus has adoption in the way that matters: amongst the open standards and data crowd. I have big issues with OStatus, and do not think it's perfect, but you can see how "We want to be open and standard, yet we'll ignore all previous work" makes those of us who have been in this space get a little nervous.
It's not unfair. And I've made very specific, technical criticisms. Tent is not doing anything particularly new, but reimplementing things that existing protocols do already in ways that are significantly less scaleable. Protocol design is hard, and it's different than just building a random app and hoping that people show up and use it. |
|
@steveklabnik I think you may have perhaps misunderstood what tent is (and also maybe some of the other technologies) "API Overview The API is RESTful, using JSON over HTTPS" <-- the first line of http://tent.io/docs "JSON has been a well defined subset of JavaScript (specifically, Standard ECMA-262 3rd Edition—December 1999[4])" <-- http://en.wikipedia.org/wiki/JSON I think you are being unfair to imply tent "random app", it's at least as well thought through as your preferred technology, if not better. It's fine if you want to differ, but please dont belittle a new project trying to innovate. |
|
Yes, but Tent does not follow REST, specifically the hypermedia constraint, which is an integral part of REST. They can say REST all they want, but it's not true. JSON may have been standardized by the ECMA, but JSON itself was RFC 4627, from 2006. A long damn time in Internet Years, but not decades.
This is where we fundamentally disagree. I am not trying to belittle the Tent devs in any way, and I'm sure they've put a lot of effort in. But they really should have consulted with some protocol designers before designing a protocol. |
|
Perhaps they mean RESTy instead of RESTful: Why are there RESTful and non-RESTful APIs mixed up here? Have the developers been too lazy to go REST all the way? Remember, REST is an architectural style that lends itself to certain architectures (such as the CouchDB document API). But it is not a one-size-fits-all. Triggering an event like replication does not make a whole lot of sense in the REST world. It is more like a traditional remote procedure call. And there is nothing wrong with this. We very much believe in the “use the right tool for the job” philosophy, and REST does not fit every job. For support, we refer to Leonard Richardson and Sam Ruby who wrote RESTful Web Services (O’Reilly), as they share our view. (from CouchDB and REST on this page http://guide.couchdb.org/draft/design.html) |
|
Right. It's 'RESTish'. And that's totally fine. But when you're planning on building a protocol that's gonna scale up to (hopefully!) zillions and zillions of users, it's nice to have confidence that those building it are familiar with what exists, so they don't make mistakes like "send one POST request per follower when I update a status." |
|
There is a fine line between that and premature optimization though ("what is so hard about downloading and using Googles Java server that implements this XML standard"). Maybe if Tent presented themselves as "a startup interested in adopting and contributing to practical decentralized web standards" instead of "a new decentralized web standard" then it would be more understandable? |
|
The RESTful JSON protocol issue is a higher level issue outside the scope of tent.io. For modern protocols to be compliant with common tool chains, they need to use the application/json media type. To be REST compliant they need to have a standardized way to say they use a "+json" mediatype, or a standardized way to use profiles. Both of which are rather raw topics at the minute. Tent.io is doing a good job, working in an area which isn't very mature - REST and the current layers of the web aren't perfectly matched to the use cases being handled, and only after multiple people doing what tent.io are doing, can the intersection be standardized and used across multiple projects. So far, I personally thinks it's one of the most well thought out projects in active development - and I say that having a fairly good awareness of many social / federated / decentralized / rww projects; and most web arch level issues. Standardization tends to happen on the back of innovative, active, and long term projects - particularly those which want to be / create a standard, or see a need for a certain standard. It may be wise to foster the standardization side as a W3C community group, and interact with other related CGs, in order to really progress that side of things, and tweak out any bugs. |
|
@titanous I wouldn't do that - tent.io is as RESTful as any other JSON based protocol, and virtually every protocol I've ever seen that claims to be RESTful - even Atom isn't entirely RESTful, nor is HTTP itself, as you'll see if you read the full REST dissertation from Roy T. Fielding. Saying you are RESTful, and being pretty much as RESTful as you reasonably can, is a good thing - remember it's an architectural style, and little more than a goal or set of good practises - not a spec which you are either implement correctly or don't. Or, succinctly, saying something is "RESTful" is an aspirational claim, rather than a badge of conformance. |
|
wow! maybe http://www.w3.org/community/fedsocweb/ should just move to github? ;D |
and others
It's not clear to me how this is actually better than ostatus. This may be just because I've really only skimmed things so far, but having some sort of section to compare tent to existing protocols would be cool.
The text was updated successfully, but these errors were encountered: