@astraluma I'm glad you like it!

@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

@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

@gaditb Good call. I switched it to the Verge one. Thank you!

@arunisaac Thanks, fixed!

@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 @doesntgolf
BTW this is a great primer on object capabilities: https://www.youtube.com/watch?v=eL5o4PFuxTY

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

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?

Yes, there’s gmail …

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 http://petmail.lothar.com/design.html

Oh, that's nice! Thanks, I'll take a look at petmail.

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

« 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