We take NIH very seriously and originally began by attempting to revise existing protocols. We have some very specific complaints about existing federated web protocols:
• no support for private message (pubsubhubbub, anything atom-based)
• inability to move relationships when changing service
• no standard API for application interaction
by leaving each of these (and others) out of scope see: http://ostatus.org/sites/default/files/ostatus-1.0-draft-2-s... they have created an ecosystem unfriendly to developers (who have to approach each provider separately to work out auth schemes and APIs) and likely to lead to vendor lock-in (because relationships can't be transferred and basic features are implemented differently in each system).
This is valuable -- I'd recommend adding a page to your site that includes these types of critiques, it'd be useful for those working on or around those other protocols. And it'd give people who are interested in your work a URL they could send around when asked "why not just use salmon/webfinger/ostatus/whatever."
Thanks, that's a good note. We didn't want it to seem like we were attacking the other protocols (all of which have had success, have clear use cases, and we owe some debt to for paving the way), but we should make our reasoning clearer to the community. Will do.
Please this! There are so many [dropbox/facebook/twitter]-clones that claim to be different that reinvent things and use poorly designed in-house protocols and I eventually got so tired of them that I mostly ignore them now.
And what about XMPP? It has private messages. If run in a similar way to tent (single user per server/domain?) then switching service provider is exactly the same. "No standard API" ... isn't the protocol an API?
* for messaging why would you not use xmpp and/or smtp?
As for using http -- I'd say http makes good sense for getting, sending and receiving documents -- like text and images. It makes it fairly easy to implement a REST-like architecture.
As for things that have been tried before, we have ping backs -- that IMNHO never really worked. And there's Diaspora that have yet to come up with a stable protocol -- and have an implementation that is pretty badly broken.
It's also a good illustration of going the "full http" route: publishing becomes easy; interaction (server to server) becomes hard if you want to have any kind of security in place.