@silverpill @pwuille Both. Though payments don't necessarily mean paying someone in particular: you can also sacrifice BTC to make a cryptographic identity expensive to obtain.

This is probably better than hash cash as it's easier to determine the value of the payment/sacrifice.

@pete @pwuille Here's how this can be implemented:

- Require actor objects to have identity proof that cryptographically links bitcoin address to actor ID. The mechanism of identity proofs is described in FEP-c390 (this proposal relies on DIDs, but bitcoin address can be represented as did:pkh identifier).
- Also require actor objects to contain a proof of burn. For example, it can be an ID of transaction that burns BTC.
- When the server receives activity from some actor for the first time, it should verify the proof of burn (for example, by connecting to a bitcoin node, looking up the transaction, and checking the sender address and the burnt amount). If the proof is correct, the server accepts activity. Otherwise it rejects activity and adds actor to a blacklist (temporarily or permanently).

The only problem I see here is that transaction lookup can be expensive.

@silverpill @pwuille “transaction lookup can be expensive” just provide a merkle path from the confirmed tx to the block header.

@pete @pwuille @silverpill @pete @pwuille I don't think people are going to be willing to pay to post. I won't, for one.

@Hyolobrika @pwuille @pete It's a one-time payment, and you will be able to re-use your identity key on other servers (if you manage multiple accounts, or during migration). Can be done anonymously.
I think it's not bad.
The alternatives are shared blocklists (leads to centralization - see email) and web-of-trust (complicated, probably doesn't scale).

@pete @pwuille @silverpill @pete @pwuille So, per account, not per post. That doesn't sound so bad. How much do you reckon is needed?
Also, if users are spending money anyway, why not let that money go somewhere useful, like to the upkeep of servers?

@Hyolobrika @pwuille @pete In the beginning payment amount can be negligible... But I think eventually we'll see specialized spam bots that can send hundreds of messages per second. Such bot can reach a lot of people even if instance admins react quickly and block it. That creates a strong incentive for spammers, so perhaps per-account payment is a bad idea after all. We can use per-post/per-connection PoW to rate-limit the spammers, in addition to proof-of-burn.
Another option is to make people pay for each connection (when you interact with someone for the first time; not per-post), so spammers will need to pay you. If you have a mutual interaction with someone, the payment cancels out. This sounds cool, but I think it may hurt the network.

>Also, if users are spending money anyway, why not let that money go somewhere useful, like to the upkeep of servers?

Who will distribute the collected funds? What if you made a payment to yourself? When the money is burned, there's nothing to worry about.

@pete @pwuille @silverpill @pete @pwuille
>Who will distribute the collected funds?
I was thinking each admin could collect the funds from their users. So it would just be a payment to the instance.
>What if you made a payment to yourself?
Yeah. That's a fair point. Maybe there could be a burn associated with starting federation from a new domain as well.

@Hyolobrika @pwuille @pete Proof-of-payment-to-admin is difficult to verify because there's no concept of admin in ActivityPub. Also instance admin could be a spammer too. That's what I would do if I were one - buy a domain and start sending automated messages until everyone blocks me. Domain works like a proof of burn already

What about just a timelocked output like joinmarket uses for its fidelity bonds?

@ademan @silverpill @pwuille Thet could work too.

@midnightmagic @pwuille What kind of cleaner solution? Spam prevention with email's design is fundamentally hard. Hashcash would have likely failed due to botnets and Asics; Bitcoin Lightning didn't exist until very recently.

@pete @pwuille An old-school anti-spam mechanism which is ~100% effective is to ensure that literally every contact one makes has a separate contact email others can make use of. Automatically-negotiated contact exchange to give people something similar in functionality seems possible, esp. since everyone uses mobile devices anyway.

@pete But, unfortunately, it looks like most of the people who would be motivated to make such a thing have essentially been all hired and stripped out from any remotely-related FLOSS project. Almost none of the floss projects I know from 15-20 years ago has survived.