3 ms·

> I feel like Element works better as a competitor to Slack or IRC than as a competitor to Signal or Whatsapp. To me it's a competitor to Keybase. "I want to s

> I feel like Element works better as a competitor to Slack or IRC than as a competitor to Signal or Whatsapp. To me it's a competitor to Keybase. "I want to send my co-worker/client an API key that I don't want exposed to the public" is about the only use for Keybase I've had. I have like 5 contacts on there for this reason. Slack/IRC is much more usable for getting shit done, but not being E2E I wouldn't send anything sensitive over them. Element is currently a "this is a mildly nicer experience over PGP + Email/Slack.

tombert 6y ago
Yep yep, totally think that's reasonable. I know very little about the intricacies of cryptography, but part of me wonders if there's some way of doing a federated "key synchronization" service similar to keybase.
- IgorPartola 6y ago
  So Keybase is just a UI for PGP/GPG (well that was what it was before it became a Borg). The problem with GPG: 1. You need to keep your private key very private, which is incompatible with the idea that you might have several devices you normally use. GPG itself does not provide you with a mechanism to sync your private keys between devices because this is a super insecure thing to do without some serious work. 2. GPG requires that you and another person verify each others' public keys out of band. I need to meet you in a parking lot to validate your key fingerprint while you validate mine. 3. GPG's web of trust relies on attaching public keys to real world identities. You are asked to validate government documents when verifying public keys. That's incompatible with how a lot of us want to work. Note that this isn't a built-in requirement, but GPG itself provides no guidance on how to validate user123 on GitHub, just User Onetwothree Jr in real life. 4. GPG's UI is almost as arcane as tar :) Keybase solved this by: 1. Providing a secure way to manage private keys across devices. 2. Outsourcing proof of identity to other providers. Its use case is validating the identity of user123 on GitHub, which happens to also work fairly well for CelebrityName on Twitter, or FriendName on Facebook. 3. See #2: social proof means you can attach that proof to any kind of identity. 4. GUI + nice TUI works better. Where Keybase fell short was that a non-techie will not understand much about "social proof" and the only kind of social proof they have access to is limited to Twitter, Facebook, and Instagram. Signal's solution to this was simpler: you have a QR code/set of numbers that represent your fingerprint right in the app. You show me yours, I'll show you mine. We get connected by phone number or email. That's it. If Signal was built on a federated platform it'd be perfect and nothing about it from what I understand prevents that.
- miloignis 6y ago
  That sounds kinda similar to the problem Matrix solved with cross-signing, how when you login to a new device and verify it with one of your already logged-in devices, it can request your old message keys E2EE so you get all your history. Maybe a similar thing could be built on top of it?
zikduruqe 6y ago
This is why I use https://keys.pub https://keys.pub and/or Magic Wormhole.

tombert 6y ago

Yep yep, totally think that's reasonable. I know very little about the intricacies of cryptography, but part of me wonders if there's some way of doing a federated "key synchronization" service similar to keybase.

IgorPartola 6y ago
So Keybase is just a UI for PGP/GPG (well that was what it was before it became a Borg). The problem with GPG: 1. You need to keep your private key very private, which is incompatible with the idea that you might have several devices you normally use. GPG itself does not provide you with a mechanism to sync your private keys between devices because this is a super insecure thing to do without some serious work. 2. GPG requires that you and another person verify each others' public keys out of band. I need to meet you in a parking lot to validate your key fingerprint while you validate mine. 3. GPG's web of trust relies on attaching public keys to real world identities. You are asked to validate government documents when verifying public keys. That's incompatible with how a lot of us want to work. Note that this isn't a built-in requirement, but GPG itself provides no guidance on how to validate user123 on GitHub, just User Onetwothree Jr in real life. 4. GPG's UI is almost as arcane as tar :) Keybase solved this by: 1. Providing a secure way to manage private keys across devices. 2. Outsourcing proof of identity to other providers. Its use case is validating the identity of user123 on GitHub, which happens to also work fairly well for CelebrityName on Twitter, or FriendName on Facebook. 3. See #2: social proof means you can attach that proof to any kind of identity. 4. GUI + nice TUI works better. Where Keybase fell short was that a non-techie will not understand much about "social proof" and the only kind of social proof they have access to is limited to Twitter, Facebook, and Instagram. Signal's solution to this was simpler: you have a QR code/set of numbers that represent your fingerprint right in the app. You show me yours, I'll show you mine. We get connected by phone number or email. That's it. If Signal was built on a federated platform it'd be perfect and nothing about it from what I understand prevents that.
miloignis 6y ago
That sounds kinda similar to the problem Matrix solved with cross-signing, how when you login to a new device and verify it with one of your already logged-in devices, it can request your old message keys E2EE so you get all your history. Maybe a similar thing could be built on top of it?

zikduruqe 6y ago

This is why I use https://keys.pub https://keys.pub and/or Magic Wormhole.