> 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

> 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): 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.

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.

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.

> ssb webclient

https://github.com/ssbc/patchfoo

you do need to host your `sbot` somewhere tho

+1 for the opinionated code bit, the Patchwork (i.e. the client) codebase is very dependent on lots of abstract patterns and libraries.

ftr we're moving Matrix to be more p2p in future (by letting you run servers clientside if you so desire), although this is a while away.

should also take a look at https://datproject.org

very interesting and maybe better than SSB..

it has hypercore - raw distributed streams, and hyperdrive - file abstraction on top, and a whole bunch of related projects, like Beaker browser.

https://github.com/datproject/awesome-dat

the protocol could be turned into a generic federated messaging framework..

FWIW I'm 80% convinced that dat is the future of SSB. It has the technological foundations to do everything SSB needs and more. There is however one huge difference in philosophy, that can be solved with technology but still needs to be done: SSB gossips content through the human network and public places, while dat needs direct connectivity between peers. The former is better exactly for the reason that was mentioned earlier: Peers need to have some re-hosting if they want to have their content disseminated while they're offline, so the discussion can still happen. Dat will need to have the equivalent of SSB's pubs (no-registration, no-config, just connect and send).

There is a discussion about that somewhere but I can't find it anymore

The scuttlebot link mentions append-only. Does this include the possibility of appending a "delete" or "edit" message?

Yes, exactly: https://github.com/dominictarr/ssb-docs#is-it-possible-to-de...

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.

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

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!

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

We're discussing that situation here:

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

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.

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.

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.

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

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.

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

> 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. We are working on decentralized identity and key management.

correction.. you probably meant https://blockstack.org

:)

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.

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.

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

> I don't know if there's an easy way to share keys in a decentralized way

Blockchain. Namecoin, in particular.