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