[lorenzleutgeb]

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.

[fc417fc802]

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.

[lorenzleutgeb]

There's `rad sync status` which will show you (for a particular repository) which other nodes have echoed back to you that they have received and verified the most recent state of your namespace of that repository. So, if you expect some other node to have received your changes, you can use this command to verify that.

When the user explicitly asks to sync, then by default the process will be considered to have completed successfully as soon as three other nodes have echoed that they have received your changes. This threshold is configurable. Further, one can define a list of nodes that they care particularly much about, in which case the process will only be considered to have completed successfully if all these nodes also signaled that they have received your changes.

For anything deeper than that, you'd have to resort to logs. And if you connect your node to the other one your are interested, you can get a pretty good picture of what's going on.

If one node "falls off" the network, then the above mechanisms will communicate that to you, or fail after a timeout.

With Git repositories, humans establish order explicitly. They push commits which are a DAG. The collaboration around that (mostly discussions on issues, patches) is also stored in and synced by Git, but here, humans do not have to establish order explicitly. Rather, these things, in Radicle lingo called "Collaborative Objects" are CRDTs, so they will merge automatically. Nodes also opportunistically tag operations on these CRDTs with the latest operation they know, to help a bit by establishing an order where possible.