https://lwn.net/Articles/966869/

LWN.net Logo LWN
.net News from the source LWN

  * Content
      + Weekly Edition
      + Archives
      + Search
      + Kernel
      + Security
      + Events calendar
      + Unread comments
      + -------------------------------------------------------------
      + LWN FAQ
      + Write for us
  * Edition
      + Return to the Front page

[INS::INS]
User: [        ] Password: [        ] [Log in]
|
[Subscribe]
|
[Register]
Subscribe / Log in / New account

Radicle: peer-to-peer collaboration with Git

    Did you know...?

    LWN.net is a subscriber-supported publication; we rely on
    subscribers to keep the entire operation going. Please help out
    by buying a subscription and keeping LWN on the net.

March 29, 2024

This article was contributed by Lars Wirzenius

Radicle is a new, peer-to-peer, MIT/Apache-licensed collaboration
platform written in Rust and built on top of Git. It adds support for
issues and pull requests (which Radicle calls "patches") on top of
core Git, which are stored in the Git repository itself. Unlike
GitHub, GitLab, and similar forges, Radicle is distributed; it
doesn't rely on having everyone use the same server. Instead, Radicle
instances form a network that synchronizes changes between nodes.

As a new project, Radicle is not fully featured compared to the
mature and centralized forges. That said, the Radicle developers are
using Radicle itself to collaborate on the software, along with a
Zulip chat system. The first 1.0.0 release candidate was announced on
March 26.

(Note that I am paid to help develop Radicle.)

Overview

In Radicle, each user runs their own node on each computer they use
for collaboration. The node stores copies of the repositories the
user is interested in, regardless of whether they're created by the
user or cloned from another node. The node process runs in the
background to fetch changes from peers and serve repositories to
peers that want them. To the user, the node acts like a local Git
server. You clone from, pull from, or push to the node and it
coordinates with other nodes.

There is a web interface for browsing repositories, issues, and
patches, and it also allows opening and managing issues. The web
interface can be opened for the local node, or on a suitably
configured server, for any other node. Thus you can inspect any
public node to see if it is in sync with yours.

    [The Radicle web interface]

The web interface looks a lot like the more mainstream forges, and is
meant to feel instantly familiar. You can browse the code, issues,
and existing patches. However, unless you run your own Radicle node
and open its web interface, you can't currently make changes: you
can't report issues, comment on issues, etc.

If you want to clone a repository locally, the web interface provides
two ways: either using normal Git (git clone) and an HTTPS URL, just
like other forges, or having your Radicle node fetch it and clone
from that using the rad command-line tool. You don't need to use
Radicle to get a copy of a repository from Radicle.

    [The Radicle command line interface]

Creating issues and patches -- and commenting on them -- happens using
your own Radicle node. There is a command-line interface, and a web
user interface. The Radicle project is also working on a full-screen
terminal user interface, like Midnight Commander but for Git, and
there is integration with Visual Studio Code and IntelliJ IDEs, among
others.

Motivation

The motivation for Radicle is similar to that of the overall
decentralization movement. The centralized Git forges are popular for
good reasons: they've put in a lot of effort into being easy to use
and efficient, and to provide the kinds of features their users need.
However, they are also not always great for everyone. There is some
truth in the joke that when GitHub is down, the world stops
developing software. Git was the first popular distributed version
control system. Then, the popularity of GitHub made it the most
centralized version control system.

With a peer-to-peer system, if your node is down, you may have to
stop working, but nobody else needs to. More importantly, you don't
need permission to run a Radicle node. Your access can't be revoked.
Your repositories can't be deleted from your node by others. Nobody
will force you to accept an "updated" set of terms and conditions.

Radicle stores issues and patches in the Git repository itself. You
can create, comment, and manage them while offline. Radicle is
local-first software: network access is only required for operations
that inherently require communicating with other computers, such as
retrieving or sending changes. Everything else works without the
network.

Radicle repositories are self-signing, a necessary feature in a
distributed system. While a GitHub repository can be authenticated by
location (it's on GitHub with a given name), a Radicle repository is
associated with a small set of cryptographic signing keys, which
allows its identity and contents to be authenticated regardless of
where the repository is stored.

Radicle's origin traces back to 2017. Its development is funded by
Radworks, an organization that coordinates on the Ethereum blockchain
using a token called RAD. However, Radicle does not use any
blockchain or cryptocurrency technology. Radicle is not the only
approach to decentralized collaboration over Git. ForgeFed is a
protocol built on ActivityPub to support a federated network of Git
servers.

Architecture

Nodes communicate with each other using two different protocols.
First, there is a gossip protocol, where nodes tell each other about
the nodes and repositories they know about, and about changes to the
repositories. Second, they use the Git v2 smart transfer protocol to
exchange repository content.

Each node stores copies of the repository as it exists on each other
node it knows about, using the Git namespace feature and the node
identifier as a name. Each node has nearly identical content, so this
is an efficient way to store the data. To Git, a Radicle repository
is a perfectly normal repository. Radicle uses standard Git
mechanisms to add a persistent repository identity, issues, and
patches. These are stored in special Git refs.

Every repository stored in Radicle has an identity that is the same
in every Radicle node where the repository appears. If there are
multiple copies of a repository stored in a node, each copy has the
same identity, and can thus be identified as a version of the same
repository. This identity is created by committing an "identity
document" that contains metadata about the repository; an example
identity document is:

    {
      "payload": {
        "xyz.radicle.project": {
          "defaultBranch": "master",
          "description": "Radicle Heartwood Protocol & Stack",
          "name": "heartwood"
        }
      },
      "delegates": [
        "did:key:z6MksFqXN3Yhqk8pTJdUGLwATkRfQvwZXPqR2qMEhbS9wzpT",
        "did:key:z6MktaNvN1KVFMkSRAiN4qK5yvX1zuEEaseeX5sffhzPZRZW",
        "did:key:z6MkireRatUThvd3qzfKht1S44wpm4FEWSSa4PRMTSQZ3voM"
      ],
      "threshold": 1
    }

The document includes a description of the repository and its default
branch. The delegates list contains the public Ed25519 keys of the
delegate(s) that are empowered to change the identity document or
commit to the main branch. This document is stored behind the rad/id
ref in the repository. It must be signed by one of the delegate's
private keys. Each repository has a short ID that is calculated from
a hash of the initial version of the identity document. This ID will
not change as the identity document is modified, and can thus be used
to identify the repository over time.

There is no way to prevent anyone from changing the identity document
on their own node and signing it with their own key, bypassing
Radicle. However, other nodes won't accept the change, since it is
not signed by a delegate's key, making such changes pointless.
Radicle also signs the branch and tag refs. The signatures are
refreshed whenever a node changes anything in the repository. This
means that other nodes can verify another node's repository content
without inspecting the other node directly. This helps prevent
forgeries and related attacks.

Issues and patches are stored using an implementation of a
conflict-free replicated data type, which Radicle calls a
"collaborative object", or COB. Any node can append data to a COB,
and changes from different nodes can be merged without conflict.
(Normal git conflict management applies to the rest of the content of
the repositories, however: the user needs to resolve them.) The COB
mechanism in Radicle is generic, and can be used to build further
collaboration tools.

Seed nodes

Any node can synchronize data with any other node, but only if they
can communicate directly. With network address translation (NAT)
being prevalent, this is often not possible. Radicle does not yet
have "NAT punching", but relies on third-party, publicly accessible
seed nodes. This is safe thanks to the repositories being
self-signed: the seed node can't modify the data.

Thus, if Alice and Bob are both behind NAT networks, they can
collaborate via a seed node on the Internet that they both can
access. Unlike with centralized forges, anyone can set up a seed
node. This works especially well for open-source projects that don't
need to keep repositories hidden. If hiding is necessary, a private
seed node and Radicle private repositories can be used. A private
repository is one that's configured to only be shared with specific
other nodes. However, Radicle is not yet a good solution for truly
confidential material: the private nodes are still rather
rudimentary.

Missing features and other challenges

Radicle does not yet have mature support for continuous-integration
systems, although work on that is underway. There is also only
rudimentary support for code review, but that is also being worked
on.

Currently, Radicle has a simple identity system: each node has its
own public key. A challenge for the future is to evolve this into a
more versatile identity system. For example, a developer with both a
laptop and a desktop system would benefit from being able to certify
that both nodes are theirs. Support for groups or organizations is
also missing.

Perhaps a more fundamental challenge is that interacting with a
Radicle repository, even just to report issues, requires using
Radicle. With a centralized forge, all you need is an account and a
web browser. This may be a problem for projects that would like to
use Radicle, but whose users can't be expected to use it.

Conclusion

Radicle is a new and promising decentralized approach to Git hosting.
If you are curious to know more, the guides are a good place to
start. We're also accepting patches and hoping to bring in new
contributors, so if you know some Rust and care about developer
tooling, please join us on our Zulip forum.

Index entries for this article
GuestArticles Wirzenius, Lars


-----------------------------------------
[Log in] to post comments

Radicle: peer-to-peer collaboration with Git

Posted Mar 29, 2024 14:26 UTC (Fri) by atnot (subscriber, #124910) [
Link] (6 responses)

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.
[Reply to this comment]
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.
[Reply to this comment]
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?
[Reply to this comment]
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.
[Reply to this comment]
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.

[Reply to this comment]
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.
[Reply to this comment]
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.

[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Mar 29, 2024 18:18 UTC (Fri) by comex (subscriber, #71521) [
Link] (2 responses)

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.
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Mar 30, 2024 2:42 UTC (Sat) by salimma (subscriber, #34460) [
Link]

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
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Sep 10, 2024 14:23 UTC (Tue) by ceplm (subscriber, #41334) [
Link]

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.
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Mar 29, 2024 18:37 UTC (Fri) by dilinger (subscriber, #2867) [
Link] (1 responses)

Hm, way to close to Radicale (the CalDAV/CardDAV server). That's
going to get confusing. :(
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Sep 11, 2024 3:44 UTC (Wed) by stephenjudd (guest, #3227) [
Link]

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.
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Mar 30, 2024 0:10 UTC (Sat) by leromarinvit (subscriber, #
56850) [Link] (1 responses)

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!
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Mar 30, 2024 14:29 UTC (Sat) by mricon (subscriber, #59252) [
Link]

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).
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Mar 30, 2024 6:53 UTC (Sat) by mirabilos (subscriber, #84359)
[Link] (6 responses)

"... written in Rust"

Thanks for the warning, I stopped reading there. Saved me time.
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 5, 2024 23:20 UTC (Fri) by Curan (subscriber, #66186) [
Link] (5 responses)

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".
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 6, 2024 15:56 UTC (Sat) by mirabilos (subscriber, #84359)
[Link] (1 responses)

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 ;)
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 10, 2024 22:05 UTC (Wed) by Curan (subscriber, #66186) [
Link]

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/>
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 10, 2024 21:43 UTC (Wed) by intgr (subscriber, #39733) [
Link] (2 responses)

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

[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 10, 2024 22:08 UTC (Wed) by Curan (subscriber, #66186) [
Link]

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/>
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 10, 2024 22:19 UTC (Wed) by mirabilos (subscriber, #84359)
[Link]

> 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 non-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.
[Reply to this comment]
javascriptless viewing like Gitea, Codeberg, and Sourcehut have?

Posted Mar 30, 2024 7:56 UTC (Sat) by westerntelegraphic (subscriber,
#132321) [Link] (1 responses)

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.
[Reply to this comment]
javascriptless viewing like Gitea, Codeberg, and Sourcehut have?

Posted Apr 5, 2024 23:23 UTC (Fri) by Curan (subscriber, #66186) [
Link]

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.
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 2, 2024 6:30 UTC (Tue) by ceplm (subscriber, #41334) [Link
]

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

[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 5, 2024 23:14 UTC (Fri) by Curan (subscriber, #66186) [
Link] (2 responses)

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.
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 9, 2024 19:22 UTC (Tue) by mathstuf (subscriber, #69389) [
Link] (1 responses)

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.
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 10, 2024 22:13 UTC (Wed) by Curan (subscriber, #66186) [
Link]

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)
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 11, 2024 13:15 UTC (Thu) by raven667 (subscriber, #5198) [
Link] (3 responses)

> 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.
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 11, 2024 14:33 UTC (Thu) by atnot (subscriber, #124910) [
Link]

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.
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 11, 2024 14:38 UTC (Thu) by Wol (subscriber, #4433) [Link]

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
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 12, 2024 1:45 UTC (Fri) by Cyberax ( supporter , #52523)
[Link]

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.
[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Apr 22, 2024 11:47 UTC (Mon) by massimiliano (subscriber, #
3048) [Link] (1 responses)

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!

[Reply to this comment]
Radicle: peer-to-peer collaboration with Git

Posted Jun 14, 2024 13:28 UTC (Fri) by shackra (guest, #171967) [Link
]

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 
[Reply to this comment]
[INS::INS]


                  Copyright (c) 2024, Eklektix, Inc.
   Comments and public postings are copyrighted by their creators.
          Linux is a registered trademark of Linus Torvalds