4 ms·

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 fi

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.

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.