3 ms·

This is very heavily biased. Many of the points "against matrix" aren't very well elaborated on or plainly wrong or outdated, such as the one stating that you c

by meibo 5y ago

This is very heavily biased. Many of the points "against matrix" aren't very well elaborated on or plainly wrong or outdated, such as the one stating that you can't viably run your own node. There's many things happening at the moment to make that easier, as well as a push to move off server nodes into p2p "device nodes" that contain your user data. Matrix' federation isn't weak, Matrix.org just hosts the biggest node. If Matrix.org would disappear today, all that would be lost is users and chat for people on that node, the rest of the network would continue working as usual. A few friends of mine and me all host our own nodes, so we wouldn't even notice it, basically. XMPP doesn't have this as all the big implementations are proprietary and incompatible.

fiddlerwoaroof 5y ago
The problem I have with matrix is more that it’s a real pain to write your own client that supports E2EE and such
- Macha 5y ago
  Is it easier to write an xmpp client which supports E2EE?
- Arnavion 5y ago
  I've been writing my own client (for kicks) from scratch by just following the specs, including E2EE. I have to agree - the documentation is terrible. It's split between [1], [2] and [3] and probably many more, but [2] is "unstable" (see [4]) and [3] is informal (see [5]). All the docs are also full of broken intra-links, so I've been even afraid of having `// Ref: https://matrix.org/docs/ https://matrix.org/docs/...` comments in my code just because I expect they'll become broken some time later. The docs are often written from a JS perspective. For example, every mention of PBKDF2 talks about using "using SHA-512 for the hash function", but PBKDF2 uses a two-input PRF, usually an HMAC. What they mean is that it uses HMAC-SHA512, but I assume they keep saying "using SHA-512 for the hash function" because that's what the JS window.crypto.subtle API uses. [6] Also, God the keys, so many keys. Keys used to encrypt other keys used to encrypt other keys, with different kinds of encryption and formats each time... [1]: https://matrix.org/docs/spec/client_server/r0.6.1 https://matrix.org/docs/spec/client_server/r0.6.1 [2]: https://spec.matrix.org/unstable/client-server-api/ https://spec.matrix.org/unstable/client-server-api/ [3]: https://matrix.org/docs/guides/implementing-more-advanced-e-2-ee-features-such-as-cross-signing/ https://matrix.org/docs/guides/implementing-more-advanced-e-... [4]: AFAICT there is no stable version of [2]. [1] is not it; [1] and [2] have completely different content. Eg [2] explains how "m.secret_storage.key.<key_id>" events work, but this information is not present in [1]. [5]: As a concrete example, I've been working on deriving secret keys from passphrases for a few days, but it always derived the wrong key. I finally figured out why this morning - [3] implies the salt is base64-encoded but it's actually utf8-encoded, so I was decoding it incorrectly. [6]: https://developer.mozilla.org/en-US/docs/Web/API/Pbkdf2Params#properties https://developer.mozilla.org/en-US/docs/Web/API/Pbkdf2Param...
  - miloignis 5y ago
    I believe that [1] is indeed the stable version of [2] - [2] contains things that [1] does not because it has new bits merged into it that have not yet been in a stable release. I think some of the confusion stems from them also swapping to a new version of the webpage in [2] that hasn't rolled out to the stable spec in [1] yet. Good warning on the JS stuff, I actually just started reading through the E2EE docs again to prep for my client, and I appreciate the heads up!
    - Arnavion 5y ago
      It is impossible to implement E2EE without the information in [2] that is not present in [1]. [2] is how you get access to the storage key that Element etc used to store encrypted secrets in your account data. So if anyone's goal is to build a Matrix client that's actually useful, [2] is unavoidable.
pkulak 5y ago
It took me an afternoon to get a Matrix server running. There's a PPA for it, it's in the Arch community repo... I don't know how much easier it could get.
- meibo 5y ago
  There's also https://github.com/spantaleev/matrix-docker-ansible-deploy https://github.com/spantaleev/matrix-docker-ansible-deploy which can basically set up an entire matrix "ecosystem" including telephony, bridges and bots with one command and some basic configuration.

by meibo 5y ago

fiddlerwoaroof 5y ago

The problem I have with matrix is more that it’s a real pain to write your own client that supports E2EE and such

Macha 5y ago
Is it easier to write an xmpp client which supports E2EE?
Arnavion 5y ago
I've been writing my own client (for kicks) from scratch by just following the specs, including E2EE. I have to agree - the documentation is terrible. It's split between [1], [2] and [3] and probably many more, but [2] is "unstable" (see [4]) and [3] is informal (see [5]). All the docs are also full of broken intra-links, so I've been even afraid of having `// Ref: https://matrix.org/docs/ https://matrix.org/docs/...` comments in my code just because I expect they'll become broken some time later. The docs are often written from a JS perspective. For example, every mention of PBKDF2 talks about using "using SHA-512 for the hash function", but PBKDF2 uses a two-input PRF, usually an HMAC. What they mean is that it uses HMAC-SHA512, but I assume they keep saying "using SHA-512 for the hash function" because that's what the JS window.crypto.subtle API uses. [6] Also, God the keys, so many keys. Keys used to encrypt other keys used to encrypt other keys, with different kinds of encryption and formats each time... [1]: https://matrix.org/docs/spec/client_server/r0.6.1 https://matrix.org/docs/spec/client_server/r0.6.1 [2]: https://spec.matrix.org/unstable/client-server-api/ https://spec.matrix.org/unstable/client-server-api/ [3]: https://matrix.org/docs/guides/implementing-more-advanced-e-2-ee-features-such-as-cross-signing/ https://matrix.org/docs/guides/implementing-more-advanced-e-... [4]: AFAICT there is no stable version of [2]. [1] is not it; [1] and [2] have completely different content. Eg [2] explains how "m.secret_storage.key.<key_id>" events work, but this information is not present in [1]. [5]: As a concrete example, I've been working on deriving secret keys from passphrases for a few days, but it always derived the wrong key. I finally figured out why this morning - [3] implies the salt is base64-encoded but it's actually utf8-encoded, so I was decoding it incorrectly. [6]: https://developer.mozilla.org/en-US/docs/Web/API/Pbkdf2Params#properties https://developer.mozilla.org/en-US/docs/Web/API/Pbkdf2Param...
- miloignis 5y ago
  I believe that [1] is indeed the stable version of [2] - [2] contains things that [1] does not because it has new bits merged into it that have not yet been in a stable release. I think some of the confusion stems from them also swapping to a new version of the webpage in [2] that hasn't rolled out to the stable spec in [1] yet. Good warning on the JS stuff, I actually just started reading through the E2EE docs again to prep for my client, and I appreciate the heads up!
  - Arnavion 5y ago
    It is impossible to implement E2EE without the information in [2] that is not present in [1]. [2] is how you get access to the storage key that Element etc used to store encrypted secrets in your account data. So if anyone's goal is to build a Matrix client that's actually useful, [2] is unavoidable.

pkulak 5y ago

It took me an afternoon to get a Matrix server running. There's a PPA for it, it's in the Arch community repo... I don't know how much easier it could get.

meibo 5y ago
There's also https://github.com/spantaleev/matrix-docker-ansible-deploy https://github.com/spantaleev/matrix-docker-ansible-deploy which can basically set up an entire matrix "ecosystem" including telephony, bridges and bots with one command and some basic configuration.