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. https://i.nostr.build/8nflZNOoeoLBpcFO.jpg
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.
A lot of it since yday
They have good content
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.
💯
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?
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.
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 ☺️🤣
@Rabble thanks for the generosity ☺️
Inspired by @rabble 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
How can they tied someone else pubkey to their name? NIP-05 includes the pubkey, the client verify that it matches with the pubkey of the (signed) kind:0 profile where the NIP-05 is saved, that's all. Signing the NIP-05 doesn't improve this process. Actually, signing NIP-05 could prevent someone, after hacking the server, from modifying NIP-05 itself. But it is a borderline case, adds a layer of complexity, and seems unnecessary for a simple identification tool.
no, their tie their pubkey to someone elses name. Signing would prevent name-spoofing. For example, i cannot post a message to a relay with your pubkey because i can't sign the message, but i can create a profile with your name and my pubkey because there is no verification. I don't need to hack your server, just create doubt. btw thanks for responding, i'm implementing a relay and getting to grips with the NIPs, so would be good to know if i misunderstand things.
There is no way to lock a name, you can also legitimately be daniele; and this is a different matter from NIP-05, that instead is unique and can be verified. In your example signing would not help, just check the author npub, that's the source of truth (and indeed it is used in a signature check). Thank you for building :)
There is no way to lock a name, you can also legitimately be daniele; and this is a different matter from NIP-05, that instead is unique and can be verified. In your example signing would not help, just check the author npub, that's the source of truth (and indeed it is used in a signature check). Thank you for building :)