5 ms·

I think it would make more sense to point to the Matrix protocol instead of Signal. Matrix is actually decentralized like Email, allows any service provider as

I think it would make more sense to point to the Matrix protocol instead of Signal. Matrix is actually decentralized like Email, allows any service provider as well as app provider - free to choose as a user. It supports Perfect Forward Secrecy (based on the Signal Protocol), arbitrary many devices and "one verification for each individual". Well, you might argue Matrix stores meta data server side (the ones chosen), while Signal at least doesn't have to. But do you really want to give up all that freedom trusting a single service provider in that really no data is kept? Maybe you can wait until Matrix allows you to avoid signing up on a server using P2P[0], then you have got it all, and don't have to commit to an alternative that has advantages, but also big draw backs. [0] https://news.ycombinator.com/item?id=27077660 https://news.ycombinator.com/item?id=27077660

daneel_w 5y ago
Or XMPP/Jabber.
- approxim8ion 5y ago
  XMPP is good, great even, but it has the same issue as email where you could interface with someone not using OMEMO or whatever your encryption scheme is and it would fall back to plaintext.
  - MattJ100 5y ago
    The story is not quite the same for XMPP. For example, with XMPP you can determine ahead of time whether or not a contact has OMEMO. And clients configured to only use OMEMO won't "fall back".
    - approxim8ion 5y ago
      Apologies, clearly my understanding of XMPP is not the best. However, both points you mentioned are client dependent, right?
      - giantrobot 5y ago
        The fallback has to be client dependent. With E2EE the server can't decrypt messages. So there's no way for the server to decrypt the message to "downgrade" the channel. The client is also the node responsible for encrypting all messages for all recipients so it has to know if any of those recipients haven't done a key exchange.
      - MattJ100 5y ago
        Yes. It's client-dependent for all other systems too. For example Signal's end-to-end encryption only works if both parties are using Signal. For XMPP the difference is that there are multiple E2EE clients to choose from (see https://omemo.top/ https://omemo.top/ ). And if someone chooses to use a none E2EE client, you still have the choice whether to communicate with them without E2EE, if that's acceptable to you in the specific context (not all conversations demand E2EE).
  - daneel_w 5y ago
    With XMPP that's thankfully up to you to decide through client preferences, and in this way your choice also propagates across XMPP servers.
- TedDoesntTalk 5y ago
  I’ve not seen XMPP used for store-and-forward messaging, like email, but I suppose it could be done. Every single XMPP client I’ve used sucks. Really suck. And there are always quirks setting up group chat and image sharing with XMPP servers.
  - daneel_w 5y ago
    Roster/conversation capability (server holding message until recipient comes online) is a basic extension to XMPP. I don't think I've ever used a Jabber server not supporting it, and all the popular clients support it.
    - approxim8ion 5y ago
      I believe they mean the messages being held on a server even post delivery.
      - daneel_w 5y ago
        Yes. Same thing, same feature. This is what "conversation" mode is, also known as message archive management, or XEP-0313 (a standardized extension/feature of XMPP).
    - TedDoesntTalk 5y ago
      Have you configured a server for that? I have. Not fun. Same with group chat.
      - daneel_w 5y ago
        Yes I have. It's a rather straight-forward and quick job with Prosody.
- arcbyte 5y ago
  I thought we all decided a decade ago that XMPP/Jabber was way too complicated to implement and not to use it?
  - daneel_w 5y ago
    I don't think so. Though it is possible that you decided so on your own.
mananaysiempre 5y ago
I love the idea behind Matrix and dearly want it to succeed, but unlike IRC and XMPP as well as (to a lesser extent) email and netnews, it has the inherent problem that it implements a genuinely difficult thing: a large partition-tolerant distributed database without a central authority and even a bit of mistrust between nodes. Now that I’ve put this in writing, I wonder if there were any attempts to do this at all before the current generation of systems. (IRC and netnews basically YOLO their consistency away because they can’t afford it, which was indeed correct when they were designed, but people did a lot of distributed systems work between then and now...) That implies that a Matrix server is necessarily somewhat heavy and rather difficult to implement. This makes me think that the federated network must by necessity exist in a fragile and tender state while Matrix is young, and need to be tended to with attention and care. The current stewards of the protocol don’t seem to be giving it that, growing features (even if good and competently designed ones) while treating the surroundings with something of a “they will come” approach. (To put it uncharitably: Look, there are now a whole two comprehensive server implementations, and the second one you could even afford a server for! Yeah, the Gnome people gave up on independently implementing a secure client, but surely an Electron one should be enough?..) I’ve spent a very limited time studying the situation so I am not going to make any dire-sounding prophecies; besides, I actively don’t want any such prophecies to come true. What I am is worried. It doesn’t take much for a protocol to become a non-interoperable tangle of implementation details, and Matrix is an extraordinarily ambitious one.
- remirk 5y ago
  I agree that Matrix is quite complicated. However, adding new features doesn't have to make it that more complicated. I get the impression that it's not that bad as most new features are actually based on existing parts of the protocol. Everything is just based on events in a room. Most 'special' events have a fallback mechanism to text, to insure clients that haven't implemented the event type can still show the information to the user. Replies and stickers make use of this for instance.
  - mananaysiempre 5y ago
    Short and harsh (likely too harsh): My point is not that Matrix is complicated, thus we should avoid making it more so. My point is that the approach that Matrix chooses, even in its most minimal form, requires Matrix to be complex and resource-hungry, thus it seems prudent to direct attention and effort towards cultivating a multitude of implementations and deployments rather than enhancing marketability. A social argument against features, not the standard technical one.
tptacek 5y ago
I wrote this article. Honestly, I don't care which secure messenger you use. I'm going to recommend the one I feel is safest, but they're all leagues better than email. Don't use encrypted email; that's the point of the article, not "use Signal".

daneel_w 5y ago

Or XMPP/Jabber.

approxim8ion 5y ago
XMPP is good, great even, but it has the same issue as email where you could interface with someone not using OMEMO or whatever your encryption scheme is and it would fall back to plaintext.
- MattJ100 5y ago
  The story is not quite the same for XMPP. For example, with XMPP you can determine ahead of time whether or not a contact has OMEMO. And clients configured to only use OMEMO won't "fall back".
  - approxim8ion 5y ago
    Apologies, clearly my understanding of XMPP is not the best. However, both points you mentioned are client dependent, right?
    - giantrobot 5y ago
      The fallback has to be client dependent. With E2EE the server can't decrypt messages. So there's no way for the server to decrypt the message to "downgrade" the channel. The client is also the node responsible for encrypting all messages for all recipients so it has to know if any of those recipients haven't done a key exchange.
    - MattJ100 5y ago
      Yes. It's client-dependent for all other systems too. For example Signal's end-to-end encryption only works if both parties are using Signal. For XMPP the difference is that there are multiple E2EE clients to choose from (see https://omemo.top/ https://omemo.top/ ). And if someone chooses to use a none E2EE client, you still have the choice whether to communicate with them without E2EE, if that's acceptable to you in the specific context (not all conversations demand E2EE).
- daneel_w 5y ago
  With XMPP that's thankfully up to you to decide through client preferences, and in this way your choice also propagates across XMPP servers.
TedDoesntTalk 5y ago
I’ve not seen XMPP used for store-and-forward messaging, like email, but I suppose it could be done. Every single XMPP client I’ve used sucks. Really suck. And there are always quirks setting up group chat and image sharing with XMPP servers.
- daneel_w 5y ago
  Roster/conversation capability (server holding message until recipient comes online) is a basic extension to XMPP. I don't think I've ever used a Jabber server not supporting it, and all the popular clients support it.
  - approxim8ion 5y ago
    I believe they mean the messages being held on a server even post delivery.
    - daneel_w 5y ago
      Yes. Same thing, same feature. This is what "conversation" mode is, also known as message archive management, or XEP-0313 (a standardized extension/feature of XMPP).
  - TedDoesntTalk 5y ago
    Have you configured a server for that? I have. Not fun. Same with group chat.
    - daneel_w 5y ago
      Yes I have. It's a rather straight-forward and quick job with Prosody.
arcbyte 5y ago
I thought we all decided a decade ago that XMPP/Jabber was way too complicated to implement and not to use it?
- daneel_w 5y ago
  I don't think so. Though it is possible that you decided so on your own.

mananaysiempre 5y ago

I love the idea behind Matrix and dearly want it to succeed, but unlike IRC and XMPP as well as (to a lesser extent) email and netnews, it has the inherent problem that it implements a genuinely difficult thing: a large partition-tolerant distributed database without a central authority and even a bit of mistrust between nodes. Now that I’ve put this in writing, I wonder if there were any attempts to do this at all before the current generation of systems. (IRC and netnews basically YOLO their consistency away because they can’t afford it, which was indeed correct when they were designed, but people did a lot of distributed systems work between then and now...) That implies that a Matrix server is necessarily somewhat heavy and rather difficult to implement. This makes me think that the federated network must by necessity exist in a fragile and tender state while Matrix is young, and need to be tended to with attention and care. The current stewards of the protocol don’t seem to be giving it that, growing features (even if good and competently designed ones) while treating the surroundings with something of a “they will come” approach. (To put it uncharitably: Look, there are now a whole two comprehensive server implementations, and the second one you could even afford a server for! Yeah, the Gnome people gave up on independently implementing a secure client, but surely an Electron one should be enough?..) I’ve spent a very limited time studying the situation so I am not going to make any dire-sounding prophecies; besides, I actively don’t want any such prophecies to come true. What I am is worried. It doesn’t take much for a protocol to become a non-interoperable tangle of implementation details, and Matrix is an extraordinarily ambitious one.

remirk 5y ago
I agree that Matrix is quite complicated. However, adding new features doesn't have to make it that more complicated. I get the impression that it's not that bad as most new features are actually based on existing parts of the protocol. Everything is just based on events in a room. Most 'special' events have a fallback mechanism to text, to insure clients that haven't implemented the event type can still show the information to the user. Replies and stickers make use of this for instance.
- mananaysiempre 5y ago
  Short and harsh (likely too harsh): My point is not that Matrix is complicated, thus we should avoid making it more so. My point is that the approach that Matrix chooses, even in its most minimal form, requires Matrix to be complex and resource-hungry, thus it seems prudent to direct attention and effort towards cultivating a multitude of implementations and deployments rather than enhancing marketability. A social argument against features, not the standard technical one.

tptacek 5y ago

I wrote this article. Honestly, I don't care which secure messenger you use. I'm going to recommend the one I feel is safest, but they're all leagues better than email. Don't use encrypted email; that's the point of the article, not "use Signal".