LWN: Comments on "Radicle: peer-to-peer collaboration with Git"

Radicle: peer-to-peer collaboration with Git

Spudd86 — Thu, 19 Sep 2024 22:19:12 +0000

Oh, found it, it's funded by a crypto company, but this project doesn't use it for anything. From the FAQ:

What is the relationship between Radicle and the Radworks ($RAD) token?

Radicle is a true peer-to-peer protocol. It doesn’t use nor depend on any blockchain or cryptocurrency.

Radworks, the organization that has been financing Radicle is organized around the RAD token which is a governance token on Ethereum.

Radicle: peer-to-peer collaboration with Git

Spudd86 — Thu, 19 Sep 2024 22:14:49 +0000

I'm confused about your assertion of the existance of a crypto currency token. I don't see any mention of one.

It uses cryptographic identities, but that has nothing whatever to do with crypto currency or NFTs.

It's peer to peer and distributed in the same way that git is. It verifies things with normal crystallographic signatures, as already commonly used with git.

Radicle: peer-to-peer collaboration with Git

stephenjudd — Wed, 11 Sep 2024 03:44:57 +0000

I also misread as Radicale (which I use) when I skimmed the home page. It is unfortunate. But software names are a very crowded space these days, so I forgive.

Radicle: peer-to-peer collaboration with Git

ceplm — Tue, 10 Sep 2024 14:23:44 +0000

The answer is in my opinion to use something which actually works right now. For example, SourceHut … yes, git repository, very simple TODO list, and email lists.

Radicle: peer-to-peer collaboration with Git

shackra — Fri, 14 Jun 2024 13:28:18 +0000

I wonder if decoupling user identities from nodes could be like Nostr, where nodes are like the relays and each user can own their identity as a private key 🤔

Radicle: peer-to-peer collaboration with Git

zaitseff — Tue, 14 May 2024 00:31:48 +0000

Immutability of data: Having an everlasting, unchangable, signed database anyone can write to is rarely actually desirable.

SKS Keyserver had exactly the same problem: once a public key, or part of a public key like an additional signature, was added, it could not be removed. Worse, IIRC anyone could add such material to other people's keys—up to and including JPEG images of who-knows-what… Many keyserver operators, myself included, left the keyserver pool for this or similar reasons.

Radicle: peer-to-peer collaboration with Git

massimiliano — Mon, 22 Apr 2024 11:47:04 +0000

Disclaimer: Radicle is very dear to me mostly because I worked full time on it for most of 2020. I have been following it since then but I am no longer active in the project.

I have two main gripes with it:

it should use plain, eventually centrally hosted git repositories as backing store for "nodes": this would allow existing git projects stored anywhere (including github, gitlab and other forges) to join the Radicle network as valid node copies, even if they cannot speak the p2p gossip protocol, mostly eliminating the barrier to entry for new users
it should have properly decoupled user and node identities from the start: any user might want to use multiple developer workstations and still keep their identity; not supporting this use case also raises the barrier to entry "too much" for most potential users

I really believe in the project goals, but when working inside the team I have not been able to steer the project in those two directions. I still consider this a personal failure of mine (or at least a big missed opportunity).

About directly supporting sharing repository contents using git repos hosted "anywhere", I proposed it but the idea went nowhere: the p2p protocol was too central to the "node" idea (with all the hosting issues and eventual firewall-piercing technical hurdles that it implies).

I also clearly stated that the overall tradeoffs between energy efficiency, costs and reliability with a totally distributed system are terrible. There are good reasons why most forges (starting from github) can give away reliable git storage space for free, and getting that pervasive level of adoption with a p2p system IMHO is between "too hard" and "plain impossible".

However, this idea was not understood and went nowhere.

About the second issue, decoupling personal user identity from node identity was literally the first thing I tried to do in the project, with technical proposals and pull requests. In this case the complications I was adding were "too large", and we ultimately decided we were not able to work together (for this and other reasons).

I am sorry to see that also this idea of mine did not make it (even if it is considered for post-1.0 work).

That said, the project is solid and provides something that is sorely needed, and I really like all the team members I have met at the time; working with them has been a wonderful experience despite the disagreements!

I am still convinced that the only way to mass adoption would be allowing plain github repos to participate in the network as "passive", "data-store" nodes.

But I still wish the project good luck with all my heart!

Radicle: peer-to-peer collaboration with Git

Cyberax — Fri, 12 Apr 2024 01:45:51 +0000

You can check the IPv6 stats for Google here: https://www.google.com/intl/en/ipv6/statistics.html - it's very sad.

> Maybe I missed it and could do a little more research but does the application work with IPv6 addresses because that can restore peer-to-peer connectivity

It won't. IPv6 in practice behaves like NAT, you need both peers to somehow communicate their decision to their firewalls. You can't just randomly connect to a port of an IPv6 peer and expect it to work. This is especially true for mobile devices, which form the main IPv6 deployment pool right now.

Radicle: peer-to-peer collaboration with Git

Wol — Thu, 11 Apr 2024 14:38:07 +0000

If you mean what I think you mean, maybe it's just not used now because there's no need?

Aiu you, an xbox would open an IPv4 link to a Microsoft server that was both IPv6 and IPv4. It would then get an IPv6 address from that server, and tunnel all IPv6 traffic over the IPv4 link.

If I was implementing something like that, I'd just ask for an IPv6 address from my local DHCP, and only use Teredo if I couldn't get one. In which case XBox Live could still be using that, just that as IPv6 has got more universal Teredo would disappear naturally of its own accord.

I'm not aware of using IPv6, but to the best of my knowledge my router is dual, and my PCs and laptops support IPv6 by default ... so hopefully by now NAT is just dying out naturally ...

Cheers,
Wol

Radicle: peer-to-peer collaboration with Git

atnot — Thu, 11 Apr 2024 14:33:26 +0000

Unfortunately not really. While it does significantly improve the situation around CGNAT, what we call "nat holepunching" is really two things: Creating a NAT ip-port mapping and an entry in the stateful firewall's connection list. With IPv6, you don't need to do the former, but in almost all cases you still have to do the latter.

Radicle: peer-to-peer collaboration with Git

raven667 — Thu, 11 Apr 2024 13:15:28 +0000

> Radicle does not yet have "NAT punching", but relies on third-party, publicly accessible seed nodes.

Maybe I missed it and could do a little more research but does the application work with IPv6 addresses because that can restore peer-to-peer connectivity in a lot of cases, Google was recently reporting that around 40% of their traffic is now IPv6 so even if _your_ ISP or your region doesn't support it yet, others support it very well, so plan A can be direct IPv6 p2p and plan B can be some NAT traversal technology.

Tangent: Now that I'm thinking about it, I'm wondering about the production history of Teredo protocol as used by the Xbox, I'm not sure Xbox Live still uses it but I haven't seen a retrospective on what the pros and cons of it were, operationally. Teredo (IIUC) is an IPv6 tunnel over IPv4/UDP designed to work behind a NAT and encode the public NAT IP and port for peer-to-peer NAT traversal, the Xbox used it for p2p gaming to reduce latency vs bouncing all traffic from behind NAT routers through a central server. Maybe games just moved away from p2p flows toward mediation through a central game arbiter as an anti-cheat measure, dunno.

Radicle: peer-to-peer collaboration with Git

mirabilos — Wed, 10 Apr 2024 22:19:39 +0000

> supports far fewer ISAs.

The lacking support in Rust itself and LLVM was the issue in the first place, so anything supporting even *less* is… quite unhelpful.

Not to forget Cranelift itself is also written in Rust…

gccrs and even rust_codegen_gcc or what’s it’s called are also not helpful yet. They _might_ become somewhat helpful once they are available in Debian so that standard package building picks them up when building Rust packages on nōn-rustc/llvm architectures, automatically, and they are supported on all architectures and can build all the codes.

So, perhaps in a decade or something.

It’s worse than ghc, and as bad as pre-Zero Java was, no, even worse, with the GCJ situation we had a stopgap.

Radicle: peer-to-peer collaboration with Git

Curan — Wed, 10 Apr 2024 22:13:02 +0000

I am wondering: Matrix does have groups and such these days. Anyway, I never really warmed up to most modern chat solutions either, really. For me IRC, Matrix, Signal, Rocket.Chat and such are usually all I need and want. At least there the Code-highlighting is working – something I can't say for many "professional" solutions like MS Teams (with paid accounts)

Radicle: peer-to-peer collaboration with Git

Curan — Wed, 10 Apr 2024 22:08:47 +0000

Hm, I should have been clearer, I think. There are other projects like ggcrs [0], but none of them can claim – AFAIK – to be 100 % compatible with the official `rustc`. In fact: there is not even a standard – again: to the best of my knowledge – that other compilers could implement. In this regard Rust is far inferior to eg. C or C++.

---

[0] <https://rust-gcc.github.io/>

Radicle: peer-to-peer collaboration with Git

Curan — Wed, 10 Apr 2024 22:05:20 +0000

GStreamer I find a really bad example, though that is probably best discussed in person and not over any kind of chat. What I will say here is: the concept in general is nice, in practice it fails so much that I never used it productively anywhere. FFMpeg was always better (though, maybe, that says more of my target audience than GStreamer? I don't know. To me, in my requirements, it always felt at least somewhat hacky). Anyway, I do concede, that this is not really something a distribution like Debian can argue, once it accepted a certain piece of software.

Of librsvg I was not aware and I must admit I am surprised. A SVG parser might be messy because of its standard (and extensions), but not being able to compile everywhere was not what I was expecting.

Python I have – very personally – no interest in. So I do not have any knowledge in this space. Sorry.

That said: I can accept the argument of "needs to compile to all the platforms I/$entity" care for. That was not clear to me from your initial post. Because I do also think, that having some software available ob one system and not necessarily on all others is not an issue in all cases. That being said: that Rust is limited by its implementation/LLVM is an issue. I wish there were more resources available to the gccrs developers [0], who aim for a better and long-term hopefully better platform.

----

[0] <https://rust-gcc.github.io/>

Radicle: peer-to-peer collaboration with Git

intgr — Wed, 10 Apr 2024 21:43:27 +0000

> being based off LLVM and not having any other implementation

This is not technically true any more. There is a working, stable Cranelift backend. Though it generates less optimized code than LLVM/GCC and supports far fewer ISAs. https://lwn.net/Articles/964735/

Radicle: peer-to-peer collaboration with Git

mathstuf — Tue, 09 Apr 2024 19:22:43 +0000

I've really liked Zulip better than Discord, Slack, or (heaven forbid) Google Chat for that niche. The pseudo-email-like threads and per-message read status really helps to keep a tab on things. IIRC, Matrix is far closer to IRC as a "stream of consciousness" and overlapping conversations are really hard. Or the rooms I've been in are mostly just IRC-alikes and other features are newer than those experiences or were unused by them.

Radicle: peer-to-peer collaboration with Git

mirabilos — Sat, 06 Apr 2024 15:56:27 +0000

If “written in $language” is a problem (we have massive trouble with librsvg, python-cryptography and now also gstreamer on *numerous* ports architectures *on top of* the t64 transition), then, yes, merely that is a good enough argument in my book ;)

javascriptless viewing like Gitea, Codeberg, and Sourcehut have?

Curan — Fri, 05 Apr 2024 23:23:03 +0000

Hm, I do wonder if this is a real issue, considering, that you deploy a node locally? Haven't checked the project out in detail yet, so I am mostly thinking out loud here.

Radicle: peer-to-peer collaboration with Git

Curan — Fri, 05 Apr 2024 23:20:43 +0000

Oh, come on. You can do better. (And I might just be taken the bait as a fellow DD here, though you are way more active than me.)

Rust has several very good concepts. And it does promise some solutions for issues in other languages (especially C/C++, ASM or similar). That said: Rust also has a ton of issues, not least of it being based off LLVM and not having any other implementation (the project for adding Rust to GCC is many versions behind and has major hurdles to climb yet).

But I would always expect a better critique than "written in $language".

Radicle: peer-to-peer collaboration with Git

Curan — Fri, 05 Apr 2024 23:14:54 +0000

The project in general looks very promising and I have a couple of private projects in mind, where this could be really helpful (at least if some of the mentioned missing features are added). The choice of Zulip is – at least to me – baffling though. Isn't Matrix the better choice in general? It has wide client support, the protocol is based on the proven solid Signal protocols and supports also large communities (depending on size you might even get away with a non-selfhosted server or put differently: that might be more than enough for you).

The "Crypto Bro" closeness would make this project suspect to me, if I didn't know Lars and trust him.

Radicle: peer-to-peer collaboration with Git

ceplm — Tue, 02 Apr 2024 06:30:25 +0000

I was trying to play with Radicle over the Easter weekend while porting Bugs Everywhere to Python3 (seed available). I have the same feeling about it as with IPFS: something which may be very important for somebody, but for anybody normal it introduces just a horrible amount of complications in between my code and the Universe with no clear benefit for me.

Also, the thing is somewhere around the Proof-of-concept stage and it is horribly unusable. For example, I have not found a way here how to switch from this view to the python3 branch, where all porting happens.

CGit on my server (or Gitea, if I want to be presumptuous) is just enough for me, https://git.cepl.eu/.

Radicle: peer-to-peer collaboration with Git

spacefrogg — Mon, 01 Apr 2024 12:07:27 +0000

1. It would not be handled at all. The commit message is just immutable data. So, unless you functionalize it again by defining special syntax and semantics that interprets "Reported-by: " content, it would not be replaced by anything in the future.

2. All content inside commit messages is handled as described in 1. It could be considered a widespread mis-use of commit messages to bake ill-defined semantics into them and apply social norms on top. That is not what they are supposed to be used for or what their data model can meaningfully support. This means they will always break current or future social norms one way or another.

Radicle: peer-to-peer collaboration with Git

gray_-_wolf — Sun, 31 Mar 2024 14:40:00 +0000

The pijul's use of keys is interesting, however raises few questions the link does not answer.

1. How are people "from outside" referenced? For example, I (not a pijul user) report some bug via email. In some projects, adding Reported-by: X Y into the commit message is customary. How would that be handled?

2. And follow up on the same topic, are any references to usernames/emails in commit messages (reviewed-by, co-authored, ...) automatically replaced by the corresponding key? Or is that left as an exercise to the commit author?

Would you happen to know the answers?

Radicle: peer-to-peer collaboration with Git

mricon — Sat, 30 Mar 2024 14:29:17 +0000

I am not directly involved in the project, but I was an early adviser to them when they were just starting out, and the common goal was to build a system similar to the one I envisioned. So, the similarity you see is intentional.

I bowed out when the project went on a weird cryptocurrency bend. Thankfully, that has been massively deprioritized (but not abandoned altogether).

Radicle: peer-to-peer collaboration with Git

westerntelegraphic — Sat, 30 Mar 2024 08:11:15 +0000

> People do also change things like names for a variety of reasons and usually really appreciate those names not lingering in old issues forever

This is a already a problem with anything built on top of git -- the Author and Committer headers contain user.name. Pijul has a much better solution: it identifies users by an ed25519 key (which is part of the commit-hash). There is a separate, ephemeral mapping from ed25519 keys to human-readable names (each signed by the key of course) which is not part of the hash chain: https://pijul.org/manual/keys.html

In fact, pretty much all the complaints you made apply equally to git itself: "Git security" -- obvs. "Data size: Lore.kernel.org rotates git archives" -- as a convenience; their size hasn't been a problem as you predict it would. "Moderation: Having this floating cloud of contributor nodes without seemingly any mechanism for proper moderation is just negligent" -- that's exactly what the commercial software industry said the problem with open source was, back in the 1990s.

And yes, we get it, you don't like cryptography.

javascriptless viewing like Gitea, Codeberg, and Sourcehut have?

westerntelegraphic — Sat, 30 Mar 2024 07:56:32 +0000

Hi, cool project!

Please do consider making the UI at least minimally functional with javascript turned off. Gitea, Codeberg, and Sourcehut all let you browse a project's files with javascript turned off. The radicle web interface just displays a blank page :(

PS, there does not appear to be a git tag for the 1.0.0 (or 1.0.0-rc1) release.

PPS, you might be interested in crate2nix. It puts every crate is its own derivation, so it can do two things crane can't: (1) builds of your dependencies can be distributed across multiple machines and (2) build artifacts can be reused by multiple different dependers. I ran `crate2nix generate && nom build -f Cargo.nix workspaceMembers.radicle-cli` from a checkout of your project at 345fa57b and it worked fine, spreading the build across eight machines in parallel. Note: I had to turn the cross-crate-boundary build.rs symlinks into copies.

Radicle: peer-to-peer collaboration with Git

mirabilos — Sat, 30 Mar 2024 06:53:27 +0000

“… written in Rust”

Thanks for the warning, I stopped reading there. Saved me time.

Radicle: peer-to-peer collaboration with Git

salimma — Sat, 30 Mar 2024 02:42:07 +0000

I feel similarly - this reminds me of SQLite's Fossil SCM (not in design, but in having your issue tracker and forge be portable), but with the advantage of being based on top of a more widely used SCM

Radicle: peer-to-peer collaboration with Git

leromarinvit — Sat, 30 Mar 2024 00:10:46 +0000

This reminds me of Konstantin Ryabitsev's 2019 blog post Patches carved into developer sigchains (which also spawned a rather lengthy discussion thread on LWN). And while I haven't looked at either protocol in any detail, Radicle's protocol guide mentions inspiration drawn from the "Secure Scuttlebutt" protocol Ryabitsev proposed to use.

Ever since I read that blog post, I've wished for something like its fictional decent tool to become reality. I'm glad it seems to be getting closer! (And I'm wondering now if rad is an intentional pun on decent...) Radicle is probably not perfect yet, and the very first comment here brings up some legitimate areas of concern. But I don't see why these couldn't be addressed in some way.

Let's hope we'll one day have a viable alternative to centralized forges that's easy enough to use that it can have a shot at becoming the de-facto default that GitHub currently is!

Radicle: peer-to-peer collaboration with Git

dilinger — Fri, 29 Mar 2024 18:37:16 +0000

Hm, way to close to Radicale (the CalDAV/CardDAV server). That's going to get confusing. :(

Radicle: peer-to-peer collaboration with Git

comex — Fri, 29 Mar 2024 18:18:09 +0000

I've always wanted to use a tool like this. By itself, Git has such a nice decentralization story which makes it resilient in all sorts of scenarios:
- your Git hosting service enshittified and took your data hostage
- you just want to switch hosting services for some other reason
- your hosting service suffered data loss
- you don't have an Internet connection and need to work offline temporarily
- your hosting service got a DMCA notice (...this is a concern for everything from youtube-dl to Nintendo fangames)

It's also usually faster to access local data than a remote server.

Git was originally designed to be paired with mailing lists, which have more or less the same resilience. Everyone on the mailing list has an archive of all mail from the list (if they don't delete it), and if the list goes down, it's not too hard to set up a new one.

But then GitHub ruined it by adding centralized issues and pull requests.

I'm not a mailing list revanchist; I think GitHub won by providing a legitimately better experience. I just want to recover the decentralization.

So I'd like to use a decentralized issue/PR tracking system for my projects. However, I highly value accessibility and drive-by contributions, so it's essential that users shouldn't be required to use any new tool in order to access and contribute issues and PRs. There should be a nice web UI that can do most of what GitHub does, *in addition* to a local tool for more advanced users. Sounds like Radicle is partway there, but the inability to contribute using the web UI is a blocker for me. I hope that gets improved soon.

Radicle: peer-to-peer collaboration with Git

atnot — Fri, 29 Mar 2024 14:26:31 +0000

I have to say I have some immediate strong concerns with this, besides the involvement of cryptocurrency stuff, although it does inherit some of them directly from cryptocurrencies:

Immutability of data: Having an everlasting, unchangable, signed database anyone can write to is rarely actually desirable. Among other things like dire consequences for pasting the wrong thing from your clipboard, it opens up endless vectors of abuse and harassment. That immutability might seem a lot less nice when someone starts posting pictures of your front door or CSAM and other illegal imagery to your issue tracker when you merge something they don't like. People do also change things like names for a variety of reasons and usually really appreciate those names not lingering in old issues forever or having to nag hundreds of repo maintainers to change them. That's not to say that none of these issues can't be narrowly fixed individually, but that the real world is usually far more mutable than this type of model allows.

Git security: Git has had a relatively constant stream of security issues that allow compromising local machines with malicious git archives. Usually this isn't a huge issue, because the people who can commit to repos are relatively trusted and/or the repo contains executable code anyway. But when everyone is constantly pushing and pull from git repos just for issue tracking, that becomes a lot more risky.

Data size: Similarly to the other two issues, one might imagine a situation where two users get into an endless offtopic argument, or some jokester posts the entire bee movie script or a uuencoded version of the shrek movie as a comment. Even non-maliciously, one might want to show a screenshot of some buggy behavior, or upload some long logs. This is now part of the eternal record, so it must be downloaded forever by everyone who wants to look at your issue tracker now and into the future. Lore.kernel.org rotates git archives regularly for this reason, but that's only possible because it's just an achive of emails sent and not the entire current and historic state of a working issue tracker.

Moderation: again, see everything above. Having this floating cloud of contributor nodes without seemingly any mechanism for proper moderation is just negligent and a non-starter for public collaboration. This might work in a scenario where everyone is trusted in the first place, but in that case there's really not any need for this rigmarole in the first place. And if fully public collaboration is out of scope, it's not a fit to replace any of the centralized services.

Given the existence of a cryptocurrency token behind this, I suspect the solution to this is supposed to be tokenized aligned incentives whatever. I'll just nip that in the bud and say that cryptocurrencies have all of these issues even by themselves and paying in some wildly fluctuating crypto token to open a bug report instead of just, say, sending an email will not sound appealing to anyone who isn't current hungry to dump said token on someone else.