Using proprietary chat apps like Discord, Telegram, Slack, LINE, Meta’s WhatsApp / Messenger. Still judging on apps that require a SIM & mobile OS (like Android) primary device like Signal… or an expensive chat protocol like Matrix.
Hosting your code & bug tracker with a propietary forge like Microsoft GitHub when you say you support open source—but don’t even bother to apply the same mentality to your own project.
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.
Well, we start be organizing the folks of Lemmy to understand the values of the old protocols instead of trying to chase the shiny new ones. “Ain’t broke, don’t fix it”
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.
There are advantages, but I think a lot of folks are tracing trends in this space (including trying to copy Slack/Telegram/Discord rather than be better or strip the bad parts out). Newer ≠ better.
Using proprietary chat apps like Discord, Telegram, Slack, LINE, Meta’s WhatsApp / Messenger. Still judging on apps that require a SIM & mobile OS (like Android) primary device like Signal… or an expensive chat protocol like Matrix.
Hosting your code & bug tracker with a propietary forge like Microsoft GitHub when you say you support open source—but don’t even bother to apply the same mentality to your own project.
…Oh, the question was “secretly”.
Wait, if not Matrix, what is a good software for this? I thought it was preferred for having an E2E encryption implementation.
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.
I have an XMPP app on my phone and I am so sad it isn’t more popular, because it is sooo responsive and clean.
Super easy to use, looks fairly modern, and it’s freaking fast.
Well, we start be organizing the folks of Lemmy to understand the values of the old protocols instead of trying to chase the shiny new ones. “Ain’t broke, don’t fix it”
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.
There are advantages, but I think a lot of folks are tracing trends in this space (including trying to copy Slack/Telegram/Discord rather than be better or strip the bad parts out). Newer ≠ better.