So... this seems like a good time to start experimenting with Mastodon.
I'm very skeptical about the chances of getting enough network effect to bootstrap a new social media site in general, and even more for distributed/decentralized/non-commercial ones.
Still, recent events on Twitter make me believe there is a chance, and I'd like to help make that happen.
@pwuille I think the big problem we're going to see is that Mastodon has much worse protections against spam than Twitter does. That's not a problem yet. But it will be in the future. And dealing with it could destroy the ability of small instances like mine to federate with others.
If email didn't have big companies like Google pouring money into anti-spam, it'd probably be dead already.
Bitcoin can fix this by making spam costly. But the people behind Mastodon hate crypto currencies.
@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.
@silverpill @pwuille “transaction lookup can be expensive” just provide a merkle path from the confirmed tx to the block header.
@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).
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.
>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.
@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.