Was hoping for some clarification :) this isn’t Nostric so would you mind explaining how one could send an event without pubkey? I imagine if we have AUTH implemented then it can be picked up from there and you can save some bytes, but other than that… care to elaborate a bit more?
Discussion
Mine noteID’s instead of pubkeys!!!
If I have to mine a pubkey then I have to create a new account just for your relay which is silly.
But if I only have to…
err how are note ID’s allocated?
No need to shout. Remember this is an experiment running for less than 24hr and no one owes anything to any body.
Sorry for shouting. I’m genuinely interested in what you’re doing.
Would you have to blacklist spammers faster than they can mine new ID’s, feels like a manual v’s automated battle.
Also blacklisting is always going to affect some innocent people and is maybe a slippery slope to censoring. Is it censorship?
But how are note ID’s generated?
I guess the typical user sends <500 notes per day, whereas the average spammer needs to send 100,000’s before they realise any value.
There are two dimensions that spammers exploit
1). The ability to create unlimited accounts essentially at no cost.
2). The ability of a single account to create unlimited notes very quickly.
You could even have a difficulty curve for noteID’s maybe your first 50 notes are free, then for next 50 you have to mine 8 zeroes, then next 50 you need 16 zeros, etc.
Probably a combination of leading zeros for pubkeys and noteID’s is enough to make spam preclusively expensive, without having to manually blacklist anyone.
Not sure how I’ve posted triplicate.
I like your ideas. BUT the reality is that zero popular Nostr clients allow mining events today to my knowledge. There’s no way to know how much PoW is required by a relay either other than mining and sending until it gets accepted. But we are connected to many relays… So now you would need PoW for every event to match the relay that requires the most PoW.
I really can’t run an experiment when there’s little support from clients.
At least public keys can be mined independently by users.
Yes, hypothetically I guess in the future a sophisticated spammer would build their own client and wardial accepted pubkeys and use those pubkeys until they are exhausted.
I guess nobody follows spammer pubkeys, so spam is mostly a problem for General channels and discovery of new pubkeys to follow. My own feed has no spam, because I don’t follow any spammers.
Spam is also bad for new users as General channels and pubkey discovery are the main place for new users.
But you’re right, for noteID’s it would need to be the client doing the POW after the user hit send.
You’re also correct that for it to all work in a standardised way across the network it would have to be a part of the protocol.
I’ve proposed a solution for reducing spam on Global Feeds, such as Adaptive Proof of Work: https://observablehq.com/d/295d8a1c6f7b07f9
Perhaps there are simpler solutions but this one proposes using a Proportional-Integral-Derivative Controller (aka PID Controller) to tune the PoW required so that the rate of events stays under control. What it does is find the correct PoW required to maintain a reasonable rate of events (e.g. 1 event / 10 seconds).
PID Controllers are used to control robot limbs, dam gates, etc.
IMO it should only be applied to public keys that are detected to be abusing.
I was also proposing the idea of relays gossiping about spammers, once a relay considers an IP or pub key to be spamming, it sends an event including the pub key or hash of the IP and proof of the spam (merkle tree proof of event ids of the abuse) to other relays which can then be on alert. This didn’t get too much traction but I might implement something soon for Nostream relays… it will be opt-in of course.
Don’t forget aggregate PoW over time. I think it could be really useful for low hanging spam.
Sorry for shouting. I’m genuinely interested in what you’re doing.
Would you have to blacklist spammers faster than they can mine new ID’s, feels like a manual v’s automated battle.
Also blacklisting is always going to affect some innocent people and is maybe a slippery slope to censoring. Is it censorship?
But how are note ID’s generated?
I guess the typical user sends <500 notes per day, whereas the average spammer needs to send 100,000’s before they realise any value.
There are two dimensions that spammers exploit
1). The ability to create unlimited accounts essentially at no cost.
2). The ability of a single account to create unlimited notes very quickly.
You could even have a difficulty curve for noteID’s maybe your first 50 notes are free, then for next 50 you have to mine 8 zeroes, then next 50 you need 16 zeros, etc.
Probably a combination of leading zeros for pubkeys and noteID’s is enough to make spam preclusively expensive, without having to manually blacklist anyone.
Sorry for shouting. I’m genuinely interested in what you’re doing.
Would you have to blacklist spammers faster than they can mine new ID’s, feels like a manual v’s automated battle.
Also blacklisting is always going to affect some innocent people and is maybe a slippery slope to censoring. Is it censorship?
But how are note ID’s generated?
I guess the typical user sends <500 notes per day, whereas the average spammer needs to send 100,000’s before they realise any value.
There are two dimensions that spammers exploit
1). The ability to create unlimited accounts essentially at no cost.
2). The ability of a single account to create unlimited notes very quickly.
You could even have a difficulty curve for noteID’s maybe your first 50 notes are free, then for next 50 you have to mine 8 zeroes, then next 50 you need 16 zeros, etc.
Probably a combination of leading zeros for pubkeys and noteID’s is enough to make spam preclusively expensive, without having to manually blacklist anyone.
Yes, you would have to select the people you authorize to use the relay. But more importantly, clients will also receive events without a public key. So, clients are forced to download Global and verify all incoming messages against their small list of keys (followers).
This creates an ecosystem that is much harder to associate with the identity of random events online. You can't simply query a relay for all messages from a user. You have to download everything and do the work.
Imagine if the protocol removed the pub key field. Now, no event is verifiable unless you:
- Verify every message against all Nostr profiles - all keys (proof of work)
- You have a small list of friends and you only verify their messages.
Sounds like a brand new protocol: Monerostr
I couldn't find the NIP that says pubkey is a required field. :) So... 🤷
It doesn't say pubkey is required. Some of the other fields are definitely not required (we have seen events without tags). So.. Maybe it's still open to an experiment? :)
It’s hard to tell if you are being facetious or just joking. Probably joking because of the emoji at the end xD You are joking, right?
Related to the idea? No. I think it would be a better social network.
Related to the spec? Kind of. Specs are hard. If you leave it open, somebody will create and start mixing their events with the regular events in the network. And NIPs are trash right now.
I seriously hope that questions like these can help solidify where the community is and change the spec for the better.
I think NIPs could be worded better, but more words don’t necessarily mean it’s better. Look at DID wall-of-text and the first thing that comes to mind is: I don’t have time to read all this crap.
If you have suggestions on the NIPs to improve wording and make things more explicit I and you I ask you to please submit your recommendations on a PR. This is the only way things can get better is by people pitching in.
It's not about the wording. It's about clarity. NIP authors simply have not had enough clarity themselves to know where the boundaries of the protocol are. And boundaries are the only thing that matter in specs.
I agree, DIDs went overboard. And yes, I am submitting PRs.
Thank you for the PRs. This is a community effort after al!
Discussion is up https://github.com/nostr-protocol/nips/issues/135
💀
🤔