| This is a great idea and exactly what software development needs right now. However there are a lot of things that seem more complicated than necessary. https://radicle.xyz/guides/protocol I'm reading through the delegate consensus model for branches and I don't see why any of that is necessary. It's encroaching on the P2P that Git already does well, which is who I decide to push and pull from. I think this project could learn a lot from the KeyBase model, which is to just be a transport for Git. - Nodes in the network should host local Git remotes. In Git you would configure the remote (origin is the conventional default) to be the address of the local Radicle daemon + a public key for the device that owns it + the repository name. Something like `http://localhost:<radicalport>/<device_id>/repository_name`. If the device_id is the local device then it stores the repository internally, otherwise it calls out to the P2P network. - You can add multiple remotes to a Git repository, so you could have a remote for each copy of the repository on each Radicle device you care to sync with. Git push pull just works. - You can use the very simple regexp branch protection model that GitHub and friends use on each device. e.g. master in MyRepo on DeviceA only allows pushes from DeviceB. DeviceIDs become the primitive for authentication. Groups of Device IDs become users. - There is plenty of existing tooling for managing mirroring and syncing on top of Git. What we are missing is a way to securely push and pull between arbitrary devices on the network by cryptographic id. e.g. I'm on my laptop, I want to pull from new-feature4 on my friend's desktop, I know its public key, not its IP address, and I know the branch name, figure it out for me. - This doesn't mean that the source of truth device has to be online to access the repository. Since there is a single source of truth it can sign any changes, and everyone interested can cache those changes, using the signature to know the refs are legitimate. |
What you are saying is basically "why automate things if you can just do them manually". But worse is not better; there is value in having the P2P transport layer work _transparently_. If you intend to force user to manually (or semi-automatically) juggle remotes for every single device on the network, you have already lost.
TL;DR What you describe is just Git on top of a generic P2P overlay network. I'm sure it can be done (and I might even believe it could be enough for some limited use-cases), but it is not Radicle.