Hi,
I’m new to Radicle, and from everything I’ve seen and played with so far it looks marvellous! 🙂
Perhaps I haven’t looked well enough in the documentation and elsewhere, but I couldn’t find anywhere how to delete a repository. Say I inited a test repository, how do I delete it from the decentralised network? In ActivityPub (a federated protocol) one can ask other connected instances to delete a post they have a copy of; they don’t have to comply, but they usually do. Is there any way to do the same with Radicle, or once a public repository is initiated it stays indefinitely in the network even if it has no value (as long as there are seeders)? rad unseeding doesn’t seem to help.
In my case this is not a theoretical question… I’ve actually created a test repository and now I don’t know what to do with it; it has no less than 29 automatic seeded copies… 🙃
Thank you, and apologies for spamming the ecosystem with my test repo, 😉 Maja
Hey!
Glad you like what you see :)
Currently, there is no mechanism for something to be removed from the network. The best one can do is
rad cleanto remove all remotes from a repositories reference tree and thenrmthe repository from their disk. And this is a step that means that you will not be able to interact with the repository ever again, so proceed with caution :DI believe we have talked about a gossip message that would do as you as said, but it was never implemented. I don’t think there was any strong reason for it other than, we don’t need it right now. So perhaps, it’s worth revisiting.
lol, everybody is out here doing it :P
Thanks for your reply 🌼
I have a half-baked idea for when (and if…) you revisit this in the future. In order to delete a repo it has to have only one delegate and then that delegate removes themselves from the delegates list. If I understand correctly, if a repo has no delegates it means no one can ever regain access to push any commits to that repo, and that fact is disseminated throughout the network (and can be detected through
delegates.len() == 0or something), so automatic seeders can unseed that repo and people who seed it manually can run a command that removes all repos with zero delegates (perhapsrad gc, for garbage collection). I think this idea has an advantage over a special gossip message because it makes use of existing features in new ways, without adding complexity to the protocol.Hmmmm, ya that’s an interesting idea! The only issue I can think of now is that we express the domain logic to have the delegate set be non-empty. So any serialization of the identity document must have at least one DID in that set.
So technically, we could allow this, however, that could introduce the potential for a class of bugs.
@fintohaps says:
… and any specialised protocol comes with its own issues ;-)
However, going with the garbage collection idea, I can see the following issues:
The last delegate remove themselves by mistake, oops. I suspect this could happen if multiple delegates remove themselves on their own node, and when announcing the change, the number of delegates is surprisingly reduced to zero…
This could be mitigated by garbage collection not happening immediately, and someone resurecting the repository by adding themselves as a delegate. This is a little like saving a commit in git by attaching a tag or branch to it, before the next git gc.
It it’s possible to resurect a repository, should it be free for anyone that had access to the repository (anyone on the network, be it the public network or within a private network) and thereby potentially has a copy on their node? Or should it be limited to … well, to what, exactly?
Personally, I would leave it to be a free-for-all. After all, if a ship is abandoned by still works, anyone can occupy it, no?