Sure! There is no reason not to have it. I just don't know what it achieves besides burning the battery. But people could find usage in the future.
Hey nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z - could #Amethyst support Proof of Work?
Discussion
The first and foremost that comes to my mind is PoW being one of many parts in spam prevention. I, personally, see it as a bit of "proof of a human having spent some time".
Who knows what else people might come up with in the future! :)
I don't know where this idea of "PoW prevents spam" started but we have got to stop it. Spammers have way more computing power than any human in this platform. Spam businesses can easily pay for computing power to outpace any phone by orders or magnitude.
Sure, and so their difficulty requirements to write notes will keep going up on relays that want POW.
Maybe, but then they will just stop accepting events from phones because there is little a phone can do to compete with full-blown GPUs in hash power.
We're missing each other. The difficulty requirement isn't for any event written to that relay, it's public key specific. If a user is spamming, or the public key is new to the relay, the requirements for that user are raised.
Well, PoW in Nostr (NIP-13) is per event.
Pubkey PoW also doesn't solve spam. Sure, It's easier for people to send posts from a phone, but if relays change the difficulty, there is no good way for people to migrate their content to a new key. Especially DMs, notifications, zaps etc that require each sender to resign all their past messages to your past key, but now tagging the new key.
Sorry, I'm confused, why would a change in relay difficulty force people to migrate content to a new key?
Computing power gets cheaper over time (specially from these early days). Difficulty adjustments are inevitable.
Yes, but why would old notes need migrating? The relay, at the time of writing, puts up a difficulty requirement, and the note gets written. Raising the difficulty on that pubkey only applies to future notes, it shouldn't require reposting old content to meet the new difficulty target.
But if I want access to the notes in my past key, I need to migrate them to the new key. Otherwise, apps will only show the new content. And if there is something I know about users is that they love their past content.
I'm still confused why we're talking about old and new keys? Are we able to migrate notes from one pubkey to another as though the new key posted it? This is my nth pubkey, I would've liked to know 😂
Yeah, you and your friends just need to resign everything. It's not that hard.
People don't want to lose their data on a key change. So, we need migration. It's a must have. And maybe PubKey PoW relays is what will get them done.
What would a regular note look like, before and after a migration like this? Can you provide a real example? Curious what it looks like, and confused as to why if you're having to recreate a note as though the new key posted it, why providing a new POW value is not an option at the same time. The pubkey, sig, id, etc all change anyway?
With this tool, you can offer PoW pubkeys. But we don't have the migration tool yet and you can't assume we will have until somebody makes it.
Right now, PoW keys are just a cosmetic benefit.
To satisfy relays that require proof of work in order to write. Presumably there will be "POW relays" that accept any note but rebroadcast having done some POW. That way Androids aren't exploding.
POW is linked to the event. You cannot re-broadcast the same event with a different POW. The POW relay will have to re-sign it and thus it cannot be a relay since it will have to store the private key. We need a different structure to do this. Maybe a Data Vending Machine.
I don't know what DVM's are or how they operate, and at this point I'm too afraid to ask. But I see your point - the note has to include proofwork in the event, and the whole thing is signed. Is it then down to sending the note "draft" to this POW worker, it sends back some kind of nonce/data, and the client then sends off the final event? Amethyst would handle this asynchronously in the background.