InboxFee

@exopaul aside from tests, I don't think so. It was launched literally yesterday, so that's not a surprise. And in fact I believe that this will indeed simply 'scare away' most strangers, as they don't really value your attention enough, if you're not a celebrity/influencer of course. However, I think there is no downside in sending inbox fee invoices: strangers will either remove you from their list (which is great!), or will be slightly annoyed (as they should be), or will actually pay if they really care (which is great too). And btw, if you'd like to try it for real, just DM me your email on twitter (@ArturBrugeman), I will send you a 'cold email', and you'd send me an invoice and I will pay it. And I invite anyone wishing to get them some free bitcoin to follow this limited time offer :)

@m0ham3d well in fact the app is not intended to filter 'spam'. Gmail already has good enough spam filters that block outright spam, plus it categorizes other stuff well too (like newsletters etc). Cold emails are much more fuzzy: some are very valuable inbound requests, and some are annoying BS. What the app does is pretty trivial: it only considers emails from 'main' Gmail tab (not Promotional/Notifications/etc), it checks if you've ever emailed to the sender or opened his previous emails. If not then it's probably a cold email from stranger. By default the app shows a notification if it detects a cold email, offering you to send an invoice. This is to make sure our detector doesn't mess with your business by sending invoices to important inbound requests. If you try it and find the detector reliable, you can enable auto-invoicing. The app can't have an API because it doesn't interact with our server for email processing. That would be a privacy disaster. However, I plan to add other services besides gmail based on demand, with POP3/IMAP support on the roadmap, obviously. Which mail system are you interested in?

@arturbrugeman I think I understood. I used "spam" in a broad sense As to API, I was thinking less about message processing and more about endpoints to check whether a given sender already paid the inboxfee, and if not to return some sort of "payment link". The mail client can then implement its own processing & rules while integrating your service.

@m0ham3d Aha! That's a great idea! In fact I anticipated some of what you're describing: the app is adding several X-Payment-XXX headers to the invoice email, including the invoice 'string' itself, which means that a) our client can give them special treatment, i.e. label them, and b) sender's client can give them special treatment, and can even auto-pay select invoices based on some rules. However, there is currently no way for both email clients to know if invoice was actually paid. It can be added if we send a confirmation email after we receive the payment, which could include the proof of payment as a header too.