Are my ideas always followed by a ā???ā ???
Discussion
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?
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
š
š¤