Replies (17)

Yes - I think they sum it up quite nicely though
DanConwayDev's avatar DanConwayDev
While a peer-to-peer network without seed nodes is feasible, it is impractical. This is because regular “user” nodes go online and offline all the time, so finding a user from which to download a certain piece of content can be challenging, or even impossible if all users with that content are offline. Therefore, a healthy peer-to-peer network necessitates at least some highly available nodes that participate in the network like regular peers, but seldom go offline. These are called seed nodes.
View quoted note →
its an interesting journey they have been on. v1 used IPFS. v2 used Secure Scuttlebut. Now they are on version 3 which uses a custom gossip model. 2 years ago the Rad token was prominent and Etherium integration was under active development. For example in this video someone from Radicle tries to put a ownership attestation of a git repository onto the ETH chain but gas fees were $700 so they didn't have enough in their wallet. There now appears to be no mention of etherium and Radicle "doesn't use nor depend on any blockchain or cryptocurrency"
its an interesting journey they have been on. v1 used IPFS. v2 used Secure Scuttlebut. Now they are on version 3 which uses a custom gossip model. 2 years ago the Rad token was prominent and Etherium integration was under active development. For example in this video someone from Radicle tries to put a ownership attestation of a git repository onto the ETH chain but gas fees were $700 so they didn't have enough in their wallet. There now appears to be no mention of etherium and Radicle "doesn't use nor depend on any blockchain or cryptocurrency"
yeah, not surprising in my work the relation to cryptocurrency projects is for providing a distributed database store for nostr... and it seems to be very contentious... the new "arweave" project aims squarely at this use case and deprecates focus on tokens and all that other shit honestly, i'm just waiting for people to finally realise that it should be possible to make a bet on a tech project without all this rigmerole they would save on building stupid tokens into their distributed databases at least
Does it bother you that the organization developing this project is funded by a pre-mined shitcoin? Even if their tech and team were awesome I couldn't support their funding model. Unless you want to fork the project and clearly disassociate from Radworks I think you run the risk participating in an affinity scam.
There are plenty of systems that are (or claim to be) suited for decentralized sharing of code. There is Radicle, there is Nostr trough NIP-34, there is Shoggoth (which one can use for anything, not just AI) and there are Gitchain, Gitopia and others. There is also Git itself, which many consider to be sufficiently decentralized on its own, with either ActivityPub, maybe extended as in ForgeFed, to handle cooperation or something like git-bug to track issues. Which of those alternatives we should promote is no easy question.
I'm really impressed with radicle v1.0.0-rc4. There is a lot to like; some great ideas, well executed with good engineering, publicity and momentum. NIP-34 on the other hand, has no usage, little momentum, and really basic tools with jagged edges and confusing interfaces. I can see why your question arises and here is my answer: Nostr has fundamentals which set it apart as a superior protocol for code collaboration. Radicle has had 6+ years, $7m in funding and a team of 12 to mature, create polished experiences and build momentum. NIP-34 is new and has 1 person full-time alongside a small number of contributors who are focused on other priorities. With patience and a concerted development effort the features of nostr can shine through and provide an attractive decentralised alternative to github. From the simplicity of design, existing relay infrastructure, and vibrant development community to the growing userbase and ecosystem of social clients which will notify users and enable them to interact without leaving their app. I have drafted quite a few more thoughts about what we can learn from Radicle but they must wait for another note on another day.
No, I want to see git and zapping become a thing. We need to solve the FOSS funding problem. Labor and capital need to merge. No more freeloading on both sides.
bth I'm not that familiar with web3 culture. As an bitcoiner (outsider), part of me wants to believe that builders create tokens purely to access VC funding for a project with laudable cyperpunk goals; with the intention of stripping it out later. Perhaps they genuinely believe that creating a token can lead to decentralisation. I don't want to be that most of web3 is just greedy people stealing from the vulnerable. What is your assessment @ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ ?
summary comparison of Radicle and nip34: Radicle characteristics: * permissionless account creation. all messages signed with ed5519 key pair * custom p2p gossip protocol similar to lightning to identify repository peers and peer state * git protocol use for syncing with peers * seed nodes (essentially relays) used to addresses reliability issues of p2p * issues, patches and comments stored in git objects benefits over nip34: * p2p (works without seed nodes) * v1 nearly complete, with IDE plugins and web ui * more momentum, contributors and interest issues: * complex, making it potentially difficult to integrate and impractical for other implementations * centralised development team funded via a Etherium DAO utility token * learning curve - different mental model required than GitHub PRs which may be an adoption barrier * custom protocol, not part of an ecosystem * big maintenance burden * does not benefit from developments in ecosystem * no web of trust for spam prevention mechanisms nip34 benefits over Radicle: * simple * multiple implementations * part of ecosystem (nostr): * maintained protocols, libraries and tools for issues like transport, spam prevention, etc * account reuse across use cases * notifications accessible from other social clients * doesn't rely on infrastructure bespoke to nip34 protocol * can be adopted alongside GitHub repositories nip34 issues: * no momentum or usage * tooling is immature and with bare bones feature