4 ms·

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

by 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.
  - xj9 9y ago
    > ssb webclient https://github.com/ssbc/patchfoo https://github.com/ssbc/patchfoo you do need to host your `sbot` somewhere tho
  - fenwick67 9y ago
    +1 for the opinionated code bit, the Patchwork (i.e. the client) codebase is very dependent on lots of abstract patterns and libraries.
- Arathorn 9y ago
  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.
- rapnie 9y ago
  should also take a look at https://datproject.org 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 https://github.com/datproject/awesome-dat the protocol could be turned into a generic federated messaging framework..
  - rakoo 9y ago
    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
bringtheaction 9y ago
The scuttlebot link mentions append-only. Does this include the possibility of appending a "delete" or "edit" message?
- rakoo 9y ago
  Yes, exactly: https://github.com/dominictarr/ssb-docs#is-it-possible-to-delete-or-edit-messages https://github.com/dominictarr/ssb-docs#is-it-possible-to-de...

by rakoo 9y ago

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.
- xj9 9y ago
  > ssb webclient https://github.com/ssbc/patchfoo https://github.com/ssbc/patchfoo you do need to host your `sbot` somewhere tho
- fenwick67 9y ago
  +1 for the opinionated code bit, the Patchwork (i.e. the client) codebase is very dependent on lots of abstract patterns and libraries.
Arathorn 9y ago
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.
rapnie 9y ago
should also take a look at https://datproject.org 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 https://github.com/datproject/awesome-dat the protocol could be turned into a generic federated messaging framework..
- rakoo 9y ago
  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

bringtheaction 9y ago

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

rakoo 9y ago
Yes, exactly: https://github.com/dominictarr/ssb-docs#is-it-possible-to-delete-or-edit-messages https://github.com/dominictarr/ssb-docs#is-it-possible-to-de...