Why not ostatus?

[steveklabnik]

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.

[titanous]

We originally began by attempting to use and revise the OStatus protocol. These are our main complaints:

• no support for private messaging, account privacy, post privacy, etc
• inability to move relationships when moving servers/identifiers
• no standard API for application interaction

We are working on a comparison page that will address OStatus in more detail.

[krainboltgreene]

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?

[steveklabnik]

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?

[titanous]

@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.

[benwerd]

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.

[steveklabnik]

@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 :)

[wilkie]

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. :)

[max-mapper]

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"

[steveklabnik]

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?

[blaine]

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. ;-)

[melvincarvalho]

Tent API is much better than OStatus. Let's compare:

1. First and foremost, tent follows the fundamental axiom of the web in giving users an HTTP URI, OStatus does not. This means that tent is a highly web oriented protocol, OStatus is more webmail oriented.
2. Tent Uses JSON, OStatus uses bespoke JRD and XRD with unclear IPR.
3. Tent uses OAuth and HMAC, OAuth uses OAuth and Salmon. OAuth is pretty good, but considered a fail by many of its authors, salmon seems to be implemented differently by everyone.
4. Tent uses a on open JSON schema, OStatus uses Activity Streams which is under heavy control by the lawyers.
5. It seems that tent can simply use HTTP GET for discovery, OStatus uses the proposed draft webfinger, which is dependent on a new URI protocol, XML, XRD and .well-known patterns. After 3 years, webfinger has multiple authors with differing, sometimes opposing, views, It's unclear whether webfinger will make it through the IETF as a best practice in its current form.

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.

[steveklabnik]

Much of this boils down to preferences, (of which mine are 'implemented, supported protocols are better than theoretical protocols') but...

Activity Streams which is under heavy control by the lawyers.

Citation, please? I've never heard of this, but I'd like to know about it.

[willnorris]

@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.

[melvincarvalho]

@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!

[max-mapper]

I for one welcome our new JSON overlords

On Thu, Aug 23, 2012 at 10:38 AM, melvincarvalho
notifications@github.comwrote:

@willnorris https://github.com/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!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-7977595.