Radicle, but using SSB instead of IPFS?
Konstantin Ryabitsev
A few weeks back I wrote the following blog post about some thoughts I
had about the future of distributed development:
https://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains
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.
Best regards,
-K
James Haydon
Hi,
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.
Best,
James
Konstantin Ryabitsev
Sorry for such a long delay between emails -- unfortunately, my
primary work responsibilities lay pretty far from designing what we
should use to replace email-based workflows. :) That said, I am
actually at the Kernel Summit this week and I believe there is
gathering momentum behind the push to get a couple of improvement
proposals. I am wondering if you can answer a couple of questions for
me.
First, you mention an append-only log. What is your approach to
handling "blockchain poisoning" -- when someone deliberately adds
illegal content to an append-only source in hopes to make the sole act
of replicating the project legally problematic. The reason I liked
individual SSB chains is because they are immune to such attacks --
poisoned SSB chains can be blocked or truncated by the project (i.e.
"replicate this SSB source up to entry X, but no further"). Similarly,
someone abusive can be ejected from the project by having their SSB
chain blocked or truncated, effectively blocking their ability to
permanently disrupt the project. (There's still ways this can be
abused, so ultimately a project may choose to switch to an allowlist
of feeds instead of maintaining an ever-growing blocklist.)
Similarly, as someone who has to routinely deal with various requests
to remove things from bugzilla.kernel.org (e.g. when someone pastes a
dmesg containing strings from an unreleased piece of hardware), is
there any process that would allow something like this for radicle?
Best,
-K
Konstantin Ryabitsev
Director, Projects IT
The Linux Foundation
Montréal, Québec
Kim Altintop
We are currently busy roadmapping the future directions of radicle, sorry for
the slow reponse.
I'll try to answer based on the current radicle architecture:
Essentially, the machine semantics (the radicle code) would need to be
sophisticated enough to determine what is and what is not acceptable input,
and reject the expression if it is not. From your examples, it's obvious
that this unlikely to be feasible for all kinds of inputs - classifying
what is considered illegal might better be left to human approval.
I'm not sure the current architecture would easily allow for that, but some
way of interactive approval before an expression gets permanently applied
to the log of the owner's machine does indeed seem to be desirable. Note
also that the transparent machines proposal would guard against replicas
rewriting history arbitrarily.
This being said, we are currently considering to move towards an SSB-like
model, potentially backed by git itself, or at least using git primitives. One
interesting property over SSB would be that a user can attest a contribution
into (her view of) mainline. Obviously, this would impose a certain discipline
wrt branching (when using merges) or other ways of attribution (when using
cherry-picking), akin to sign-offs - so this requires more thought.
Let us know your thoughts!
Kim