Great short into by a Radicle contributor: <a href="https://twitter.com/abbey_titcomb/status/1237053756983959552?s=21" rel="nofollow">https://twitter.com/abbey_titcomb/status/1237053756983959552...</a>
Really like the idea of decentralizing projects and their social artifacts. Getting rid of github for project discovery is a great goal.<p>Additionally running all of this on top of I2P would counter any embargoes that centralized forges like Github have to abide by. Projects by Iranians wouldn't suddenly disappear from radicle and neither would things like PopcornTime.<p>I'll be checking this out. I hope they have an executable with a good CLI. The GUI or embedded webserver for the social part of radicle can come later (unless they already have it)
Ssb itself does initial sync which requires a few GB of download to use (and will keep growing AFAIU). Does radicle-link have the same issue? Or is it relying on gossip and transient data?
From the first look it sounds like GitCenter (git over zeronet), but a closer looks seems radicle is more efficient and has unique (and probably better) way for discovering new content. Still not very clear about the actual design of radicle, will checkout more about it
<i>In fact, Git was only created when Linus’ free Bitkeeper license was revoked after a Linux kernel contributor tried to reverse engineer its networking protocols</i><p>Bit-who?
I have to say that reading the Radicle designers observations about git on IPFS I think they solved the wrong problem. I would love to be able to save and work with git repos on ipfs.<p>Most of the other things radicle aims to provide seem like they are better centralized. There is a reason we all use gitlab/github for collab services. It is that centralization is better for that kind of thing.
Any approach to sharing and collaborating around a git repository that requires some convention inside that repository seems fundamentally broken to me. I understand why people want to do it that way -- self describing artifacts are quite handy. Having something like fossil that can live inside a git repo itself is a big plus, for some workflows. I would be shocked if the linux kernel tree ever has a project.json file added to it. All the identifiers you need are already there in the commit hashes, why create another layer of complexity inside the repo itself?