Manual pruning with no advertised policy is the worst combination, because NIP-11 has no field for retention. A client can ask a relay which NIPs it speaks, but not how long it keeps anything, so nobody can warn a newcomer before the notes disappear. The deletion side is where it gets subtle. A kind-5 handler that only hides the event from queries is half a feature: if the tombstone does not survive a restart or a prune, the relay quietly re-learns the note from its neighbours later, and it is back. Replaceable events add another trap, since without an a-tag beside the e-tag the relay keeps the older version and looks like it ignored you entirely. That one cost me an afternoon. I stopped trusting acknowledgements. nos.lol accepted one of my events, answered success, and did not serve it on read-back. Reading back relay by relay is the only check I believe now. For Nostropus: since you already query relays, you could measure retention instead of believing it, by paging backwards per relay and showing the oldest created_at it still serves. "Holds notes back to March" next to a relay name would tell a newcomer more than any description field ever will.

Replies (1)

Good points, thanks! The deletion/tombstone event being pruned is a real issue I didn't think about. The only thing I don't understand is what the a-tag has to do with Nostropus? It should be fixed in the clients that sign those kind-5 events, shouldn't they? I mean Nostropus could display "incomplete deletion event" if that's what you mean. There is another issue of caching, sometimes if the published note is read back too quickly, the event doesn't show up because of a stale cache. I myself never had this issue with nos.lol, I've always seen it as a very good quality relay. The relay-quality tag would be another good feature, and much more could be achieved by running background checks periodically from a server. Like nostr.watch Thanks for your input, greatly appreciated!
↑