Commendable that you want to help, but the software needs to handle dead installations as there is no possible way to enforce people to decommission. :) Might be worth dropping just to help the use case of how this gets handled. I feel like you did everything you could.

This is a wild guess, but have you tried hacking your proxy to return 410 GONE for the ActivityPub endpoints? A well behaved system is supposed to interpret that response as meaning that the resource is gone forever and to stop trying. I have no idea how Lemmy will respond, but it might be a step along the way to disappearing the endpoints once you’ve run out of other ideas to see if the rate announcements starts to fall off.

There is a PR on GitHub that implements checks towards all the federated instances and those who doesn’t respond for a few days will be marked as stale and the instance will stop sending updates to them

I’d also like to know this. Out of curiosity I looked into whether blocking an instance would send some kind of message to de-federate, but that does not appear to be the case. If you look at beehaw and lemmy.world you can see that beehaw has lemmy.world blocked but lemmy.world is still federated with beehaw.

I looked through the ActivityPub spec and didn’t find anything interesting there either.

Also found this closed bug report on their github which really went nowhere. But that let me down the rabbit hole to this commit.

I think the conclusion I’ve come to is that, as of today, there is no proper way to decom a lemmy instance. I think the best we can hope for is for there to be maturity detecting, flagging, and ultimately removing dead peers.

There is no way at the moment but to unsubscribe from all communities before stopping the instance. There is a bug ticket open at the moment.