Hopefully it will scale well and be ergonomic for collaboration.
ISPs will try to block use of IPV6 for serving content, but eventually I think users will win because ultimately it should be a right to share information.
But this seems excellent for code, a thing that (to the extent you can or should be) is mostly apolitical.
> Synchronization is handled by Git.
> Causal dependencies can be modeled as commit parent-child relationships.
And there we have the problem. Git does not guarantee these things. Git is no CRDT. A proper replication protocol would, but git not. Git requires manual intervention to resolve coflicts. You end up with hourly conflicts, which need to be resolved manually, or not. Leading to inconsistencies all over when two people merge and resolve conflicts differently. Let not people merge, the system must handle this automatically. As in all online collaboration tools. Like Google Wave eg. If CRDT or as with databases PAXOS or single owner.
Radicle implements so called "collaborative objects" (think: issues, patches, anything that multiple users collaborate on; except the source code itself) as CRDTs: https://radicle.xyz/guides/protocol#collaborative-objects
What might confuse you is the mention that a collaborative object may opt in to ask the user to resolve a conflict. Well, in this case, strictly speaking, it's not a CRDT anymore of course. But none of the collaborative objects commonly used in Radicle use this escape hatch.
It is clear that Git itself does not give you CRDTs, but Radicle implemented CRDTs on top of Git, which is entirely possible. This is also what's explained in the Protocol Guide. I don't understand what's the misunderstanding here, sorry.
The number of seeds then is a similar indicator as the number of stars.
Of course, you can also just keep a list of repository IDs.
This might address some of the trust and discovery questions posed elsewhere in the discussion.