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.
the website has been remade and the old articles are gone. Is this some kind of relaunch? Are the people behind the old radicle still around?
Funnily enough, the article makes no mention of blockchain, while the community discourse shows that monadic.xyz appears to be funding radicle development and is looking for blockchain developers to work on it. This still seems to be tied to oscoin.io, quite curious where the money for this keeps coming from.
It’s less of relaunch and more of an update on our development. After launching last year, we learned a lot from early users and iterated on our design to focus the direction of the project. We’ve been communicating these changes as we process them (see here and here) — this post is simply an attempt to present those changes and realign the public direction of the project. The website has been redesign to reflect these changes. All previous work on the project still exists in the old repo.
Monadic does indeed fund development on the Radicle project and did fund the oscoin.io project. oscoin has been sunsetted as a “product” and the research that went into it will instead be implemented within the Radicle project (see new website). The article does indeed (second to last paragraph) mention this approach with the presentation of the global registry that holds canonical project metadata. On “where the money comes from”: Monadic is funded by the partners presented on the website and Radicle is — and will remain — a free and open source project.
Hope this provides more clarity! More frequent updates on development will be shared on the community discourse.
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).
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.
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.
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).
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.
I’m really excited to see attempts at a decentralized github replacement that explicitly prioritize “uncensorability” and “liberty” in those strong terms
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.
I’m a bit confused by this project’s status. Since last time this was shared
the website has been remade and the old articles are gone. Is this some kind of relaunch? Are the people behind the old radicle still around?
Funnily enough, the article makes no mention of blockchain, while the community discourse shows that monadic.xyz appears to be funding radicle development and is looking for blockchain developers to work on it. This still seems to be tied to oscoin.io, quite curious where the money for this keeps coming from.
Hej, thanks for the questions.
It’s less of relaunch and more of an update on our development. After launching last year, we learned a lot from early users and iterated on our design to focus the direction of the project. We’ve been communicating these changes as we process them (see here and here) — this post is simply an attempt to present those changes and realign the public direction of the project. The website has been redesign to reflect these changes. All previous work on the project still exists in the old repo.
Monadic does indeed fund development on the Radicle project and did fund the oscoin.io project. oscoin has been sunsetted as a “product” and the research that went into it will instead be implemented within the Radicle project (see new website). The article does indeed (second to last paragraph) mention this approach with the presentation of the global registry that holds canonical project metadata. On “where the money comes from”: Monadic is funded by the partners presented on the website and Radicle is — and will remain — a free and open source project.
Hope this provides more clarity! More frequent updates on development will be shared on the community discourse.
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!
I’m really excited to see attempts at a decentralized github replacement that explicitly prioritize “uncensorability” and “liberty” in those strong terms