3 ms·

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 e

by Torgo 14y ago

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.

danielsiders 14y ago
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.
- e12e 14y ago
  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 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.
smacktoward 14y ago
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.
- danielsiders 14y ago
  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-specification.html#anchor4 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).
  - smacktoward 14y ago
    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."
    - drivebyacct2 14y ago
      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.
    - danielsiders 14y ago

by Torgo 14y ago

danielsiders 14y ago

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.

e12e 14y ago
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 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.

smacktoward 14y ago

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.

danielsiders 14y ago
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-specification.html#anchor4 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).
- smacktoward 14y ago
  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."
  - drivebyacct2 14y ago
    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.
  - danielsiders 14y ago