Do you want to see spam and hate speech off the Fediverse? Think there must be a better way than continuing to click Mute and Block all the time?
On this episode of Libre Lounge, Chris and Serge talk about the work they're doing to protect the Fediverse from Spam, Scams and Online Harasment.
@librelounge I haven't listened to the episode, yet, but this has been bothering me for a while, since the mute/block approach means that there's a world of difference between the community established members see and the trash newcomers are going to see, which isn't exactly the best foot forward.
That said, yes, you could grind stamps. Grinding stamps still means that you're wasting resources to send unwanted messages, which is better than present, which is free. (Plus, you can *still combine* with present mechanisms; we aren't throwing anything away.)
- If they're tradeable, then they're more valuable, and you're literally wasting money (and enriching the person you're trying to antagonize) to send them.
- Alternately, there's the solve-a-puzzle mechanism to get stamps. This mechanism doesn't mean the person gets enriched, but it does mean that grinding is more worthless
- Every user can specify what stamps they accept
- By default, every user's instance runs a "postage stamp dispensor"
- You can get stamps by yes, grinding against some puzzles to get them
- But they expire after say, a month
- What if you hoard a lot to unleash a spam wave? User can "restart" postage dispenser, they're worthless now
@cwebber @librelounge @rmw @emacsen Three questions, here:
1/ How does this work for public areas, flooding the timeline with spam or hate?
2/ Would anyone really accept a micropayment system? Seems like we've been promised them forever and nothing has worked.
3/ If widely adopted, what prevents centralized spam-houses from going wherever there's cheap power and burning heaps of fuel, like cryptocurrency mining already does? And would that solution disrupt real messages?
1. Public timeline is addressed in other parts of my paper, specifically MultiBox. I think Chris took that proposal and put it into thiers too. Did you happen to read the whitepapers?
2. We never mentioned micropayments. I think money here is a potentially bad idea.
3. If stamps are limited in time and value and can be nullified, it's not going to stop them, but it will make it a pointless excercise.
@emacsen @cwebber Do you have a link to the whitepapers? I haven't seen them.
And certainly excuse the term "micropayment" if it doesn't fit, and maybe it's a lack of vision on my part, but I can't see an approach to electronic stamps that isn't a micropayment service, especially where the recipient gets some benefit.
There's some confusion, maybe because of my statment about "getting paid" for spam. That was a bit tongue in cheek. The only benefit anyone recieved in buying a stamp is message delivery. When you send me a letter or postcard, the stamp you pay is a delivery fee.
Stamps in our proposal are just delivery fees, paid by a sender. The difference is that the recipient (and or server operator) gets them, and not some third party (ala the post office).
You can also say that sending a message not costs 3 stamps, where it previously only cost 1.
You can also say that a stamp expires in a month. Or you can say "All stamps that existed before right now are null and void".
I could hoard/collect stamps, but I can only use them to send you messages so long as you say so.
As for trading, why would someone pay me for something that you can instantly declare has no value?
You *could* ask for money in exchange for Stamps on your own site in theory. We didn't specify a mechanism for that, but it's possible.
But going back in the other direction (stamps for money), I just don't see that happening.
@emacsen @cwebber @librelounge I hope I'm not just arguing semantics, but at least to me, that sounds like a micropayment system, but with features that make communication unreliable, but (based on how e-mail seems to have gone) still gives an advantage to spambots that mass-send garbage for a queue of clients as soon as tokens are generated.
I'll leave it at that until I've gotten through the whitepapers, since it's likely I don't understand the use case or am hung up on semantics.
emacsen.net is one server in the network