Create a comment censorship service

[johnsBeharry]

There are 2 types of comments that we may want to censor.

1. comments which are spam
2. comments which are against our community policy

How might we do this censorship, when a comment can be posted directly to Nostr? How might we ensure that our readers don't get their browser fetching a large amount of spam comments?

• Load approved comments: How might we reduce the payload, and only request "suitable" comment
• Pagination: How might we perform pagination on large amounts of comments?

[Giszmo]

If you want to censor, why do you use a censorship-resistant platform? Just store the comments in your own DB.

If you actually want to only fight spam, show only events authored by makers and by people that makers follow. That would require the maker accounts to be opened to actual nostr clients that allow following though.

If you decide to only show replies by makers themselves, you again opt out of decentralization and don't need nostr.

[johnsBeharry]

The name was a bit of a joke — to get that kind of reaction you just gave. When I boil it down I consider any hiding of events, with whatever arbitrary/subjective parameters to be censorship. Also, the attempt to dissuade one from using a solution could also be considered an attempt of censorship. It’s my loose definition.

[johnsBeharry]

The whole site is an experiment on data ownership, community, data structures and alternative data stores. I’m hoping from the experiments we can learn about new UX patterns and come up with rationale for why to/why not to…

[Giszmo]

My take on the matter is that proximity matters. Nostr users already can "follow", so whatever their follow say, is not considered spam or they would simply unfollow. Now bolt-fun does accredit "maker" accounts as primarily not spammers. Makers could follow each other or external accounts, too. From there, it's incredibly quick for clients to obtain all the kind-1 events of all the makers, their follows and their follows' follows for example. The comments would thus turn invite-only for clients that work that way. In Nostroid I will define an in-group from the extended follows this way and show out-group only if the in-group reacted to out-group events. Out-group reactions to in-group events would by default not be shown. In the case of comments on stories, this approach should be very simple to implement.