Is the payment to get the email delivered or to get guaranteed response?
I'd prefer the latter for two reasons: 1) as a receiver I don't want to miss out on a potentially interesting email just because the sender couldn't pay (for technical or financial reasons), and 2) as a sender I'd like some sort of guarantee if I'm going to pay for something.
It's probably the more difficult approach of the two so I suggest testing both approaches and see what works best.
Congrats on getting this far already. Like you say it's not a new idea, but who cares about ideas. It's about execution anyway. Looking forward to the launch!
1) I think the fact of paying is already a good enough barrier. The price could be just a couple of dollars, which would be enough to convice sender to spend sometime on writing a personal email instead of using cold mail template.
2) Because of this barrier user will receive much less email + with much relevant content. As a result sender will have much higher chances for reply.
The problem is that as soon as you tie the ability to send someone an email to your bank account you immediately put poor people at a grotesque disadvantage. I wouldn't presume to speak for pg, but I doubt any savvy investor would be happy passing up the opportunity to be the first to hear about the next Google/Uber/Facebook because the founder couldn't afford to send you an email. If you want to limit the number of emails people can send then you need to tie the ability to something else.
That's why Bill Gates' idea was so good - his plan was to make people's computers have to do useful work (say, Folding At Home or the distributed Seti search client) rather than merely transferring money around. Wealthy people wouldn't be at an advantage because the work unit would be time: a rich person with a fast laptop that can test 1,000,000 protein folds in 2 minutes has to do 1,000,000 tests to send their email while a poorer person whose hardware can only do 1,000 folds in 2 minutes only has to do 1,000 tests to send their email. Time is effectively the same for everyone. It's a beautiful solution. Far better than boring old money.
While we are getting good at proof-of-work stuff -- we aren't great a proof-of-power.
Meaning, it would be easy for me to emulate 10,000 slow computers with one powerful one, doing 2 minutes of work 10,000x parallel (claiming each of these computers is very weak) and that completely bypasses the "beautiful" solution.
Sending BTC works because it isn't gameable (at this point). I like the idea of a ฿0.0001 (or even ฿0.001, 20 cents) fee for each email sent to me. It is a little over 2 cents US -- would absolutely stop spammers (most it cost prohibitive for them), but hopefully would not stop normal users.
This could be interesting with an API to control pricing, that way it could be adjusted by BTC => local currency -- but also based on other things.
I for example, would like a multiplier based on my backlog. I might start at 20 cents an email -- but if I have 1,000 messages waiting for me to read, I would increase the price to contact me to $20 an email -- because at a certain point I can't keep up and the value per email drops to 0.
If you have to pay for an email anyway, would You instead call or pick some other way of direct communication? Not quite sure that replacing the indirect communication, where You can procrastinate to some extent, with direct one will solve the issues it promises.
micropayment channels (https://bitcoinj.github.io/working-with-micropayments), are used between 2 parties to send a lot of micropayments. But here there is only one transaction even small.
Also micropayments may help against spam but not agains cold emailing
You can have a micropayment channel between the user and their email provider, and between email providers.
When User A wants to send an email to User B, he sends a micropayment through one of these channels to his email provider. His email provider in turn sends a micropayment to User B's email provider. User B's email provider sends a micropayment to User B.
So in this way, value can be transferred without any on-chain BTC transactions, zero fees, and instantly.
I'd prefer the latter for two reasons: 1) as a receiver I don't want to miss out on a potentially interesting email just because the sender couldn't pay (for technical or financial reasons), and 2) as a sender I'd like some sort of guarantee if I'm going to pay for something.
It's probably the more difficult approach of the two so I suggest testing both approaches and see what works best.
Congrats on getting this far already. Like you say it's not a new idea, but who cares about ideas. It's about execution anyway. Looking forward to the launch!