Anybody else getting tons do spam replies with fake accounts and invalid nip-05’s? I’m thinking if relays refused to accept content from npub’s that were impersonating other people’s nip05 it would help.

Reply to this note

Please Login to reply.

Discussion

Not that much so far. Just some reply guys

same here. Report spam doesn't fix a lot 😕

Only if I disable my spam filter. Then yes I see lots of impersonations with off-topic junk.

I prefer if the relays do spam filtering, but gossip does it pretty well now even if they don't.

Unfortunately Amethyst has become unusable for me now.

Yeah I think we need both relay and client filtering and settings. We need better management tooling for both.

I was thinking the same thing. In fact instead of what I was planning to work on next, I'm going to build the moderation tool website for chorus.

Back in June I did some work with fiatjaf on NIP-86 https://github.com/nostr-protocol/nips/pull/1325 to create a uniform interface between relays and management software. And chorus supports it on the backend (at least partially). But I'm unaware if anybody has built a NIP-86 front-end web tool designed to moderate relay content yet (showing a queue, 1984 reports, detecting impersonation, etc, etc). So tomorrow I'm going to write some VueJS, something I haven't done for awhile. But I can already tell it is going to be a big project in its own right and so many other nostr devs... someone must already be onto this, right? Do you know of any? A fuck it, I'll just do it my way anyways. I've never been cured of not-invented-here-syndrome.

ive had a mod portal and api for a while, pre86. i will add nip86 support at some point..

people dont seem to use active moderation very much, as its far more efficient to use lists and lightning payments than to sit there deleting infinity replyguy like a nostr caveman 😂 once you start battling with spam a bit more you may have a similar realization.

yeah I like your take on it, I was thinking a very simple API like client requests relay’s metadata - response shows supported NIPs etc. and then some general-purpose key:value interface for arbitrary data?

Something small that could still be put behind an npub interacting via NOSTR itself as the interface, eventually, i.e. silent DM the relay API queries and commands, ecash 🥜 optional 🤔

I have been reading the nip 86 thread and looking for management tools, and trying to figure out the chorus command line that has no docs yet. I thought Gossip was awesome, but Chorus! wow. PoW and WoT will be forged using the gossip model.

I agree. Relays can work at the network level by eliminating the most obvious attacks, while clients can offer fine-tuning preferences to strengthen filters as needed.

That is a really good point. It is not just binary valid and invalid, but the server response carries much more information. Simple 404 is less severe than a completely different pubkey being returned.

Or do a quick Wot filter: for each user do a req for the last event that has a p-tag to that key from you or one of your follows.

make sure to check for the content of the interaction as there might be some ⚠️ reactions there 🙃

Yep. Reports, mute lists, and other negative reactions also create these events that cite spam keys. So, you still need to apply the rest of the clients filters to the results as usual.

Remove some not known relays in your list

💯

I don't understand why NIP-05 isn't signed:

https://github.com/nostr-protocol/nips/blob/master/05.md

"""

Identification, not verification

The NIP-05 is not intended to verify a user, but only to identify them, for the purpose of facilitating the exchange of a contact or their search.

"""

but we could easily add a signature field, otherwise the profile process is less secure than the signed-event model. Unless I missed something?

Interesting! How would that work in detail? Place a signature in the JSON of the NIP-05 server?

NIP-05 should be use to identify an user, not to verify it. A signed NIP-05 would be rendundant.

How would you verify that? Anyone can put someone else's nip-05 user in their profile. The client just checks if .well-known/nostr.json?name=username is present, right?

And it will find a mismatching public key.

Of course! You're right. So, if relies were to verify the accounts npub matches that in the JSON, it should be fine, right?

Yes, it's what clients currently do.

t-y

Dark Star's (1974) Bomb #20 already got it right: "You are false data, ... therefore I shall ignore you". – https://m.youtube.com/watch?v=S-xUjmJkO8g&t=11m14s

This Reply spam seems little bit different than regular RplyFamily. It was targeted to more certain users (popular users).

I think we need more "Smart clients and Smart relays" here to solve the issue. Clients can show it clearly when the person have invalid NIP-05 (impersonators) while relays might probably filter them out.

Yep 😒🙄

yeah, impersonators are getting crazy and the audacity to slide on your dms! lol ☺️🤣

Inspired by nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 idea, #Nostr relay implementation #Nosflare has been updated to v4.22.25 with NIP-05 validation! In order to publish an event, a valid Nostr address must be stored for the pubkey's latest kind 0 event. If none is found on the Nosflare-powered relay itself, it'll fallback to an external relay (nostr.band) to check. There's also option to allow or block specific domains. Test it out now using wss://relay.nosflare.com

https://github.com/Spl0itable/nosflare

note1lphqcapvylxw75xwlwjr6pte27nyv546njf2d05ms75m5qe4q0aqc2zqme