I've finished writing part 1 of "OcapPub: Towards networks of consent", which is to say the "Conceptual Overview" section https://gitlab.com/spritely/ocappub/blob/master/README.org
There's a lot there already, and we haven't even gotten to Part 2, the "How to Build It" section yet. I'll begin work on that tomorrow.
What's here already is more or less an explanation of *why* OcapPub is taking the particular direction it is taking, and why other approaches run into serious problems.
@astraluma I'm glad you like it!
@cwebber 👆 good read
I've got a question that I'm sure someone beside you could answer if they see it - feel free, that someone.
What's a stamp? I mean, not metaphorically, but what's the payment Bob puts on his message.
@emsenn I believe a postage stamp is meant.
@cwebber has discussed in the past systems to charge for message delivery. See http://dustycloud.org/blog/possible-distributed-anti-abuse/
@emsenn
Not getting specific yet. There's just the principle involved that the burden should be on the sender to get unsolicited messages delivered. There may or may not be a micro transaction currency involved. If not, Bob needs more CPU time or other resource to send. This prevents junk messages from overwhelming the system, hopefully
@cwebber
@yaaps @emsenn @astraluma @skarabrae See more here https://octodon.social/@cwebber/102465707083348407 but yes you are all generally on the right track
@cwebber amazing work. "We will read it to our readers" I think you meant to say "leave" instead of "read".
What type of stamp do you imagine, hashcash or some type of coin ?
@cjd Oops! Nice catch, fixed.
Also I meant to say "postage" or "postage stamps". In retrospect it's fine to say "stamps" as long as you introduce them as "postage stamps" first to remove ambiguity.
As for what they are, there are a few options, and this system is compatible with a currency-like system or something like hashcash. But I have an idea for something that I think may be a weird hybrid... more on that soon. Maybe that's part three, or a second document ;)
@cjd Just as a preview:
- I don't like how hashcash implies constantly burning CPU. But we may be able to "reuse" that.
- I don't trust blockchain style cryptocurrencies. Digicash and other fiat-issued systems are more okay, but I'm not wildly enthusiastic of making this too money-like in the first place, though there's no reason someone couldn't use real money.
I've only run my idea by one person, I need to run it by a few more before I'm brave enough to publish it. Wanna volunteer?
@cwebber if you're interested in fielding ideas, I'll definitely give it a read.
FWIW I've been working on a proof of work for a project of mine which requires miners to collect as many hashcash'd messages as possible, thus creating a "bandwidth hardness" of the algorithm and also turning the mining pools into a decentralized pubsub system.
My intuition is that too get adoption in the fedeverse, whatever the system, stamps will need to be an optional extension.
@cwebber Problematically, with "stamps", if Bob has the ability to return the stamp to Alice because her message was not spam, then stamps can be exchanged so financial markets can emerge, and financial markets are at the heart of the crypto/blockchain FOMO esthetic.
However interesting this thinking is, my cynical side suspects that the fedeverse will stumble over a handful of bad ideas before converging on a system of gossiped whitelists, so like BGP, you need at least 1 node to sign for you.
@cwebber A really cool model (IMO) would be if everyone allowed a certain number of stamps for servers who they explicitly choose to federate with. When a message is viewed and not flagged, the stamp is returned to the author. A new server might get only 50 stamps plus 5 per day with an upper limit of 500. Getting old and controlling spam well leads to increased limits.
But alas, oceans don't boil easily...
@jfred @cwebber
Any time one proposes a currency-like thing, people immediately (and rightly) ask "why did you say that? what's in it for you?" which makes it all but impossible to bolt it on to an existing project.
I suspect the most likely thing to work is a challenge/response hashcash where message recipients can decide what the work actually is... "here's a challenge, download this webassembly file, execute it with the challenge and give me the result".
@cwebber (My one criticism so far is that, while I get that the Vice article is the CLOSEST citation to what you're saying, EUGH it's such a bad article. Would the Verge or Techdirt articles not work as well there?)
@gaditb Good call. I switched it to the Verge one. Thank you!
@arunisaac Thanks, fixed!
@cwebber
I LOVE it.
KEEP GOING ON!
@cwebber Finally got around to reading this. I really like it so far.
@skunksarebetter Regarding "echo chambers", it's a concern, but I think if we allow people to have multiple identities (as opposed to fearing about people judging their one solo identity) they can also better explore ideas.
But I think echo chambers aren't as much of a risk as spam and harassment anyway.
@succfemboi @skunksarebetter @sjw@patch.cx If you read https://gitlab.com/spritely/ocappub/blob/master/README.org you'll see that I challenge whether our current assumption of how we implement bans and other abuse moderation are actually sufficient for the systems we want (and the level of protection for users we want), and indeed, the fact that we can't stop people from creating multiple accounts is part of it.
We should acknowledge this and look for a solution that doesn't require a lockdown on number-of-accounts to function safely.
« so the receiving server can decide whom to send the message to. Unfortunately this decision breaks the actor model and also our suggested solution to authorization; see MultiBox for a suggestion on how we can solve this » — @cwebber
« freedom of speech merely means that you have the freedom to exercise your speech, somewhere. It does not mean that everyone has to listen to you » — @cwebber
@cwebber Solid intro. Looking forward to part 2.