Threads for askywalker
-
I think it’s going to be very difficult to sell the combination of “uncensorable” and “canonical global registry”. If a tool I use for my professional and/or uncontroversial work is inextricably and publicly linked with people who are generating deepfakes or sharing 3d printed weapon designs or worse, that’s not going to go down well. If my computer is helping to store and distribute that data for others then so much the worse. If self-hosting a gitea instance is too risky for somebody then I’m not sticking my neck out for them.
While the article offers a decent critique of federation as a solution, it does have the useful property that you only host and interact with the data that you’re interested in.
-
Under the uncensorable principle in the article we specifically include “In addition, users should have the freedom to control their interactions and the content they see on an individual basis.” to address this point. Radicle adopts the same “shared moderation” approach that Scuttlebutt does. Users have the freedom to choose what is replicated on their machine and what is not. This allows moderation to spread naturally, and keeps the network neutral. Also, users don’t have to replicate the canonical global registry.
-
Umm, but no mention of git-ssb at all?? or did I miss it? I would totally expect some comparison…
Our original post mentioned the git-ssb as a source of major inspiration behind the project :) We didn’t compare directly in the article, because we wanted to focus more generally on the comparison to the “social overlay” approach to SSB that has been key theme in our redesign.
Having only cursory knowledge of SSB and git-ssb, and no knowledge of Radicle at all, I would find a comparison of what you claim to have “learned from” git-ssb helpful. As of now, I only see there are now 2 git-related SSB-related projects, no idea why I should be interested in yours compared to the other one, when I can easily see that some people are apparently already happily (?) using git-ssb.
Also, you mention some redesign in your comment here, which doesn’t help me in anything if I don’t even know that there was something before that was redesigned (the article doesn’t seem to mention any redesign).
Sure! First, Radicle isn’t really SSB-related - the protocols are designed differently. You can think of git-ssb as an append-only log of “raw” (uncompressed, non-delta-encoded) updates to your local git repo. Radicle only synchronizes the differences between git object databases of different peers. git-ssb replaces the storage and networking layer of git, while making git believe it’s “talking” to another git server. Radicle doesn’t replace the storage layer, but instead introduces peer-to-peer networking on the transport layer without changing git’s network protocol. A similarity between the two is that every collaborator on a project only ever writes to their own view of the repo – there is no such thing as a shared master branch in a distributed setting.
The inspiration Radicle takes from git-ssb and SSB mainly applies to how SSB implements conversational interactions: disjoint streams of messages can reference other streams and be coalesced into a single timeline. This is how we intend to implement collaboration features (issues, pull requests) in Radicle. You can find more on this in our protocol spec. Everything is WIP so comments and feedback are appreciated!
On ‘why you should be interested’ — it’s too early to make a detailed comparison regarding one approach vs. the other. We believe git-ssb satisfies many of our design goals but not all so we’re exploring a different approach.
This post is the output of multiple iterations on the Radicle project after launching last year. You can find more context on the evolution of the project on the new and old GitHub repos (this issue specifically), Twitter, or our community discourse.
Cool, thanks!