Comment by 0x3o3
3 months ago
Radicle is architecturally local-first: you run your own node, sync repositories from a P2P gossip network, and then everything—browsing code, creating issues, reviewing patches—happens against your local data store. There's no round-trip to a server. Issues and patches are stored as signed Git objects (COBs) that replicate with the repo itself. The network is only involved when you choose to sync. This makes it extremely performant for day-to-day work and fully functional offline.
Tangled to my understanding is federated in theory but centralized in practice. It relies on "knots" (servers that host Git repos) and a central AppView at tangled.sh that aggregates the network. Issues and social artifacts live on Personal Data Servers, not locally. While you can self-host a knot, the default experience routes through Tangled's managed infrastructure. The architecture is fundamentally client-server: your operations go over the network to wherever your data lives.
That implementation sounds really awesome but it raises a few questions for me (that I didn't immediately see when skimming the landing page although I realize answers might be in the docs somewhere).
I found the answer to one of them (how automatic pinning works) which I'll paste here because others are likely to wonder as well. Related, I assume there's a way to block overly large files if you run a seed node?
> They can vary in their seeding policies, from public seed nodes that openly seed all repositories to community seed nodes that selectively seed repositories from a group of trusted peers.
Suppose I'm A and I collaborate with B, C, ... Z. If I file an issue locally and sync to C, am I able to see if and when that propagates through the network to everyone else? I guess what I'm wondering about is what the latency, reliability, and end user understandability are like when using this to collaborate in practice. Like if I file an issue on GitHub I know that it's globally visible immediately. How does that work here?
Currently, with Radicle still under active development, we already reach convergence times that are negligible for async collaboration (like working on code or issues). Working on a well-seeded repo, my changes sync to ~10 nodes within a tenth of a second and with ~80 nodes within 3 seconds.
This is obviously not fast enough for sync collaboration, like writing on a virtual whiteboard together, but that's also not what Radicle is designed for. Also, if you share larger files (e.g. you attach a screenshot to your issue) the above times might not be a good estimation anymore, but that's the exception for now.
It's really strange to see that people assume that peer to peer networks somehow must be slow. In my experience, since everything runs locally, working with Radicle feels way more snappy than any web interface, which has lots of latency on every so-odd click.
As the network scales, it'll of course take some care to keep the speed up, but that's known and there are a few models to take inspiration from.
It's not that I assume it must be slow, but rather that from experience being slow is a distinct possibility so I know to ask about it. But I also asked about reliability and visibility into the process. The latter is what I'm most curious about.
I'm not meaning to suggest that I have a problem with any of it. It's just that when I see anything P2P that's mutable I start wondering about propagation of changes and ordering of events and how "eventual consistency" presents to end users in practice. Particularly in the face of a node unexpectedly falling off the network.
I realize I could browse the docs but I figure it's better to ask here because others likely have similar questions and we're here to discuss the thing after all.
3 replies →