8 ms·

It's kinda ironic that Keybase disappears into Zoom the day after Matrix/Riot enabled end-to-end encryption by default, with cross-signed device verification si

It's kinda ironic that Keybase disappears into Zoom the day after Matrix/Riot enabled end-to-end encryption by default, with cross-signed device verification similar to Keybase's concept of connected keys - see https://blog.riot.im/e2e-encryption-by-default-cross-signing-is-here/ https://blog.riot.im/e2e-encryption-by-default-cross-signing.... In other words, a fully open source (and open standardised) alternative continues to exist in the form of Matrix. [disclaimer: project lead for Matrix]

KAMSPioneer 7y ago
Holy crap, the Matrix/Riot teams have been busy! Congrats on the progress, it's very exciting to watch. Although I have a Matrix account I have had trouble getting friends/family to switch with me (mostly non-technical folks, and Signal was much stickier for them), it might be time to convince them to try again. Thanks to you and the team for all the hard work!
- mikro2nd 7y ago
  Interesting. I've turned quite a number of non-technical friends/family into Signal users, just by telling them, "Here's the messaging app I'm using if you want to talk to me..." without mention of encryption until they're already hooked. Uniformly comments have been favourable concerning ease-of-use and quality of voice/video calls (at least compared to what they're already used to -- generally Zoom or Skype), and several of them have pushed it out to their networks in turn.
  - KAMSPioneer 7y ago
    Oh definitely, my experience is similar. Sorry if I was unclear: by Signal being "stickier" than Matrix I meant that I've had better luck getting friends to continue using Signal than continue using Matrix. So far, anyway.
  - SAI_Peregrinus 7y ago
    Ease of use is the big elephant-in-the-room issue for Matrix. The only way I've found to join a room is the `/join` command. There's a GUI search, but it doesn't work. Users have to pick their identity provider, their home server, etc. Lots of choices, scary messages, and generally annoying to set up. Services that depend on someone who is technically inclined setting things up never become widespread outside technical communities. If users pick an unreliable server to connect to, or there's a network split, things break, just like IRC does. There are several clients, all slightly different. It's up to the user to pick which one they want, when they've never used any of them and just want something to work. It's better than IRC, but that bar is so low you'd have to bury it to get any lower.
    - Arathorn 7y ago
      The GUI search should work fine these days. (It was broken about 6 months ago due to the room lists getting too big, but was fixed in https://github.com/matrix-org/synapse/pull/6019 https://github.com/matrix-org/synapse/pull/6019). It's true you have to pick a server to use, but we try to provide decent defaults (although it's true matrix.org has been overloaded recently). We're trying to simplify onboarding via P2P Matrix - by default, you'd start off entirely P2P, and only pick a server if you want to 'anchor' your account somewhere. I have a feeling you may be going off outdated impressions here; we've been desperately trying to improve UI/UX (as per https://blog.riot.im/e2e-encryption-by-default-cross-signing-is-here/#what-else-has-been-going-on-in-riot https://blog.riot.im/e2e-encryption-by-default-cross-signing... and https://blog.riot.im/e2e-encryption-by-default-cross-signing-is-here/#what-s-next https://blog.riot.im/e2e-encryption-by-default-cross-signing...).
      - SAI_Peregrinus 7y ago
        I last used it for the recent (Thursday, April 30th) Rust Zurich meetup. I've got it installed via apt, and updated to riot-web version: 1.6.0 olm version: 3.1.3 Search didn't find the room. /join did. Also it just took me over a minute to find the version number, because the client settings are hidden in a dropdown menu under my user name, not in the gear icon (tooltip "settings") on the upper left or the hamburger menu that says explore, and even in the right dropdown it's under "settings->help & about" instead of just under "help" where the "about" box has lived in every single program since the '90s...
ryukafalz 7y ago
Hi! I use Matrix a lot, but a privacy-sensitive group of my friends recently switched to Keybase largely due to the per-room/per-message retention policies. This might be a good opportunity to convince them to jump ship, and I know something similar has been in the works for Matrix, but do you know where it is on the list of priorities? (Congrats on the cross-signing release though, it's been a long time coming and it's been working really well!)
- Arathorn 7y ago
  We've had per-room/per-message retention policies in Matrix for months now (although Riot hasn't exposed UX to configure them yet, as we were drowning in cross-signing work). https://github.com/matrix-org/synapse/blob/master/docs/message_retention_policies.md https://github.com/matrix-org/synapse/blob/master/docs/messa... has the details.
  - ryukafalz 7y ago
    Hmm, that document seems to indicate they're disabled by default in synapse though? >Note that over every server in the room, only the ones with support for message retention policies will actually remove expired events. This support is currently not enabled by default in Synapse.
    - Arathorn 7y ago
      True - we did a slow roll-out whilst testing. It should be okay to turn on everywhere now :)
- Semaphor 7y ago
  Hijacking this: Does anyone know if there’s a Matrix client (out or in dev) that has the UI/UX of old 1on1 messengers (ICQ, MSN) and not chatrooms (IRC, Slack)? Specifically not the weird list of bubbles on the side, but instead a list of accounts/rooms and a window per chat.
  - Arathorn 7y ago
RMPR 7y ago
I was about to complain about your desktop Electron app but it seems that spectral[0] is already usable without any hassle (build from source, ...) at least on Fedora, time to reactivate my Matrix account, keep up with the great work 0: https://gitlab.com/spectral-im/spectral https://gitlab.com/spectral-im/spectral
- roblabla 7y ago
  There's also Fractal[0] which uses GTK+ instead of Qt, and is maintained by the Gnome foundation and planned to be used by the Librem 5 AFAIK. [0]: https://matrix.org/docs/projects/client/fractal https://matrix.org/docs/projects/client/fractal
  - RMPR 7y ago
    Unfortunately, can't find it in the Fedora's repo
    - uneekname 7y ago
      I know it isn't ideal, but Fractal is available through Flatpak and Snap
- Hitton 7y ago
  Alternatively Mirage[0] - Qt + Python. There is really a lot to choose from with Matrix. The beauty of open protocol. [0]: https://github.com/mirukana/mirage https://github.com/mirukana/mirage
  - RMPR 7y ago
    Seems like on Fedora the only mirage available is Mirage the image viewer http://mirageiv.sourceforge.net/ http://mirageiv.sourceforge.net/
    - RIMR 7y ago
      You can install the other Mirage on Fedora by following the instruction in the Github link...
packetlost 7y ago
Matrix and Keybase have entirely different goals and functionalities. There's barely any feature overlap besides end-to-end encrypted messaging, but it's not like XMPP hasn't had that for years. I think it's silly to even compare the two
Legogris 7y ago
I've been looking into Matrix as a "personal IM bridge" and I'm thinking this could be a way for Matrix to get traction. Let's say you're in a position that I think may here are: You would prefer to use IM in a secure way. Let me qualify "secure" for this purpose meaning: Encryption of communication in rest and transit; not relying on a single infra/network/service provider; being able to communicate with new peers easily without having to sign up with new providers; not requiring sign-ups leaking PIIs such as phone numbers; being able to sync message history across devices; all of this should hold for group conversations. matrix.org seems to be on the right track towards that. Feature-wise there's some missing pieces in terms of federation but the roadmap looks like the ambition is right. But in practice, it's realistically years until you can meet a random person in a bar and ask to join you on matrix to stay in touch, so many of us will still keep our accounts on the not-as-great platforms such as FB, Skype, WhatsApp, Signal. Given that, wouldn't it be nice to facilitate using those platforms in a way that 1) absolves you from the behavioral tracking that comes with most of the first-party web- and smartphone apps and 2) integrates them in the same UI? There are, of course, solutions to this end. Bitblbee (IRC gateway), libpurple (pidgin, finch), third-party clients like franz. I'm sure there are many here who have or are using libpurple or bitlbee for this. But matrix also has bridges! I'm thinking one potential way that matrix could really get traction and seed the network infrastructure would be just that. Given stable gateways for the IM networks people already use, it's suddenly a much easier sell to get enthusiasts and power-users to self-host matrix servers just to solve their own bridging needs and get a unified flow for disparate protocols. As that grows, eventually there's a large spread-out flora of matrix servers that can become part of something larger. I think if there's one thing that can make matrix succeed in it's mission, it's stable, feature-complete (or at least ticking the important boxes for the majority) bridges to mainstream services such as Facebook, Whatsapp, Signal, LINE, Skype, Google and Keybase. I think this should be a focus for Matrix, and amazing it would be to have these be the fruit of voluntary contributors, some funding is likely required if it's to be sustainable as proprietary protocols and endpoints will inevitably break. What's your take on that? I realize it's a long comment and I'm in a bit of a rush, but I'd be really curious to hear how you think about these things.
- toyg 7y ago
  I'm not Arathorn (and not even a Matrix user yet, barely ever on Signal too), but the problem with bridges to 3rd-parties is that you're effectively allowing these non-Matrix users to keep doing what they're doing, instead of incentivising them to switch. The walled gardens know this very well - that's why they've discontinued their XMPP gateways.
seemslegit 7y ago
What endgame do you think your company has other than eventually selling out its userbase in one way or another ?
- Arathorn 7y ago
  Matrix isn’t a company, it’s a non-profit foundation, expressly set up to protect its users: see https://matrix.org/foundation https://matrix.org/foundation for details. Riot is a Matrix client made by New Vector (https://vector.im https://vector.im), the company started by the team who originally created Matrix. The endgame there is to sell Matrix hosting (https://modular.im https://modular.im), support and other value-added services for Matrix. We are categorically not going to sell out our userbase - and we have no reason to; if we did, they’d just move to a different Matrix service provider.
  - seemslegit 7y ago
    I can imagine keybase delivering a similar statement back in the day, good luck.
    - Legogris 7y ago
      I think a key difference here is fully open and collaborative specs, with Apache-licensed reference implementations for server and client that they dogfood themselves. It's also getting federated. So protocol, tech and network can live on regardless of who's running the servers people are using or driving the development of implementations.
      - seemslegit 7y ago
        Until one day the foundation decides federation is not in the best interest of the community, the standards and reference implementation start to reflect closely the interests of the leading player[s] with other implementations having to play catchup. It would have been a very cynical take if it wasn't business as usual in our industry.
zfnmxt 7y ago
It's funny, but I think I get most of my Riot/Matrix news from your comments scattered about hacker news. Anyway, I run a matrix server for my family (and we all use the Riot client) and the number one issue is encryption and mysterious "Unable to Decrypt" messages. (Closely followed by how rough the Android client is.) This fixes all of that (well, once RiotX replaces the standard Android client) and I think it will remove a lot of friction. Thanks for your work!
eslaught 7y ago
The thing I like about Keybase is that keys are always generated client-side and never leave the client, and all of the functionality associated with adding/removing devices is done in a way so that there's no way for a server to tamper with it (aside from denying service). Is that true in Matrix? Several services advertise themselves as "end-to-end" encrypted, but then when you poke harder it turns out either there is some sort of TOFU (so an opportunity for the server to insert itself) or else there is no device continuity (which means in the case of e.g. Whatsapp that keys are reprovisioned almost promiscuously to avoid bad UX). Whatsapp is a particularly bad example because (a) I lose chat history when I move devices, and yet (b) the UX does not require an old device to authenticate the new one, so I can compromise conversations (at least moving forward) if I can compromise a server. How end-to-end is Matrix really, and how similar is the new support to Keybase's key management flow?
- Arathorn 7y ago
  Yes, Matrix is properly end-to-end encrypted (with all keys generated clientside) and has been independently audited as such: https://www.nccgroup.trust/us/our-research/matrix-olm-cryptographic-review/ https://www.nccgroup.trust/us/our-research/matrix-olm-crypto.... We have gone to huge efforts to prevent MITMs via device verification and cross signing - which specifically addresses both problems of a) losing chat history when you move between devices (via https://github.com/uhoreg/matrix-doc/blob/e2e_backup/proposals/1219-storing-megolm-keys-serverside.md https://github.com/uhoreg/matrix-doc/blob/e2e_backup/proposa...) and b) requiring cross-signing when you log in on a new device, to spread trust to new logins, as per https://github.com/uhoreg/matrix-doc/blob/cross-signing2/proposals/1756-cross-signing.md https://github.com/uhoreg/matrix-doc/blob/cross-signing2/pro.... All keys are stored clientside, with the exception of if you enable serverside key backup, when they are then encrypted and optionally stored serverside to allow you to recover your history if you lose all your devices.
  - eslaught 7y ago
    Just to confirm, if I turn off backup, does anything stop working aside from needing at least one device to be operational at any given time? Edit: Specifically, is key backup tied to the ability to recover account history on a new device, or can I still get that with key backup disabled as long as I have at least one other device active? Edit 2: Can you address this paragraph: > One point for super-paranoid users: currently the private key used to sign your own devices and the private key used to sign other users are encrypted by your recovery passphrase/key and stored on the server to allow recovery if you lose all your devices. We also allow signing keys to be shared (gossiped) between devices, but right now the implementation also stores them encrypted on the server too. This restriction will be fixed in future, but for now if you don’t trust your server with encrypted keys, you may want to hold off on using cross-signing. If I understand correctly, sounds like security is based on the complexity of your recovery passphrase and an implicit assumption that the passphrase doesn't get transmitted to the server... is that correct?

KAMSPioneer 7y ago

Holy crap, the Matrix/Riot teams have been busy! Congrats on the progress, it's very exciting to watch. Although I have a Matrix account I have had trouble getting friends/family to switch with me (mostly non-technical folks, and Signal was much stickier for them), it might be time to convince them to try again. Thanks to you and the team for all the hard work!

mikro2nd 7y ago
Interesting. I've turned quite a number of non-technical friends/family into Signal users, just by telling them, "Here's the messaging app I'm using if you want to talk to me..." without mention of encryption until they're already hooked. Uniformly comments have been favourable concerning ease-of-use and quality of voice/video calls (at least compared to what they're already used to -- generally Zoom or Skype), and several of them have pushed it out to their networks in turn.
- KAMSPioneer 7y ago
  Oh definitely, my experience is similar. Sorry if I was unclear: by Signal being "stickier" than Matrix I meant that I've had better luck getting friends to continue using Signal than continue using Matrix. So far, anyway.
- SAI_Peregrinus 7y ago
  Ease of use is the big elephant-in-the-room issue for Matrix. The only way I've found to join a room is the `/join` command. There's a GUI search, but it doesn't work. Users have to pick their identity provider, their home server, etc. Lots of choices, scary messages, and generally annoying to set up. Services that depend on someone who is technically inclined setting things up never become widespread outside technical communities. If users pick an unreliable server to connect to, or there's a network split, things break, just like IRC does. There are several clients, all slightly different. It's up to the user to pick which one they want, when they've never used any of them and just want something to work. It's better than IRC, but that bar is so low you'd have to bury it to get any lower.
  - Arathorn 7y ago
    The GUI search should work fine these days. (It was broken about 6 months ago due to the room lists getting too big, but was fixed in https://github.com/matrix-org/synapse/pull/6019 https://github.com/matrix-org/synapse/pull/6019). It's true you have to pick a server to use, but we try to provide decent defaults (although it's true matrix.org has been overloaded recently). We're trying to simplify onboarding via P2P Matrix - by default, you'd start off entirely P2P, and only pick a server if you want to 'anchor' your account somewhere. I have a feeling you may be going off outdated impressions here; we've been desperately trying to improve UI/UX (as per https://blog.riot.im/e2e-encryption-by-default-cross-signing-is-here/#what-else-has-been-going-on-in-riot https://blog.riot.im/e2e-encryption-by-default-cross-signing... and https://blog.riot.im/e2e-encryption-by-default-cross-signing-is-here/#what-s-next https://blog.riot.im/e2e-encryption-by-default-cross-signing...).
    - SAI_Peregrinus 7y ago
      I last used it for the recent (Thursday, April 30th) Rust Zurich meetup. I've got it installed via apt, and updated to riot-web version: 1.6.0 olm version: 3.1.3 Search didn't find the room. /join did. Also it just took me over a minute to find the version number, because the client settings are hidden in a dropdown menu under my user name, not in the gear icon (tooltip "settings") on the upper left or the hamburger menu that says explore, and even in the right dropdown it's under "settings->help & about" instead of just under "help" where the "about" box has lived in every single program since the '90s...

ryukafalz 7y ago

Hi! I use Matrix a lot, but a privacy-sensitive group of my friends recently switched to Keybase largely due to the per-room/per-message retention policies. This might be a good opportunity to convince them to jump ship, and I know something similar has been in the works for Matrix, but do you know where it is on the list of priorities? (Congrats on the cross-signing release though, it's been a long time coming and it's been working really well!)

Arathorn 7y ago
We've had per-room/per-message retention policies in Matrix for months now (although Riot hasn't exposed UX to configure them yet, as we were drowning in cross-signing work). https://github.com/matrix-org/synapse/blob/master/docs/message_retention_policies.md https://github.com/matrix-org/synapse/blob/master/docs/messa... has the details.
- ryukafalz 7y ago
  Hmm, that document seems to indicate they're disabled by default in synapse though? >Note that over every server in the room, only the ones with support for message retention policies will actually remove expired events. This support is currently not enabled by default in Synapse.
  - Arathorn 7y ago
    True - we did a slow roll-out whilst testing. It should be okay to turn on everywhere now :)
Semaphor 7y ago
Hijacking this: Does anyone know if there’s a Matrix client (out or in dev) that has the UI/UX of old 1on1 messengers (ICQ, MSN) and not chatrooms (IRC, Slack)? Specifically not the weird list of bubbles on the side, but instead a list of accounts/rooms and a window per chat.
- Arathorn 7y ago

RMPR 7y ago

I was about to complain about your desktop Electron app but it seems that spectral[0] is already usable without any hassle (build from source, ...) at least on Fedora, time to reactivate my Matrix account, keep up with the great work 0: https://gitlab.com/spectral-im/spectral https://gitlab.com/spectral-im/spectral

roblabla 7y ago
There's also Fractal[0] which uses GTK+ instead of Qt, and is maintained by the Gnome foundation and planned to be used by the Librem 5 AFAIK. [0]: https://matrix.org/docs/projects/client/fractal https://matrix.org/docs/projects/client/fractal
- RMPR 7y ago
  Unfortunately, can't find it in the Fedora's repo
  - uneekname 7y ago
    I know it isn't ideal, but Fractal is available through Flatpak and Snap
Hitton 7y ago
Alternatively Mirage[0] - Qt + Python. There is really a lot to choose from with Matrix. The beauty of open protocol. [0]: https://github.com/mirukana/mirage https://github.com/mirukana/mirage
- RMPR 7y ago
  Seems like on Fedora the only mirage available is Mirage the image viewer http://mirageiv.sourceforge.net/ http://mirageiv.sourceforge.net/
  - RIMR 7y ago
    You can install the other Mirage on Fedora by following the instruction in the Github link...

packetlost 7y ago

Matrix and Keybase have entirely different goals and functionalities. There's barely any feature overlap besides end-to-end encrypted messaging, but it's not like XMPP hasn't had that for years. I think it's silly to even compare the two

Legogris 7y ago

I've been looking into Matrix as a "personal IM bridge" and I'm thinking this could be a way for Matrix to get traction. Let's say you're in a position that I think may here are: You would prefer to use IM in a secure way. Let me qualify "secure" for this purpose meaning: Encryption of communication in rest and transit; not relying on a single infra/network/service provider; being able to communicate with new peers easily without having to sign up with new providers; not requiring sign-ups leaking PIIs such as phone numbers; being able to sync message history across devices; all of this should hold for group conversations. matrix.org seems to be on the right track towards that. Feature-wise there's some missing pieces in terms of federation but the roadmap looks like the ambition is right. But in practice, it's realistically years until you can meet a random person in a bar and ask to join you on matrix to stay in touch, so many of us will still keep our accounts on the not-as-great platforms such as FB, Skype, WhatsApp, Signal. Given that, wouldn't it be nice to facilitate using those platforms in a way that 1) absolves you from the behavioral tracking that comes with most of the first-party web- and smartphone apps and 2) integrates them in the same UI? There are, of course, solutions to this end. Bitblbee (IRC gateway), libpurple (pidgin, finch), third-party clients like franz. I'm sure there are many here who have or are using libpurple or bitlbee for this. But matrix also has bridges! I'm thinking one potential way that matrix could really get traction and seed the network infrastructure would be just that. Given stable gateways for the IM networks people already use, it's suddenly a much easier sell to get enthusiasts and power-users to self-host matrix servers just to solve their own bridging needs and get a unified flow for disparate protocols. As that grows, eventually there's a large spread-out flora of matrix servers that can become part of something larger. I think if there's one thing that can make matrix succeed in it's mission, it's stable, feature-complete (or at least ticking the important boxes for the majority) bridges to mainstream services such as Facebook, Whatsapp, Signal, LINE, Skype, Google and Keybase. I think this should be a focus for Matrix, and amazing it would be to have these be the fruit of voluntary contributors, some funding is likely required if it's to be sustainable as proprietary protocols and endpoints will inevitably break. What's your take on that? I realize it's a long comment and I'm in a bit of a rush, but I'd be really curious to hear how you think about these things.

toyg 7y ago
I'm not Arathorn (and not even a Matrix user yet, barely ever on Signal too), but the problem with bridges to 3rd-parties is that you're effectively allowing these non-Matrix users to keep doing what they're doing, instead of incentivising them to switch. The walled gardens know this very well - that's why they've discontinued their XMPP gateways.

seemslegit 7y ago

What endgame do you think your company has other than eventually selling out its userbase in one way or another ?

Arathorn 7y ago
Matrix isn’t a company, it’s a non-profit foundation, expressly set up to protect its users: see https://matrix.org/foundation https://matrix.org/foundation for details. Riot is a Matrix client made by New Vector (https://vector.im https://vector.im), the company started by the team who originally created Matrix. The endgame there is to sell Matrix hosting (https://modular.im https://modular.im), support and other value-added services for Matrix. We are categorically not going to sell out our userbase - and we have no reason to; if we did, they’d just move to a different Matrix service provider.
- seemslegit 7y ago
  I can imagine keybase delivering a similar statement back in the day, good luck.
  - Legogris 7y ago
    I think a key difference here is fully open and collaborative specs, with Apache-licensed reference implementations for server and client that they dogfood themselves. It's also getting federated. So protocol, tech and network can live on regardless of who's running the servers people are using or driving the development of implementations.
    - seemslegit 7y ago
      Until one day the foundation decides federation is not in the best interest of the community, the standards and reference implementation start to reflect closely the interests of the leading player[s] with other implementations having to play catchup. It would have been a very cynical take if it wasn't business as usual in our industry.

zfnmxt 7y ago

It's funny, but I think I get most of my Riot/Matrix news from your comments scattered about hacker news. Anyway, I run a matrix server for my family (and we all use the Riot client) and the number one issue is encryption and mysterious "Unable to Decrypt" messages. (Closely followed by how rough the Android client is.) This fixes all of that (well, once RiotX replaces the standard Android client) and I think it will remove a lot of friction. Thanks for your work!

eslaught 7y ago

The thing I like about Keybase is that keys are always generated client-side and never leave the client, and all of the functionality associated with adding/removing devices is done in a way so that there's no way for a server to tamper with it (aside from denying service). Is that true in Matrix? Several services advertise themselves as "end-to-end" encrypted, but then when you poke harder it turns out either there is some sort of TOFU (so an opportunity for the server to insert itself) or else there is no device continuity (which means in the case of e.g. Whatsapp that keys are reprovisioned almost promiscuously to avoid bad UX). Whatsapp is a particularly bad example because (a) I lose chat history when I move devices, and yet (b) the UX does not require an old device to authenticate the new one, so I can compromise conversations (at least moving forward) if I can compromise a server. How end-to-end is Matrix really, and how similar is the new support to Keybase's key management flow?

Arathorn 7y ago
Yes, Matrix is properly end-to-end encrypted (with all keys generated clientside) and has been independently audited as such: https://www.nccgroup.trust/us/our-research/matrix-olm-cryptographic-review/ https://www.nccgroup.trust/us/our-research/matrix-olm-crypto.... We have gone to huge efforts to prevent MITMs via device verification and cross signing - which specifically addresses both problems of a) losing chat history when you move between devices (via https://github.com/uhoreg/matrix-doc/blob/e2e_backup/proposals/1219-storing-megolm-keys-serverside.md https://github.com/uhoreg/matrix-doc/blob/e2e_backup/proposa...) and b) requiring cross-signing when you log in on a new device, to spread trust to new logins, as per https://github.com/uhoreg/matrix-doc/blob/cross-signing2/proposals/1756-cross-signing.md https://github.com/uhoreg/matrix-doc/blob/cross-signing2/pro.... All keys are stored clientside, with the exception of if you enable serverside key backup, when they are then encrypted and optionally stored serverside to allow you to recover your history if you lose all your devices.
- eslaught 7y ago
  Just to confirm, if I turn off backup, does anything stop working aside from needing at least one device to be operational at any given time? Edit: Specifically, is key backup tied to the ability to recover account history on a new device, or can I still get that with key backup disabled as long as I have at least one other device active? Edit 2: Can you address this paragraph: > One point for super-paranoid users: currently the private key used to sign your own devices and the private key used to sign other users are encrypted by your recovery passphrase/key and stored on the server to allow recovery if you lose all your devices. We also allow signing keys to be shared (gossiped) between devices, but right now the implementation also stores them encrypted on the server too. This restriction will be fixed in future, but for now if you don’t trust your server with encrypted keys, you may want to hold off on using cross-signing. If I understand correctly, sounds like security is based on the complexity of your recovery passphrase and an implicit assumption that the passphrase doesn't get transmitted to the server... is that correct?