Radish alpha
h
rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
Radicle Heartwood Protocol & Stack
Radicle
Git
How to delete a repository?
Open did:key:z6MkkshL...kZ9u opened 1 year ago epic=expiry type=feature

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

fintohaps commented 1 year ago

Hey!

Glad you like what you see :)

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.

Currently, there is no mechanism for something to be removed from the network. The best one can do is rad clean to remove all remotes from a repositories reference tree and then rm the 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 :D

I 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.

Thank you, and apologies for spamming the ecosystem with my test repo, 😉

lol, everybody is out here doing it :P

z6MkkshL...kZ9u commented 1 year ago

Thanks for your reply 🌼

I 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.

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() == 0 or 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 (perhaps rad 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.

fintohaps commented 1 year ago

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.

levitte commented 1 year ago

@fintohaps says:

… however, that could introduce the potential for a class of bugs.

… and any specialised protocol comes with its own issues ;-)

However, going with the garbage collection idea, I can see the following issues:

  1. 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.

  2. 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?