Strafe: A new open-source, E2E Encrypted, and federated alternative to Discord
strafe.chat
strafe.chat
I was there when teamspeak was forced out by the demands of the group. There was no fighting it. My individual ideological preferences cannot defeat those of a collective. These people just want to play games. They don't want to take up arms in my weird nerd battle against COTS software, closed platforms or buggy applications.
A feature comparison between Discord and all these other clones is always laughable, which is exactly the reason why convincing everyone to move is an impossible challenge. I was checking out Fluxer this weekend and it's the first one to inspire hope in me that maybe that won't always be the case. But Matrix, Stoat, etc. are all simply sub-par user experiences.
As bob1029 said, making apps is easy especially now but getting friend groups to move is the real challenge so I think a column in the table should include a score for how easy it is to import Discord server history, chat history, invite friends and so on. I think there would have to be next to no friction or risks. If self hosted then backups would have to be encrypted and automated so that the servers can be treated as mostly ephemeral. Operating and maintaining Discord takes a rather large team so these open source alternatives would have to be able to show they have automated most tasks in a secure and fault tolerant manor that is hard to get wrong.
Are we reliving particularly nice interactions with loved ones?
Photos and home videos I totally get. But even going back a day in a conversation history can be a significant chore if I didn't 'save the link' or remember a date or whatever. I couldn't imagine ever trawling through all that text unless by necessity.
The argument changes slightly if someone wants to recreate a friend by throwing conversation into the model or context or whatever, but I find that creepy and it's a relatively new thing.
Maybe I'm just sentimental via pictures. I love conversing in text, but I'm just not sentimental for it in any way. Other people are allowed to be, but I don't understand it.
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.
Can't think of a worse chore. I'd rather do laundry, it's at least productive. Life can go on without our presence occasionally. That's "normal". It's not possible, nor healthy to try, to be everywhere all at once. I think I may have had notions in that direction when I was younger, but living life won instead. And for that I'm thankful.
Having ranted all that, here I am conversing on HN at 1am :\
When we catch up in person the awesome stuff generally gets relived, which is good enough for me.
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.
If you're literally just doing a front end to Matrix, I get why you have to use the current Matrix protocol. But if you're doing something that isn't Matrix, you should avoid Olm.
The thing with MLS is that it basically requires a central server for ordering the commits. For Matrix' interpretation of federation, this doesn't really work because a group isn't really owned by a server, it is a DAG of events, which, as is the nature of DAGs, does not have the total order needed for MLS commit ordering.
So either you introduce a central party that does ordering, or you do BFT-style consensus, or you try to get some idea of branching an merging of group states into MLS, which isn't really possible with what RFC 9420 offers.
My impression also is that the Matrix community really loves their DAGs and the group state management that they built, and from an MLS perspective it makes more sense to store that in the group context (either as extensions or as components as defined in draft-ietf-mls-extensions-10).
There is draft-xue-mls-decentralized which proposes two ways to MLS offer some foundations, one of which (IMO) only solves half the problem and the other (IMO) doesn't make sense.
The fediverse folks are also trying to solve this and it just is hard. https://github.com/swicg/activitypub-e2ee/issues/56
Edit: (I work on OpenMLS)
* 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?
Can't use LLMs to contribute code
Read: write your PR. It doesn't say "do not contribute code touched by LLM".
It asks to take accountability for the thing you submit.
Technical output written by LLM is often very hard to read due to the ticks, fillers, fluff and idiosyncrasies. Even with rules or guidance.
This contribution rule ensures crap will be edited out and only the valuable content submitted. Cleaned up LLM code can be very valuable.
Developer gets it.
On the other hand Strafe does not have it at all, so it is not really a competition.
There’s a GitHub but it was all the way at the bottom of the page behind a tiny icon in a group of other socials. At least on mobile it was.
Nitpick: the bottom row on the front page shows a discord link, but not their own strafe link. I hope they can add this because of dogfooding.
I can’t find any such free thing that has a native iOS app.
Buzz was one I looked at but it was way too complicated with Nostr and a bunch of things that are way too much for what I intend to use it for… :-(
This - Strafe, Chatto, Stoat all fall apart in the native iOS app requirement..
Each sidebar "server" entry should be an ACTUAL SERVER, with a unique username and connection. Like Mumble, Ventrilo, and Teamspeak. Federation is a strictly worse model than what they got right two decades ago.
Imagine having to create a gmail account to write with gmail users and a sim card for every telcom provider, because you only can call someone within one provider.
This is just a path which ends up at the global monopoly or oligopoly which we have now with Discord and whatsapp
I think they are working on federated identity between different servers, but multiple servers with individual auth is available today.
It's way too early for this to be in HN.
- You can change the back end and store everything in an sqlite3 database.
- Spam is what killed usenet as a discussion medium. Topic-specific, moderated google groups are still active and see traffic.
- People keep reinventing the same things over and over again.
- irc.example.org
- news.example.org
could be the same thing. IRC would poll. NEWS would not.
Also all links under the resources heading are broken.
is the completely german-less train-of-thought I could imagine leading to this name
"Slack" associates pretty strongly with "slack off" (get no work done) too, so that one's also strange.
I think "Zulip" has the best naming of all these.
Meanwhile, “Discord” wouldn’t surprise me if it were a product of the Discordians themselves, a similarly disorganized “parody religion”.
I always preferred Discordianism over CofSG, but both were cool.
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?
Also “strafe on your desktop”. Plus this is obviously entirely vibecoded.
Incase anyone is wondering, there is a screenshot here: https://github.com/StrafeChat
The fact that Apple back in the early iOS days thought it invented desktop icons is still absolutely ridiculous.
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.