That’s where hashcash came from I believe and same principles here could be used here (using Bitcoin for relays rather than email) that it becomes uneconomical to post excessive spam. FYI nostr:nprofile1qqsqyredyxhqn0e4ln0mvh0v79rchpr0taeg4vcvt64te4kssx5pc0spz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3camnwvaz7tmwdaehgu3dwfjkccte9emkcann9eehqctrv52em09e

That works for encrypted DM type notes. Not sure about public stuff though if the relay remained in the dark about what it’s transmitting unless the message is sharded and that sounds complicated.

Reply to this note

Please Login to reply.

Discussion

Well you're not using "Bitcoin" per se, it's just adding proof of work to messages. Coracle does this. It just uses your computer to do proof of work on a hash of your message.

No reason why it couldn't work for public notes too. Nothing is encrypted.

It's the same kind of thing that Anubis does: Force the user instead of some "captcha" to do a small amount of computational work, that's no problem if it's a human but becomes uneconomical if it's a massive web scraper" https://anubis.techaro.lol/

The only real way to make the relay not know what it's sending but not have everything encrypted is to make the operator unable to communicate preferences to the relay, which means relays in enclaves with attested runtime code meeting protocol spec, and if no proof-of-blind-enclave then not considered protocol compliant.

Yeah, I mean... I wasn't thinking of the relay operator "provably" not knowing what's getting relayed, but rather just the idea of the operator having a general policy of "not caring."

The enclave approach would be close to that, the operator could obviously know what's on the relay, because anyone can query the relay, and the notes are not encrypted. But the op wouldn't be able to do anything with this knowledge, because to change the code of the relay would require breaking the attestation and being booted from protocol compliance. So code-enforced not caring, in a way.

Interesting!