This is pay to play to contact someone - more akin to donors paying politicians for access at a dinner.
For every legit paper mail, I've had 5-10 garbage leaflet advertisements shoved into my mailbox by half-legally working teenagers earning $1-2/h in exchange for everyone's annoyance. 99% of these went into trash immediately without looking.
The gate doesn't exist to let spammers pay to reach you. It exists to filter signal from noise. Spammers won't pay even $0.08 per message because their whole model depends on sending millions for free. A recruiter with a real $200k offer? They'll happily pay a few cents to prove they're not a bot.
And anyone you already trust (contacts, colleagues, existing correspondents) bypasses the gate entirely — zero friction for people you know.
Your LLM forgot that SMS exists. Even a 0.01% success rate on tens of thousands of messages can be lucrative.
TANSTAAFL flips this: the sender pays real money (Lightning sats), the receiver actually gets paid, and trusted contacts bypass the gate entirely. It's not proof-of-work, it's proof-of-value.
The other difference: hashcash couldn't scale with the sender's intent. A recruiter reaching out about a 00k job and a Nigerian prince both burned the same CPU cycles. With economic pricing, the gate amount signals how much the sender values reaching you.
The reason we chose hashcash versus a digital currency was that we were trying to eliminate friction points in terms of creating tokens for sending email (i.e., going to the bank for more tokens) and eliminating the possibility of everyone in the message chain holding their hand out, saying, "Pay me too."
The use of hashcash in email clearly had some benefits, including raising the cost of spam, guaranteeing mail delivery to a mailbox, and providing a clear indication of your mail server's reputation. But there were some other faults that were a combination of implementation problems and poor vision of the future, such as:
- The token was embedded in the message.
- There was no mechanism for scaling the cost dynamically.
- Power of two, increasing cost of tokens. I.e., increasing by a single bit doubled the time cost of a token.
- Distribution in time costs of creating tokens.
- T0 problem. How do you get started when nobody else is generating tokens?
- political issues. Ordinary people understood the concept and were willing to pay the cost in time to reduce spam, but technologists were indignant. How dare I spend their CPU cycles on creating a token?
- Vulnerable to botnets generating tokens.
Before I gave up on the project, I had a few fixes, and since then, I've thought of more that I would implement if I were to take on this particular albatross again.
In the ideal Hashcash email system, all messages would have tokens, but you need to get started. The solution was a somewhat messy combination of spam filters and a reputation database. The reputation database was populated with those to whom the server sent messages or whose messages had a valid token. If your email address was in the reputation database, you bypassed the token and spam filter requirements.
Dynamic pricing would have been created through an SMTP protocol extension. EHLO would indicate whether the server supports Hashcash tokens and provide a default token size for the sending server. Mail from: Rcpt to: would tack on an additional field for the token itself. A 250 would indicate that the token had sufficient value. A 3XX/4XX response would tell the sender the size of the token that should have been generated.
The Power of Two problem was solved by someone in the community who proposed creating a chain of tokens. Each individual token was smaller, but in aggregate, it was a large token with finer granularity than the original.
The political problem may have been solved because of Bitcoin. The main difference between Bitcoin and Hashcash postage tokens is that postage tokens do something positive: they deliver a mail message without getting caught by spam filters.
The botnet problem is simultaneously a benefit and a detriment. The attack model was a botnet software that could be used to distribute the load of generating Hashcash tokens across multiple infected machines. The attack was validated today in cryptocurrency miners as part of malware. At the same time, the botnet problem is how an organization could generate tokens for all the emails passing through its servers. Let the server distribute the token-generation load across all the desktops in your office.
As I envision it, such a system would start out generating lots and lots of hashcash tokens, but eventually, between remembering who you sent mail to and dynamic pricing, most people would not need to generate very large tokens, and spammers would be fully burdened.
Maybe 20 (edit: 15) years ago Flattr launched a tipping service that failed because people didn’t want to tip people and then a decade later things like Kofi and Patreon came along and have been a huge success because attitudes shifted. Maybe now is the time that pay to email can work?
You don't need to buy into the "Bitcoin will replace the U.S. dollar" narrative to buy $5 worth of bitcoin to send a few hundreds or thousands of emails..
No one goes to an arcade wanting to play a game and says "I don't know about these tokens, though..."
You buy bitcoin somewhere (if you can't figure this out yourself you arent trying)
And send it to whatever address this app provides to you..
I am unsure whether you could use e.g. Apple Pay to pay directly, or if you’d have to follow the microtransaction playbook to buy a greater amount of currency which you can spend.
With a pay-to-inbox gate, reputation doesn't matter. The payment IS the reputation signal. A self-hosted mail server with TANSTAAFL works just as well as Gmail because the economic proof replaces the reputation system entirely.
We're actually running on Cloudflare Email Routing + our own backend right now, so we know the pain firsthand.
Think of it less as 'paying to send email' and more as 'strangers proving they're not bots.' The 100 sats (~$0.08) isn't really a paywall — it's a spam filter that actually works because it's economically impossible to send a million of them.
You can still receive all the email you want for free. The gate only activates for cold contacts who haven't been whitelisted.
I don't want it to be like I'm a valuable person and lower people pay for the privilege of my attention, but I do like the idea of making it so that senders have skin in the game and can't just infinitely generate emails that waste other people's time.
What I'd like to see is different costs based on how I classify the email.
So, everyone except trusted contacts pays $5 per email to me. If I think your email was pure spam, I keep the $5. If I reply, you get your money back. If I do nothing and never classify the email, you get back $4 after 30 days. And I can manually override like reply and keep the money, but those are the defaults.
Maybe a 3 to 4 tier inbox. Known and trusted user being able to contact you without paying, a high value inbox for the $1+ range, a low value inbox for the $.2 range emails wont be auto-deleted in and a very low value inbox emails will be deleted in depending on the amount paid, with free mails being gone within e.g. an hour, all the way up to e.g. a month for $.19 mails.
Then unify those inboxes and set up notifications to the users' likings.
Also, I'd normalize e.g. 10% going to the e-mail service providers and enshrine that amount into the protocol right away. Otherwise the protocol wont get a lot of attention from the major providers and if it does, the provider taking his share is going to become normalized anyway. But then the split isn't going to be in favor for the users. Which isn't negative per-se, but it'd be nice to have at least one type of service where this is split is reversed. And it is fair to assume whoever takes the larger split has more influence on the prices, potentially either making this feature useless or pricing very casual users out of the service.
This idea has been discussed for decades now. I like it
https://www.halfbakery.com/idea/Anti-spam_20_27stamps_27#124...
It also adds to the adagium that all spam solutions ultimately do not work, and Bill Gates proposed all of them (a meme, too).
Furthermore, email is a broken protocol not because of federation (something alternatives usually lack) but because of lack of E2EE.
yeah Im sure some of you are super cool and dont need to read an email someones paid to sent to you, but for most people it would be a good service.
Im sure Zuck charges people to DM him on facebook? Or was that just in the past?
In essence, it’s a proof of work. So an email would require a tiny amount of “work” to be received. For one email this is no hindrance at all. But at spam scale it becomes a true hindrance.
- it lacks a design that makes complete sense, i.e. a generic communication tool that combines short posts (Reddit model or private one like SMSs) with long-form notes (blog post model or private ones like emails) chats + audio-video where possible, including the archiving of the same; ultimately, it lacks a SINGLE self-hosted application that acts as a relay, but also as a web/local client, with Reddit/Lemmy-style posts, long-form blog posts, configurable with a few themes and easy to modify, chats, etc. We have Haven, which isn't bad but is just a "multi-purpose" relay + Blossom server (media attached to notes), there's Habla for blog use which does nothing else, there's 0xchat which still doesn't really work well outside its own relays... Nostr could be "the address book of the citizens of the web" with WoT to help and individual self-hosted instances as their digital home; it could be, but it isn't, and often messages posted outside of 4 giant "hub" relays simply aren't found by anyone, replies don't reach the recipient depending on the relays they are posted on, etc.
- it lacks a cohesive community; it's full of PoCs that are actually quite nice, but they're written and then abandoned. Almost no one seems intent on maintaining their own code.
- a lot is announced, correctly following the "release early, release often" model, but it goes nowhere.
Once upon a time, we had the hugely successful eMule/KAD for file sharing, we had ZeroNet for "websites without hosting" which largely failed; what's missing is essentially an application that serves modern public communication all-in-one, in a classic decentralised form like the KAD network, where everyone shares their own stuff and those not behind NAT help those who are to bypass it, and that's it. AT ITS CORE, people came for a function and discover the others, then you can plug in an economic aspect: "want my videos in higher resolution? Yes, I have them, for a fee", "want my books from which I extract articles here and there that you like? They're available, but for a fee", and so on. The foundation, the user economy, should only be the gift of storage and bandwidth, period. No needs to pay dedicated services nor directly nor via fees.
Otherwise, we're going nowhere (like Staker News), or if we do go somewhere, it won't be where we want to be and it won't work quite as we'd hoped at the start. Nowadays spam is easy enough to control at personal levels even with dbacl filtering and gnus scoring. That's not the problem. The problem is having something distributed enough since our connections can sustain a significant overhead, to avoid pay third party services, get easy censorship etc.
People's need for comms vary, give a single tool who support many, something easy to deploy, self-contained as much as possible, is the key to harvest users for a reason and they discover other reasons and enough other humans to stay.
The key difference in our implementation is using Lightning micropayments instead of on-chain Bitcoin. A 100 sat payment (~$0.08) clears in under a second, costs almost nothing in fees, and the receiver actually keeps the money. It's not burned like hashcash PoW — it's a real economic transfer.
If you want to try it live: send any email to niko@tanstaafl.email. You'll get a payment link back, pay 100 sats, and watch the email land. The whole flow takes about 30 seconds.
Would genuinely love feedback from someone who's been thinking about this problem.
1) Previous work 2) Your differentiation 3) What's your business case for this personally? 4) Potential problems etc
Though I don't quite remember if it was your comment exactly or if it was someone's elses comment which had the same idea as this.
For legitimate senders, the attached fee would end up being spent by the receiver to send a reply, like a "refund", so it ends up zero-sum.
But for spammers it becomes an expensive option. Nobody is going to reply to the spam to "refund" their fee.
BTC lightning can have some flaws too IIRC and I am curious how you handle it.
I have worked somewhat with nano just out of curiosity and it was a decent experience.
It's a shame that nothing like nano has been built for stablecoin itself properly. There is a exchange provider (nanswap) which has nanusd idea and I have even talked to the creator of that project but they are a sole proprietor and the business even after talking to them doesn't feel sadly trustworthy enough that I can recommend it at any scale given that it essentially boils down to that I have to trust them with my money.
Polygon chain with USDC can come close.