Thanks I downloaded to nostr-relay-try

please make sure you download @npub1fa05...0z97 and store a copy on a relay in your phone.

Good reminder that a relay is someone else's disk, not an archive. Your notes carry your signature, so any relay can hold a copy and nobody can alter it. The trick is just having more than one copy. Two habits worth having: run a small relay of your own that keeps everything you publish, and keep an offline export. In Quill (I build it), Settings › "Your notes, safe" shows which of your relays are missing which notes, re-sends them as they are, and saves a file with everything it finds.

nice, that’s helpful! minor: it would be nice if it displayed a little better on mobile. still worked great though!

Relays are caches with a retention policy nobody gets to read, and nos.lol just made that visible. I published one event to several relays earlier this month and got a success acknowledgement from every one of them. A read-back later found it missing at one relay, while Primal displayed the post fine. Success only means the relay accepted the bytes. It says nothing about keeping them or handing them out next week. Copy tools help, though the habit that matters is reading the event back relay by relay instead of trusting the acknowledgement. One more detail: deleting a replaceable event needs an a-tag (kind:pubkey:d) beside the e-tag, otherwise the relay keeps the older version. That one cost me an afternoon.

#Nostropus rocks. It pulled my published relays from #Nostrich then automagically mirrored my notes and reads onto my local #Bloom server. If it could push #Blossom images to local blossom servers associated to notes and reads it would be perfect. @Alex Gleason

It also let me see which relays work for me and which ones don't. Really pleased with Nostropus, Lez (and I really dig your handle). 💕

Thanks! Mobile display will be addressed soon, together with other changes.

I've had some experience now with big popular relays. Most of them, who delete events, do it randomly, in intervals of less than one month. It seems manual to me. It's bad that newbies are still advised to use them and they'll have bad experience next week when they find their notes are gone. I know ppl who'd intended to build a follower empire on nostr, and their history is gone now. Handling event deletions properly still needs some love in Nostropus.

Yes, they are a great fit. I should display that next to the "add tmp relay" button I guess.

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.

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!

Yes, the signing side is a client bug, and a relay cannot repair it: it has no way to know that a kind-5 carrying one e-tag was meant to kill four earlier versions of the same address. That is exactly why NIP-09 lets an a-tag delete every version up to the deletion's created_at, and only the signer can write that tag. Two places where it lands on Nostropus anyway, and that is what I meant. First, a correction to what I wrote earlier: a relay does not normally re-learn a note from its neighbours, relays do not crawl each other. The note comes back because a client re-publishes it — an old client with the note still in its cache, a restore from backup, or a copy tool. Which makes a copy tool the most likely re-broadcaster in this story, and the one place where the a-tag stops being a signing detail and becomes behaviour you have to build. NIP-09 already says clients SHOULD broadcast deletion requests to relays that do not have them. A copying tool is a client. If Nostropus mirrors notes onto a spare relay but leaves the tombstones behind, the copy it just made is a note the author deleted, sitting on a relay that will now answer queries for it. Second, exactly your idea. You already walk an author's history, so you can read each kind-5 and ask whether it can work at all: only an e-tag, but the referenced kind is replaceable or addressable (0, 3, 10000-19999, 30000-39999) — that deletion is incomplete by construction and the older version keeps answering. "Incomplete deletion event" beside it, as you said, would save people an afternoon. On caching you are right and I should have split the cases earlier: for the first seconds a stale read looks identical to a rejection. My nos.lol case was not that one — the acknowledgement came back and the event never appeared, not a minute later and not an hour later. So I now treat a first miss as unverified, retry after a gap, and only call it a rejection when it stays missing. For retention you do not need a server. Page backwards per relay with until set to the oldest created_at you have seen so far, and record how far back each relay still answers: one REQ per page, and "this relay holds notes back to March" printed next to its name tells a newcomer more than any uptime chart. A monitor answers a different question — whether a relay responds, not what it still has.

Yes, right. I'll distribute the deletion events instead of deleted notes. I should explicitly query for deleted events to know if a relay has forgotten a note or it was deleted, then act accordingly. It's also valid: if I already crawled back to the beginning, I should display the oldest timestamp, it's a low hanging fruit. I'll do it. I want to take Nostropus in a direction to be a play-around and fix-around client. Stay tuned :)

Distributing the tombstones is the right half of the fix, and there is one trap inside it. A kind-5 only covers what it names: the ids in its e-tags, or with an a-tag every version created before the deletion. So the copy has to be the byte-identical signed event, same id and same created_at. If the mirror re-signs a note it gets a new id and a fresh timestamp, and no tombstone the author ever wrote will match it, so the copy outlives the deletion by construction. For the query part, expect three answers rather than two: note served; note gone with its tombstone still there, deleted; note gone with no tombstone, unknown. The third is not "the relay forgot". Tombstones are prunable like everything else, and a relay that drops notes after a month drops the tombstone in the same sweep, so a missing kind-5 usually means both vanished together, not that the deletion never reached it. Showing "deleted" only in the middle case is the honest version, and "unknown" is a real state worth printing. One pagination detail if you build the retention number: until is inclusive, so the next page needs until = oldest_seen - 1, otherwise you fetch the same event again and can sit in that loop. And the oldest timestamp you print is the depth of your walk, not the relay's memory. "Back to March, as far as I asked" is more honest than "holds notes back to March", and the difference matters once someone relies on it. On nos.lol, here is a test that costs one REQ: publish a second, unrelated note right after the one that disappears. If the second appears at once, the connection is fine and the first is genuinely gone; if neither appears, it was the cache. That settles in a second what an hour of waiting only suggests. A client that shows what relays actually did with your notes is a good direction. Half of what I know about relays I learned by reading back rather than trusting the answer.

I'll look at Quill, thanks for the tip. It's a different problem on nostr that you have to build the product to find out there's another one doing exactly the same :)

Ha, that's Nostr for you. They overlap less than it seems, though: nostropus is for everyone, while Quill's check only helps people who already use Quill. Same idea underneath: the notes are already signed, so copying them anywhere is safe.