Just read your blog post, those are some really interesting ideas / UX flows!
We have indeed thought about using SSB (and DAT hypercore) for hosting Radicle projects.
The Radicle architecture uses a deterministic language (similar to Scheme) for specifying state-machines (“Radicle machines”) which live on an append-only log. By adding the appropriate code, this can offer code collaboration features (issues, patch-requests, etc.), but it can be used for other uses too. The reason we did this is that we wanted to empower developers of each project to manage things as they wanted; a new feature can be added by simply adding some code to the project’s feed. The code specifies all sorts of rules for managing the project, e.g. a patch can only be merged into master if 2 admins have approved it, etc.
There are a few things that IPFS has which made us choose it, though we are also thinking of maybe moving down a layer to libp2p:
(1) Interleaving of feeds: in SSB the feed of a “project” would be the interleaving of all the inputs of all the feeds of the participants. However for the model above we need a total order of all inputs. (For example, it might be very relevant if a record attesting a user was made ‘admin’ came before or after they posted a record indicating a patch should be merged.) The Radicle machine could still be hosted on SSB but then all inputs would have to be on the hosts SSB feed, in which case (3) becomes relevant.
(2) SSB feeds (and DAT too) can be forked. When a feed is just text posts from an individual, this is probably not such a huge problem. But in our case this would mean that some of the rules stated in the code for the project could be broken (even removed) without needing anyone’s approval, etc. While the current implementation of Radicle on IPFS doesn’t guard against this yet, we are hoping to do add this soon, as described in the transparent machines doc. It may be that we are being overly paranoid here and that in most cases one can just trust the host not to fork the feed.
(3) IPFS has pubsub/messaging: this, in particular, allows users (even users the host/project isn’t in some sense “following”) to send proposed inputs to the host of a machine. I’m not sure if the SSB protocol has something that could replace this. (In any case, pubsub isn’t quite the right thing here, which is why we are investigating libp2p for more direct messaging needs.) The alternative is that proposed inputs may only be sent by people that have already been “invited” in some way. As you mention, especially for submitting “drive-by” issues, this seems rather onerous.
These reasons are mostly related to the architecture that we chose for Radicle; it may well be that SSB is useable for P2P code-collaboration as you describe in your post (but less suited to Radicle machines as we envision them).
I would love to chat about this some more.
So would we!
and one of my goals is to ascertain the general acceptance among developers of distributed platforms that go beyond mailing lists.
I would be very interested in hearing what sort of feedback you get.
On Monday, August 12, 2019 at 7:48:27 PM UTC, Konstantin Ryabitsev wrote:
Hi, Radicle folx:
A few weeks back I wrote the following blog post about some thoughts I
had about the future of distributed development:
Just recently, someone pointed out that Radicle has many of the similar
ideas, except that it uses IPFS instead of SSB. I don’t know that much
about IPFS, but I am wondering if you’ve considered the potential
benefits of using SSB as protocol instead. From my superficial
comparisons of both SSB and IPFS, I think SSB may be a better choice due
to its intrinsic chaining nature (and, therefore, ease of attestation of
all content to a specific developer/device).
I would love to chat about this some more. I am heading out to the
Kernel Summit in early September, and one of my goals is to ascertain
the general acceptance among developers of distributed platforms that go
beyond mailing lists.