4 ms·

Since I'm explicitly mentioned in the article, let me say a few things: a) I agree email is forked up. b) I think a stamps-like solution could possibly work,

Since I'm explicitly mentioned in the article, let me say a few things: a) I agree email is forked up. b) I think a stamps-like solution could possibly work, but it's not the email part that makes it hard, it's the ecosystem around email that makes it hard. For example, once you send an attenuated capability to someone else, you've lost it, which means your system needs to be aware that what you're sending is a capability token and not an identity token. If what I've said doesn't make sense- I'll explain a bit later on in this post. c) I think it's nice to think creatively about message systems, including email, XMPP, ActivityPub Now I'll say where I see the problems here being: 1. Overlaying on top of email The problem with a protocol such as email is once it's in place, it's in place. Stamps (which is the idea the author references) could maybe be overlayed on ActivityPub- but I worry the time for that ship is either closing or it's sailed. I have many more thoughts on this point but it would be pages of thinking, so I'll leave it at that. 2. Cryptography not required The author wants public keys, emails signed, etc. You don't need any of that for this to work. What I proposed for AP (and still do) is that we can have a "public" address and then private, revocable addresses. You can then combine that with a bearer token exchange system. It's actually very simple, though I'm oversimplifying it too much here. 3. The author says I got it from Christine Webber, and "who knows where she got it from"- She got it from Mark Miller's Ph.D thesis, as well as the work done by Chip Morningstar. The theory behind all of this is called Object-capability Theory (https://en.wikipedia.org/wiki/Object-capability_model https://en.wikipedia.org/wiki/Object-capability_model) The email addresses are what the OCAP folks would call a capability token- the ability to send an email is a capability, and the special email I give someone is a capability token, a bearer token in this case (though there are other patterns in the OCAP world). I can then make other attenuated capabilities, ie proxy capabilities that may act slightly different or serve a specific purpose- like a share link that only works for a week, or a share link that's upload only, etc. Why is all this important? Because understanding the theory will help you understand the possibilities, and also the possible flaws. Am happy to discuss further.

senko 5y ago
Capabilities don't solve double spending(or in this case, double sending) token, as they are intentionally transferrable. So you'd need to have a way to bind a capability to a sender, which naturally leads to PK, or treat them as short lived tokens you revoke as soon as you see they've leaked, which is identical to throwaway email addresses we already have.
- emacsen 5y ago
  > Capabilities don't solve double spending(or in this case, double sending) token, as they are intentionally transferrable. They do if the entity doing the transfer is the issuing entity.
mhb 5y ago
Isn't this an obvious (and actually useful) product for a startup? You implement whatever solution you come up with handling payments, tokens or whatever and users can have it as a filter before they see their email.
cabalamat 5y ago
> once you send an attenuated capability to someone else, you've lost it I'm not sure what you mean here. For example, if Alice sends a token to Bob giving Bob a capability, Alice can sign it with her private key and Bob's public key, such that if Bob (or anyone else) wants to use that capability, they have to have Bob's private key to do so.
- emacsen 5y ago
  What I mean is that if Bob hands his capability to Carol, she can give it to Dave and he can't stop it. I don't see any reason we need keys here.
  - cabalamat 5y ago
    But Dave can only use the capability if he has Bob's private key. That's why we need keys.
    - emacsen 5y ago
      Dave doesn't need a private key, the token just needs the ability to be traded. One of the more complex aspects of OCAPy design vs the we do things now is that in a fully ocap world, the token wouldn't just be a string, but possibly a reference to a living object that Alice owns. Then the trade (and any use of the capability) always goes through Alice. That's why you don't need crypto in a real OCAP world.

senko 5y ago

Capabilities don't solve double spending(or in this case, double sending) token, as they are intentionally transferrable. So you'd need to have a way to bind a capability to a sender, which naturally leads to PK, or treat them as short lived tokens you revoke as soon as you see they've leaked, which is identical to throwaway email addresses we already have.

emacsen 5y ago
> Capabilities don't solve double spending(or in this case, double sending) token, as they are intentionally transferrable. They do if the entity doing the transfer is the issuing entity.

mhb 5y ago

Isn't this an obvious (and actually useful) product for a startup? You implement whatever solution you come up with handling payments, tokens or whatever and users can have it as a filter before they see their email.

cabalamat 5y ago

> once you send an attenuated capability to someone else, you've lost it I'm not sure what you mean here. For example, if Alice sends a token to Bob giving Bob a capability, Alice can sign it with her private key and Bob's public key, such that if Bob (or anyone else) wants to use that capability, they have to have Bob's private key to do so.

emacsen 5y ago
What I mean is that if Bob hands his capability to Carol, she can give it to Dave and he can't stop it. I don't see any reason we need keys here.
- cabalamat 5y ago
  But Dave can only use the capability if he has Bob's private key. That's why we need keys.
  - emacsen 5y ago
    Dave doesn't need a private key, the token just needs the ability to be traded. One of the more complex aspects of OCAPy design vs the we do things now is that in a fully ocap world, the token wouldn't just be a string, but possibly a reference to a living object that Alice owns. Then the trade (and any use of the capability) always goes through Alice. That's why you don't need crypto in a real OCAP world.