3 ms·

I'm probably missing some context - I don't really grasp the problem being solved or why it's related to the fediverse. Would an accurate summary be "how to mak

I'm probably missing some context - I don't really grasp the problem being solved or why it's related to the fediverse. Would an accurate summary be "how to make activitypub based systems end to end encrypted (by default?)" or more along the lines of "verified" identity like keybase?

ineptech 2y ago
This is a directory of public keys, which every secure messaging app including Keybase must also have, but federated rather than centralized. That's a necessity for e2ee and it's very cool to implement it as an append-only version of the pub-sub messaging the fediverse already has. It has nothing to do with the identity verification a la Keybase, unfortunately, as that would be a really good and useful feature for the fediverse, but I think it would be a lot harder to do.
- some_furry 2y ago
  Nothing prevents other people from stapling identity verification on top of this.
  - ineptech 2y ago
    Well I hope so, but it would take something more exotic than the directory service described in this article, right? ... thinking it through, maybe not. I guess if a client initiates AddVerification for some twitter handle, and the directory service sends that handle a private twitter message with some guid, and then the client sends AddVerificationStepTwo with that guid, the directory service could append both of those messages to attest that that user is associated with that handle. A malicious directory service (or a real directory service that's calling a malicious twitter clone) could fail to correctly verify someone, but it wouldn't be able to add a verification for the wrong client or for a client that didn't initiate it, which is probably good enough? edit: just realized you're the author, thanks for working on this stuff!
rakoo 2y ago
Sending an encrypted message to someone is a problem solved for decades: get their public key, encrypt your message, send it. The real problem with encrypted communications is: how do you properly distribute public keys, make sure they receive it, they receive the right one, etc ? - giving them by hand, directly or through web of trust, doesn't scale - trusting a server involves... trusting it, which you might not be able to do for many reasons - use the first one you receive from your recipient (TOFU) kinda works, but it's not really enough The beginning of a solution here is general transparency for everyone: everyone sends their public key to everyone, everyone records everything, and so if someone else changes my key without my consent I can tell everyone "SOMETHING IS WRONG, THIS IS NOT ME". For scalability, of course, keys aren't sent to everyone. The nice thing with this is that by design you don't need to trust anyone, you just have to watch everything by yourself. Keybase still needs to trust all third-party services, although it's assuming that each one isn't super reliable and the real trust comes from multiple independent third-parties. It's slightly in the middle, with the advantage of reusing existing stuff, but the inconvenient of making said existing stuff more important What's the relationship with the fediverse ? None, really; the concept is generic for any kind of communication, but ActivityPub is slowly becoming a protocol for generic communication anyway so might as well do it for AP.

ineptech 2y ago

This is a directory of public keys, which every secure messaging app including Keybase must also have, but federated rather than centralized. That's a necessity for e2ee and it's very cool to implement it as an append-only version of the pub-sub messaging the fediverse already has. It has nothing to do with the identity verification a la Keybase, unfortunately, as that would be a really good and useful feature for the fediverse, but I think it would be a lot harder to do.

some_furry 2y ago
Nothing prevents other people from stapling identity verification on top of this.
- ineptech 2y ago
  Well I hope so, but it would take something more exotic than the directory service described in this article, right? ... thinking it through, maybe not. I guess if a client initiates AddVerification for some twitter handle, and the directory service sends that handle a private twitter message with some guid, and then the client sends AddVerificationStepTwo with that guid, the directory service could append both of those messages to attest that that user is associated with that handle. A malicious directory service (or a real directory service that's calling a malicious twitter clone) could fail to correctly verify someone, but it wouldn't be able to add a verification for the wrong client or for a client that didn't initiate it, which is probably good enough? edit: just realized you're the author, thanks for working on this stuff!

rakoo 2y ago

Sending an encrypted message to someone is a problem solved for decades: get their public key, encrypt your message, send it. The real problem with encrypted communications is: how do you properly distribute public keys, make sure they receive it, they receive the right one, etc ? - giving them by hand, directly or through web of trust, doesn't scale - trusting a server involves... trusting it, which you might not be able to do for many reasons - use the first one you receive from your recipient (TOFU) kinda works, but it's not really enough The beginning of a solution here is general transparency for everyone: everyone sends their public key to everyone, everyone records everything, and so if someone else changes my key without my consent I can tell everyone "SOMETHING IS WRONG, THIS IS NOT ME". For scalability, of course, keys aren't sent to everyone. The nice thing with this is that by design you don't need to trust anyone, you just have to watch everything by yourself. Keybase still needs to trust all third-party services, although it's assuming that each one isn't super reliable and the real trust comes from multiple independent third-parties. It's slightly in the middle, with the advantage of reusing existing stuff, but the inconvenient of making said existing stuff more important What's the relationship with the fediverse ? None, really; the concept is generic for any kind of communication, but ActivityPub is slowly becoming a protocol for generic communication anyway so might as well do it for AP.