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.
@cwebber Solid intro. Looking forward to part 2.
@astraluma I'm glad you like it!
@cwebber i like where this is starting, and i am looking forward to seeing where it goes!
thank you :)
@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/
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
@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...
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!
I LOVE it.
KEEP GOING ON!
@cwebber this (like all of your writing) is really, really great!
This question is maybe a bit boring (and from the outline it looks like maybe you'll cover it in part 2? so feel free to not answer or direct me elsewhere), but -
in a distributed ocap system, doesn't revoking caps require an ... ACL? (or in this case, a non-acl (blacklist)), to keep track of which caps have been given out that are no longer to be recognized as legit?
@doesntgolf I haven't covered that, but the answer is... no! You don't need an ACL for revocation (or for tracking abuse)! And here's how we can do it.
An ocap is an unforgeable reference right? (As in, if you don't know it, you don't have a way of faking it.)
So, what if we have the "real" object, and then what we actually hand the person is a "proxy" object that forwards messages? This proxy could attach information so we know "who's capability" is being used when they use it.
@doesntgolf Now, let's say we see that they're abusing our resource through that proxy. Here's the second part! Our proxy contains a flag that we can set, and then it *stops forwarding messages*! But we hold onto the capability to flip that bit... a "self-destruct button" if you will... and since they don't have that, we can disable it if necessary, that's our power.
So as you can see, we can get both accountability and revokeability!
Thanks @cjd ! Putting this on now.
@cwebber ahh, it's a brilliantly simple solution! I need to take some time to think about the implications of proxy objects, but I really love how simple that is. Thanks for explaining :-)
@cwebber Finally got around to reading this. I really like it so far.
@cwebber Very interesting. I do see one problem in that a design like this would be a great echo chamber which can easily become harmful in a similar way that harrasment is, a sort of self harassment with an invisible enemy. But I don't see that issue solving itself in the current more open and walless systems, and such a closed system is beneficial to certain parties anyway. Regardless it's an interesting concept which I hope sees a working model!
@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 @email@example.com 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