Follow

I've finished writing part 1 of "OcapPub: Towards networks of consent", which is to say the "Conceptual Overview" section gitlab.com/spritely/ocappub/bl

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 i like where this is starting, and i am looking forward to seeing where it goes!

thank you :)

@cwebber

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 dustycloud.org/blog/possible-d

@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

@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 @cjd I'll read it, but I'm still fairly junior at developing distributed systems

@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...

@cwebber @cjd It'd be neat to use GNU Taler for this, though that requires banks to actually support it...

@jfred @cjd Does it? Or does it only require so if you're trying to link it to real money? What if we're not? :)

You can issue Taler like a fiat currency, yeah? Their demo even has something they issued that way, just for demonstration.

@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".

@cjd @jfred The thing I'm proposing though isn't currency-like-enough, as hopefully people will see. For one thing, "postage" expires... not a desirable property in a currency.

@jfred @cwebber
Then some instances can make spammers fold proteans, others can make participate in SETI (is that still a thing?) others can make them mine monero...

@jfred @cwebber
Another advantage of just throwing people a challenge and a wasm file to compute the response is that you can make the response also contain the message you want to send, so then you have protocol-agile asymmetrical encryption capability builtin

@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?)

@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.

(1/2)

@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!

(2/2)

@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 :-)

This is interesting and gives me an idea. Could we do something similar for email? Instead of giving people our actual email address (real object) to send us email, we give them a random (so it's unforgeable) newly generated alias address (proxy object). If they start spamming us, we delete the alias. If they share the alias with a spammer, we can hold them accountable. Are there any systems that implement this?
I don't understand. How is gmail implementing this kind of object capability?

@arunisaac Yep, people have been doing that for some time! Many mail servers even support this out of the box.

You can also read up on Petmail which has similar ideas to what I am describing petmail.lothar.com/design.html

@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.

@cwebber
> if we allow people to have multiple identities [...] they can also better explore ideas

But some people might call it ban evasion and it's a more cumbersome to have multiple accounts, unless one is @sjw or something
@skunksarebetter

@succfemboi @skunksarebetter @sjw@patch.cx If you read gitlab.com/spritely/ocappub/bl 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

Sign in to participate in the conversation
Octodon

Octodon is a nice general purpose instance. more