• barsquid@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    4 hours ago

    Wait, if not Matrix, what is a good software for this? I thought it was preferred for having an E2E encryption implementation.

    • toastal@lemmy.ml
      link
      fedilink
      English
      arrow-up
      2
      ·
      31 minutes ago

      If you’re the type that that doesn’t like the kind of energy wasted for cryptocurrencies, you will be suprised that the eventual consistency the whole network is copying all message, all attachments of all users per host. This is also why it takes on the order of minutes to just join a new room or freshly launch an app as all of this syncing needs to happen. This also causes the self-hosting to be priced out as medium-sized (in terms of users) or low-spec hardware cannot keep up with neither the CPU/RAM nor storage space required to maintain a node on the network… which is pretty wild for mostly text in 2024. This causes folks to host their own single-user instances, or in reality almost everyone flocks to Matrix.org or a server Matrix.org hosts (or unfederates only serving to those on the host which is one way). With all of this centralization, almost all metadata ends up in the hands of Matrix.org (maliciously or not) due to the design of the protocol needing to have the entire history of everything. Copying Slack/Telegram/Discords UX in this sense was not the best call. Eventually consistency does add a resilience & uptime guarantee, but technically I don’t think those cost outweigh the benefits in most cases.

      End-to-end encryption (E2EE) is important, but it’s not always required. Many rooms are purposefully public so IRC(v3) fits most basic needs (tho I am not a fan of needing pastebins & separate image uploads). In the case of these encryption algorithms, almost everything is using the same double-ratchet encryption seen in Signal for DMs (provided you can verify there isn’t a backdoor via source code availability). If you need more features like E2EE or reactions or threading or pasting source code, XMPP is & has been the gold standard. It treats chat as ephemeral (while still having history, archiving, & no need for bouncers) where missing an old messages isn’t seen as the end of the world. Important, long-lived announcements & information should be in the Atom/RSS feed, mailing list, or forum (or Movim if you want this task on the XMPP network via PubSub) as these are the proper platforms for these tasks (we know how horrible searching a massive chat room is UX-wise… it’s basically gone in many cases, & in the case of proprietary systems is in a literal knowledge black hole). XMPP was built to run efficiently on machines from last decade so it is just as lean in both clients & servers now saving you money, data, storage, battery.

      SimpleX is a project worth following, but I am not too sure how it handles ephemeral vs. eventual consistency & it is also far too new to have multiple clients & a proper decentralized community. Maybe this will come with time, but I am only keeping tabs on it for now.

      • barsquid@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        16 minutes ago

        Oh, yikes, that does seem poorly-designed for the majority of use cases. Thank you for taking the time to write that up and recommend alternatives, I really appreciate understanding it better.