|
|
Subscribe / Log in / New account

Radicle: peer-to-peer collaboration with Git

Radicle: peer-to-peer collaboration with Git

Posted Mar 29, 2024 14:26 UTC (Fri) by atnot (subscriber, #124910)
Parent article: Radicle: peer-to-peer collaboration with Git

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.


to post comments

Radicle: peer-to-peer collaboration with Git

Posted Mar 30, 2024 8:11 UTC (Sat) by westerntelegraphic (subscriber, #132321) [Link] (2 responses)

> 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.

Radicle: peer-to-peer collaboration with Git

Posted Mar 31, 2024 14:40 UTC (Sun) by gray_-_wolf (subscriber, #131074) [Link] (1 responses)

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

Posted Apr 1, 2024 12:07 UTC (Mon) by spacefrogg (subscriber, #119608) [Link]

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

Posted May 14, 2024 0:31 UTC (Tue) by zaitseff (subscriber, #851) [Link]

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

Posted Sep 19, 2024 22:14 UTC (Thu) by Spudd86 (subscriber, #51683) [Link] (1 responses)

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

Posted Sep 19, 2024 22:19 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]

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.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds