6 ms·

From my quick read of the spec, server-to-server federation assumes that servers can be trusted. That need not be the case; unless a message is signed it should

by jeswin 9y ago

From my quick read of the spec, server-to-server federation assumes that servers can be trusted. That need not be the case; unless a message is signed it should not be assumed to have come from a specific user. I don't know if there's an easy way to share keys in a decentralized way, but that'd be an interesting problem to solve (some blockchain maybe). The other question is whether we want server-to-server federation at all instead of a P2P network like bittorrent. With the decreasing cost of compute, I am also optimistic of everyone being able to run a little sandbox on the cloud to exchange data with others, instead of routing it via FB/Twitter.

Ajedi32 9y ago
Seems to me that they _did_ consider those concerns to some extent, but the specification doesn't really address them: > Unfortunately at the time of standardization, there are no strongly agreed upon mechanisms for authentication. Some possible directions for authentication are laid out in the Social Web Community Group Authentication and Authorization best practices report. https://www.w3.org/TR/activitypub/#authorization https://www.w3.org/TR/activitypub/#authorization
detaro 9y ago
That need not to be the case, but realistically it is the case for Mastodon & co for now. People are looking into various signature schemes, potentially as extensions of the protocol, but it would have moved the entire thing into very untested waters, which is bad for a new standard. Same with federation: It's what you need right now for "normal" users (e.g. compare user numbers of Mastodon etc to purely p2p alternatives). While I personally self-host a lot of stuff and would be willing to run a Mastodon instance for friends and family, I can't expect or even recommend they run something themselves individually. Thanks to federation, nothing is stopping those that can to run their own single-user software speaking the protocol, or for instances to only serve very small groups.
- jeswin 9y ago
  As a counter example, there are millions of non-technical users using the bittorrent protocol. They are running a server on their machines and not aware of the technical complexity that lies underneath. I am not saying it's an easy UX problem to solve, but it can be done.
  - AsyncAwait 9y ago
    Sure, I think the problem with people running i.e. Mastodon on their own machine would be what should happen when people turn off their computer. I guess there could be some sort of "super node" solution, where a known Mastodon server would just forward you the "what happened while I was asleep" stuff and I guess people could encrypt their messages to you with your advertised public key, so that you don't have to trust the super nodes, but I am not sure about the additional complexity involved in implementing that vs current Mastodon using ActivityPub, nor about the usability challenges involved.
    - NoGravitas 9y ago
      That's basically how Secure Scuttlebut works; the super nodes are called pubs. It's actually remarkably easy to onboard to SSB with Patchwork. The problems set in when you start considering mobile devices or multi-device support (the latter is currently possible but risky).
  - fauigerzigerk 9y ago
    BitTorrent only works well (i.e in a true peer to peer fashion) if many people are serving up the same files so that some sources are always online. Outside of piracy that is rarely the case.
    - icebraining 9y ago
      People will serve whatever the software wants; serving only want the user explicitly selected is just an option. For example, in Freenode you don't control what gets downloaded and served (which also helps to hide what you're fetching on purpose).
ocdtrekkie 9y ago
I think there's a few major reasons servers is still the way to go, albeit numerous much smaller servers. - Mobile users content should remain available when they are disconnected. - Participating in a federated environment still contains plenty of technical challenges, if we want non-tech-savvy users to participate, we need admins. I personally would like to see servers for web applications, be they Sandstorm.io-type app platforms or Mastodon-type social networks, in a family-and-friends scale operation. I'd happily host resources for family and friends, for instance. While most people may not be able to run their own server, almost everyone is either family or friends with someone who can, and corporate offerings will fill in the gaps.
rakoo 9y ago
> I don't know if there's an easy way to share keys in a decentralized way, but that'd be an interesting problem to solve (some blockchain maybe). This is exactly what namecoin tried to solve. Buy an identifier, put whatever you want in it. Example: https://nameid.org/?name=rakoo https://nameid.org/?name=rakoo > The other question is whether we want server-to-server federation at all instead of a P2P network like bittorrent. We want something in between. The best model I know is the one of scuttlebutt (http://scuttlebot.io/more/protocols/secure-scuttlebutt.html http://scuttlebot.io/more/protocols/secure-scuttlebutt.html): Each peer is identified by an asymetric keypair, and writes posts/comments/photos to a local ledger. Everything is signed and potentially encrypted if the message is to be read only by select people. Diffusion follows the peers' connections: stuff is sent from peer to peer as they connect together, friends can be used as a third leg (ie a common friend can carry stuff even if it's not for them), and you also have pubs where more people can connect and get more stuff faster. This system is different from bittorrent in that everything depends on the human connections: information spreads along human acquaintances, names aren't globally unique, they depend on how your friends agree to name you, etc... It's better than naive server-to-server federation because pubs can be simple, stupid message forwarders yet still have all the advantages of being always-up servers.
- Crespyl 9y ago
  Scuttlebut is, so far, the most interesting decentralized social media tool I've seen. Even Mastodon and Matrix still require a server of some form, while SSB will continue to work offline and via truly local peer to peer connections. The only issue is client support and the fact that I don't have a good sense of the state of development/stability/soundness for SSB. If you (or anyone) has experience actually using SSB or similar true P2P platforms, I'd be very interested to hear what did or didn't work well.
  - ChristianBundy 9y ago
    SSB is rock-solid in that the community encourages the use of diverse client and server implementations rather than having a monolithic interface that's meant to do everything. On the other hand, the underlying libraries are opinionated in that they usually use depject and a handful of other tools/techniques that aren't super familiar to those outside the SSB community, which makes it harder to write brand new clients. I'd use SSB exclusively if they offered a web client (as I'm on a Chromebook), but we're slowly getting there.
olegkikin 9y ago
> I don't know if there's an easy way to share keys in a decentralized way Blockchain. Namecoin, in particular.
tbv 9y ago
We're discussing that situation here: https://github.com/beakerbrowser/beaker/issues/820 https://github.com/beakerbrowser/beaker/issues/820 We have two different p2p social feed apps that are compatible, but as we plan for future development we're considering ActivityPub/ActivityStreams
jack_zampolin 9y ago
> I don't know if there's an easy way to share keys in a decentralized way, but that'd be an interesting problem to solve (some blockchain maybe). There is a way to do this! Check out https://bockstack.org https://bockstack.org. We are working on decentralized identity and key management.
- deleted 9y ago
  [deleted]
- rapnie 9y ago
  correction.. you probably meant https://blockstack.org https://blockstack.org :)
deleted 9y ago
[deleted]
davexunit 9y ago
One of the authors of this standard has talked about decentralized identity, potentially using a blockchain, and has also mentioned that p2p is where things are headed. I have a feeling these will be the next topics explored in the standardization effort.
rogerbraun 9y ago
messages are signed using http signatures (https://tools.ietf.org/html/draft-cavage-http-signatures-09 https://tools.ietf.org/html/draft-cavage-http-signatures-09)
NoGravitas 9y ago
It's intended that server-to-server messages be signed with the private key that matches the public key baked into the user's profile data. I'm not sure whether the final specification requires this, or merely recommends it; it may have gotten pushed off to a future update in order to get the spec out on time.
paroneayea 9y ago
Hi... ActivityPub co-editor here. I linked to it elsewhere in the spec, but my paper at Rebooting Web of Trust addresses some of this: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/final-documents/activitypub-decentralized-distributed.md https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust... Currently ActivityPub servers in practice use HTTP Signatures and Linked Data Signatures, so there's a certain amount of proof of the origin of messages there. But in moving towards a much more peer to peer system, we can do even better by stripping out SSL Certificate Authorities and DNS altogether. The paper linked above discusses one path to accomplishing that in ActivityPub using DIDs. Hope that's interesting to you!

by jeswin 9y ago

Ajedi32 9y ago

Seems to me that they _did_ consider those concerns to some extent, but the specification doesn't really address them: > Unfortunately at the time of standardization, there are no strongly agreed upon mechanisms for authentication. Some possible directions for authentication are laid out in the Social Web Community Group Authentication and Authorization best practices report. https://www.w3.org/TR/activitypub/#authorization https://www.w3.org/TR/activitypub/#authorization

detaro 9y ago

That need not to be the case, but realistically it is the case for Mastodon & co for now. People are looking into various signature schemes, potentially as extensions of the protocol, but it would have moved the entire thing into very untested waters, which is bad for a new standard. Same with federation: It's what you need right now for "normal" users (e.g. compare user numbers of Mastodon etc to purely p2p alternatives). While I personally self-host a lot of stuff and would be willing to run a Mastodon instance for friends and family, I can't expect or even recommend they run something themselves individually. Thanks to federation, nothing is stopping those that can to run their own single-user software speaking the protocol, or for instances to only serve very small groups.

jeswin 9y ago
As a counter example, there are millions of non-technical users using the bittorrent protocol. They are running a server on their machines and not aware of the technical complexity that lies underneath. I am not saying it's an easy UX problem to solve, but it can be done.
- AsyncAwait 9y ago
  Sure, I think the problem with people running i.e. Mastodon on their own machine would be what should happen when people turn off their computer. I guess there could be some sort of "super node" solution, where a known Mastodon server would just forward you the "what happened while I was asleep" stuff and I guess people could encrypt their messages to you with your advertised public key, so that you don't have to trust the super nodes, but I am not sure about the additional complexity involved in implementing that vs current Mastodon using ActivityPub, nor about the usability challenges involved.
  - NoGravitas 9y ago
    That's basically how Secure Scuttlebut works; the super nodes are called pubs. It's actually remarkably easy to onboard to SSB with Patchwork. The problems set in when you start considering mobile devices or multi-device support (the latter is currently possible but risky).
- fauigerzigerk 9y ago
  BitTorrent only works well (i.e in a true peer to peer fashion) if many people are serving up the same files so that some sources are always online. Outside of piracy that is rarely the case.
  - icebraining 9y ago
    People will serve whatever the software wants; serving only want the user explicitly selected is just an option. For example, in Freenode you don't control what gets downloaded and served (which also helps to hide what you're fetching on purpose).

ocdtrekkie 9y ago

I think there's a few major reasons servers is still the way to go, albeit numerous much smaller servers. - Mobile users content should remain available when they are disconnected. - Participating in a federated environment still contains plenty of technical challenges, if we want non-tech-savvy users to participate, we need admins. I personally would like to see servers for web applications, be they Sandstorm.io-type app platforms or Mastodon-type social networks, in a family-and-friends scale operation. I'd happily host resources for family and friends, for instance. While most people may not be able to run their own server, almost everyone is either family or friends with someone who can, and corporate offerings will fill in the gaps.

rakoo 9y ago

> I don't know if there's an easy way to share keys in a decentralized way, but that'd be an interesting problem to solve (some blockchain maybe). This is exactly what namecoin tried to solve. Buy an identifier, put whatever you want in it. Example: https://nameid.org/?name=rakoo https://nameid.org/?name=rakoo > The other question is whether we want server-to-server federation at all instead of a P2P network like bittorrent. We want something in between. The best model I know is the one of scuttlebutt (http://scuttlebot.io/more/protocols/secure-scuttlebutt.html http://scuttlebot.io/more/protocols/secure-scuttlebutt.html): Each peer is identified by an asymetric keypair, and writes posts/comments/photos to a local ledger. Everything is signed and potentially encrypted if the message is to be read only by select people. Diffusion follows the peers' connections: stuff is sent from peer to peer as they connect together, friends can be used as a third leg (ie a common friend can carry stuff even if it's not for them), and you also have pubs where more people can connect and get more stuff faster. This system is different from bittorrent in that everything depends on the human connections: information spreads along human acquaintances, names aren't globally unique, they depend on how your friends agree to name you, etc... It's better than naive server-to-server federation because pubs can be simple, stupid message forwarders yet still have all the advantages of being always-up servers.

Crespyl 9y ago
Scuttlebut is, so far, the most interesting decentralized social media tool I've seen. Even Mastodon and Matrix still require a server of some form, while SSB will continue to work offline and via truly local peer to peer connections. The only issue is client support and the fact that I don't have a good sense of the state of development/stability/soundness for SSB. If you (or anyone) has experience actually using SSB or similar true P2P platforms, I'd be very interested to hear what did or didn't work well.
- ChristianBundy 9y ago
  SSB is rock-solid in that the community encourages the use of diverse client and server implementations rather than having a monolithic interface that's meant to do everything. On the other hand, the underlying libraries are opinionated in that they usually use depject and a handful of other tools/techniques that aren't super familiar to those outside the SSB community, which makes it harder to write brand new clients. I'd use SSB exclusively if they offered a web client (as I'm on a Chromebook), but we're slowly getting there.

olegkikin 9y ago

> I don't know if there's an easy way to share keys in a decentralized way Blockchain. Namecoin, in particular.

tbv 9y ago

We're discussing that situation here: https://github.com/beakerbrowser/beaker/issues/820 https://github.com/beakerbrowser/beaker/issues/820 We have two different p2p social feed apps that are compatible, but as we plan for future development we're considering ActivityPub/ActivityStreams

jack_zampolin 9y ago

> I don't know if there's an easy way to share keys in a decentralized way, but that'd be an interesting problem to solve (some blockchain maybe). There is a way to do this! Check out https://bockstack.org https://bockstack.org. We are working on decentralized identity and key management.

deleted 9y ago
[deleted]
rapnie 9y ago
correction.. you probably meant https://blockstack.org https://blockstack.org :)

deleted 9y ago

[deleted]

davexunit 9y ago

One of the authors of this standard has talked about decentralized identity, potentially using a blockchain, and has also mentioned that p2p is where things are headed. I have a feeling these will be the next topics explored in the standardization effort.

rogerbraun 9y ago

messages are signed using http signatures (https://tools.ietf.org/html/draft-cavage-http-signatures-09 https://tools.ietf.org/html/draft-cavage-http-signatures-09)

NoGravitas 9y ago

It's intended that server-to-server messages be signed with the private key that matches the public key baked into the user's profile data. I'm not sure whether the final specification requires this, or merely recommends it; it may have gotten pushed off to a future update in order to get the spec out on time.

paroneayea 9y ago

Hi... ActivityPub co-editor here. I linked to it elsewhere in the spec, but my paper at Rebooting Web of Trust addresses some of this: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/final-documents/activitypub-decentralized-distributed.md https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust... Currently ActivityPub servers in practice use HTTP Signatures and Linked Data Signatures, so there's a certain amount of proof of the origin of messages there. But in moving towards a much more peer to peer system, we can do even better by stripping out SSL Certificate Authorities and DNS altogether. The paper linked above discusses one path to accomplishing that in ActivityPub using DIDs. Hope that's interesting to you!