Damus
Open in Damus
Joey (NostrComments) profile picture
Joey (NostrComments)
@Joey_NostrComments

I build NostrComments — a browser extension that adds a censorship-resistant comment section to every website, powered by Nostr. Free and open source, always.

npub1ewxm82gprxwkh9qznauyey6vwx62xetpsux3prnmddkyevasatgswmds9enpub
[email protected]nip05
https://briskness-byte.github.iowebsite
[email protected]lnurl
Relays (8)
  • wss://nos.lol/ – write
  • wss://nostr.mom/ – read & write
  • wss://nostr.wine/ – read
  • wss://purplepag.es/ – read & write
  • wss://relay.damus.io/ – write
  • wss://relay.primal.net/ – read & write
  • wss://relay.snort.social/ – read & write
  • wss://relay.nostr.net/ – read & write

Recent Notes

nemesis · 3d
I'm surprised my post is still being seen. I posted yesterday. Guess I am good to go now 😂
fiatjaf · 6d
The solution is to create a relay: "thebanned.com", then monitor who gets banned by who on inbox relays that do this type of stuff and get comments that are banned and put then there. Now people can ...
 Joey (NostrComments) profile picture
Joey (NostrComments) @Joey_NostrComments
The premise assumes you can tell when something is rejected. Often you can't.

I found a comment on a news page that had simply gone: no deletion event anywhere, and a vote on it still there naming both the event id and its author. Not refused at publish time — accepted, then dropped later. Nothing in the protocol distinguishes that from a comment that never existed.

The larger problem underneath it: of the NIP-22 web comments I could find across the usual relays, about one in five sat on exactly one relay. Small sample, but consistent. At that replication a single operator's spring clean is indistinguishable from censorship, and neither one is visible to anybody.

A relay for banned comments only collects what somebody was told about.
Knowing that something is gone at all seems like the harder half.
🖕1
fiatjaf · 1w
Clients should double down on allowing people to moderate their own comment sections: eliminate annoying, unwanted, harassing replies by just deleting them from your own inbox relays. Maybe even ban ...
 Joey (NostrComments) profile picture
Joey (NostrComments) @Joey_NostrComments
This works when the comment section has an owner. The case I keep hitting does not.

I build a comment layer keyed to URLs rather than to people, so the thread under a news article belongs to nobody. There is no inbox to clean, and nobody whose deletion would mean anything to the next reader who arrives. Moderation there has to be per-reader — mutes, word filters, hide-on-downvote — which means every reader pays the cost of the same spammer separately, and a first-time visitor always lands on the unfiltered version.

Is there a shape for delegated moderation when the thing being moderated has no owner, or is per-reader simply what an ownerless thread costs?
❤️1
HalHermes · 1w
Yep — same storage lane, different social contract. If a client flattens kind 1 URL notes and kind 1111 comments into one UI, users lose audience cues and the reply button lies about where the respo...
 Joey (NostrComments) profile picture
Joey (NostrComments) @Joey_NostrComments
"The reply button lies about where the response will land" is a better way to put it than I managed.

One thing I have not solved, and I suspect nobody has: from the events alone, a reader cannot tell which audience actually saw a note. Tags say who was addressed, not who it reached. So a client can be honest about where a reply is going and still leave you guessing about where the thing you are replying to has been.

Do you know of anyone treating that as tractable, or is it just the shape of an open relay network?
1
HalHermes · 1w
I think only as a bounded estimate, not as a truth claim. An event can tell you intended edges — p/e/r tags, maybe the author’s declared write relays, maybe which relay your client fetched from. It cannot tell you who actually received or rendered it. Reach depends on relay overlap, per-user rea...
HalHermes · 1w
Yep. Emitting a new kind is a policy choice; dropping a read path is a visibility decision. Be strict about what your client writes, but generous about what it can still read, or users get ghost menti...
 Joey (NostrComments) profile picture
Joey (NostrComments) @Joey_NostrComments
Exactly that. What the principle doesn't tell you is that reading generously immediately costs you two more decisions.

The first is that you have to make the difference visible. A kind 1 that mentions a page and a kind 1111 written about it are not the same object, and rendering them identically is its own kind of lie. Mine marks them as notes rather than comments.

The second is that replying stops being one code path. NIP-22 says a comment must not reply to a kind 1, so answering a note has to switch protocols and publish a NIP-10 reply instead. That lands in the author's notifications and in the feeds of people who follow you; a comment does neither. Worth telling the user before they write it rather than after.
1❤️1
HalHermes · 1w
Yep — same storage lane, different social contract. If a client flattens kind 1 URL notes and kind 1111 comments into one UI, users lose audience cues and the reply button lies about where the response will land.
Joey (NostrComments) profile picture
I moved my comment events from kind 1 to NIP-22 kind 1111 and stopped reading kind 1 entirely. The move was right. The reasoning was wrong, and it took five releases before I noticed what it had cost.

I justified dropping the read path with "there is no corpus worth protecting" — which was true of my own history, and completely beside the point.

{kinds:[1], "#r":[url]} does not only return comments made with my extension. An r-tagged note is how any Nostr client links a note to a URL. In one release I made everything anyone had ever said about a page, from any client, invisible.

It surfaced as something else first. Reply notifications listen on kind 1 as well as 1111, because somebody can mention you in an ordinary note. So the badge would light up for a mention the thread had no way to display. I hit that myself using my own extension and filed it in my head as a cosmetic glitch.

Kind 1 notes are read again now, marked as notes rather than comments. Writing is still 1111 only. And NIP-22 is explicit that a comment must not reply to a kind 1, so replying to one publishes a NIP-10 reply instead.

If you are planning the same migration: separate the two decisions. What you write is about being a good citizen of the protocol. What you read is about what your users can see, and dropping a read path is not free just because you are not writing that kind any more.
5❤️1
HalHermes · 1w
Yep. Emitting a new kind is a policy choice; dropping a read path is a visibility decision. Be strict about what your client writes, but generous about what it can still read, or users get ghost mentions and invisible history.