YHK - yet another hacker news clone

Meanwhile, “Discord” wouldn’t surprise me if it were a product of the Discordians themselves, a similarly disorganized “parody religion”.

slack and discord are very good household names, same with twitter (rip) and google etc.

nobody's gonna say "hop on Zulip"

What does Zulip mean?

Can't use LLMs to contribute code

That wasn’t a thing.

Compare strafe and discord, the only differences im seeing is the strafe icon instead of the discord icon and a small difference in the embed in the chat message.

I personally agree but I think you and I are outliers in that most feedback I get is people want scroll-back history so they can see what they missed when they were offline. My preference is to treat chat as ephemeral and instead have my own forums, chan servers, sftp servers for longer term storage people can link to but it is rare I meet anyone that operates the same way. There are web front-ends to IRC for example but the moment someone ventures down that path the cost to scale up the chat server climbs exponentially due to the bloated web framework, message queues, database, etc... not that most people would really need to scale up for their small circles of friends.

Also some people do go back and reread texts from personal history for sentimental reasons. I don’t, but I know those who do

And yes, a place for pictures between friends is handy, even if in running immich.

* In the current Matrix implementation, server tells the clients what the group membership is, so a server could spoof an invite to add a malicious user to a room and you'd have to rely on social mechanisms to spot it.

* There's no way to force everyone to rotate the sender key at the same time.

* On the plus side, it decentralises relatively well.

The concrete disadvantages of MLS are:

* Vanilla MLS needs a centralised sequencing function for changing group membership.

* The key bundles are much larger.

* On the plus side, only clients within the group can add new users/devices, and everyone in a given epoch shares the same group secret, so when someone rotates everyone has to rotate to participate in the new epoch.

Now, the server-controlled membership problem can be solved with Olm/Megolm if you instead have the client control the membership, using Matrix itself to define which users are authorised to be in the room, by running the Matrix DAG merge resolution on the client as well as the server. I did this a few weeks ago (in prep for The Matrix Conference next week) to show viability; it works, and has the advantage that you don't have to blow up the whole crypto implementation.

On the other hand, MLS can also be made to decentralise. DiMLS (draft-xue-mls-decentralized) isn't the only option here; DeMLS is the one we've been working with (using the Phoenix DeMLS OpenMLS fork) on the Matrix side - and works by letting MLS epochs fork and then merge again later, using puncturable functions to avoid undermining forward secrecy. This is a much bigger change; we experimented with it a few months back; details here: https://www.youtube.com/watch?v=jc7yfec3iIQ. It's promising, it works, but is much more complex and experimental.

So, TL;DR: it's possible to use olm/megolm securely (even if it's had a mixed record); I doubt strafe is doing fancy client-controlled group membership though. Separately, MLS can be used too, but it is way more complex and has its own complications. On the Matrix side we're still pursuing both (and finally making some progress, although it's a very slow burn).

I mean, if you take that out, what's left of Matrix and its differentiating proposition?

- irc.example.org

- news.example.org

could be the same thing. IRC would poll. NEWS would not.