npub1jl…jynqn on Nostr: Jameson Lopp is always a good read. He recently reposted this article from 2022 on ...

Jameson Lopp (nprofile…mcme) is always a good read. He recently reposted this article from 2022 on the death of email, and it has tons of great food for thought for nostr devs.

https://blog.lopp.net/death-of-decentralized-email/

> SMTP needed specific rules for relaying mail and authenticating users to prevent relaying unsolicited email.

> The helpful nature of open relays was among the first victims of the spam influx... The SMTP standard, which was designed with reliability as a key feature, had to be modified to purposefully discard certain messages.

> ISPs started to use crude filters based on keywords, patterns or special characters... these measures were still inaccurate and caused many false positives – emails were filtered or blocked even though they were perfectly fine and actually wanted by recipients.

> The next major development in email deliverability included the standardization of reputation scores... Of course, if you're familiar with how these technologies work then you'll notice that... None of these actually provide email senders with any sovereignty.

> Why wasn’t hashcash widely adopted? One reason was that there was a chicken-and-egg problem for it to work; you’d want almost all email users to nearly simultaneously migrate their email clients and servers to start supporting hashcash, otherwise you’d see massive amounts of legitimate emails get rejected for not including valid hashcash headers.

The solution I think nostr has at its disposal that Lopp doesn't identify (because he's not talking about nostr) is that contact lists are public. Maybe this won't always be the case — private follows actually make a lot of sense, and I think some clients support them.

But as long as transitive follows can be calculated, a web-of-trust score for unsolicited messages (DMs and otherwise) can always be derived. This allows relays and clients to skip the hacky content-based solutions and go straight to an explicit trust score, falling back to payments or proof of work to screen unsolicited messages.

New-style sender-obscured DMs make this harder, since this calculation can't be done without the ability to decrypt user messages. This leaves it up to clients to screen DMs, which can be prohibitive if spam becomes a large problem.

But this relies on an overly-narrow definition of what a "client" is. A client can actually be a server-side component, even a DVM that a user authorizes with a bunker provider in advance to provide screening metadata for DMs. This component can be self-hosted, and trust can be revoked easily.

All that said, I think we can do this, but we've got to keep our eye on the ball. I'm hoping to work on some of these problems this year, starting with basic DVMs for aggregating public data to help clients reduce bandwidth requirements, but I also hope to experiment with trusted relay proxies and privileged DVMs.