Hacker News Reader

Comment by Torgo | Hacker News Reader

I am not convinced that this needs a new protocol as they claim. Facebook-style functionality be done on top of activity streams, pubsubhub, salmon, webfinger et al. They indicate they have investigated existing systems and found them lacking. I would rather have something like this built on protocols that a bunch of people have discussed out in the open first. That said, I am interested to see more details as they arise, as this type of thing is needed.

View on HN

Or at least some hard details about what those existing alternatives are lacking. That could lead to further improvement, as whatever communities have already formed around those alternatives could debate the questions and possibly improve their protocols.

As it is the FAQ reads like "those are old and busted, we wanted something new and hot," which gives off an aura of NIH syndrome.

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.

Hey, so, I'm one of the co-authors of OStatus.

First, welcome to the community of people working on this important problem. I highly recommend you join this group to stay informed about what's going on elsewhere:

http://www.w3.org/community/fedsocweb/

It's an "issue" group, not dedicated to any one protocol, service, or software package. Please, make sure you're a part of it!

A couple of notes:

1. We're working on including private messages in PubSubHubbub 0.4 and thus into the next version of OStatus. Understood that it's a big deal.

2. You're right, there's no standard API. ActivityPub is an attempt at that; see here: http://www.w3.org/community/activitypub/

Thanks for considering. Let's make sure we interoperate!

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?

I've yet to go read the op page -- but:

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

And yet, where NIH would be useful, they reuse the inappropriate HTTP.

We considered the protocols you're mentioning. There are a few huge problems for our use cases: PSH is built on Atom which means all feeds are public. That's fine for your public feed ala Twitter, but unacceptable for private messages. We also think it's critical for users to be able to take their relationships with them when they move to another server/provider. OStatus and PSH don't make that possible. They also don't have a standard application access API, so developers have to work around different providers' specifications if they exist at all.

The federated social net was a great first step, but the lack of support for access control/private messages and account portability means that you end up with lots of proprietary implementations of basic features which can create vendor lock-in.

How does using atom make things public? Just use client certs over https -- and it's as private and secure as anything over http(s) ever is?

Alice gets her updates from Bob via something like:

https://bob.example.com/private/alice/<type>.rss

You'd of course need to synchronize access passwords/keys/tokens somehow -- but that could be part of "friending" someone?

Integrate with something like cacert.org so you don't have to manage certs (as part of this project). A friend request includes the requesters cert (could be self signed, or via a trusted authority, like cacert), encrypted with the public cert of whomever the request is sent to.

When a friendship is accepted on the other end, store the cert, and use that for authentication. Add your own authorization rules (Alice is a close friend).

It might be a benefit to set it up as follows: everyone has a personal cert. They generate and sign a proxy cert for their tent server. The public "top" cert is used for user management and federation -- numerous such "downstream" certs could be generated, along with revocation certs.

Reply on news.ycombinator.com