Revolt: FOSS Discord Alternative
revolt.chat
revolt.chat
Also, the backend is written in _Rust_, I thought you guys LIKED THIS KIND OF THING!
This project is really good. Really really good!
A small team would inspire more confidence in the longevity of the project.
- a lot of knowledge can be lost how the system works and has to be reverse engineered - which fork is the chosen one by the community and how will people know about it - branding might be unclear, can you reuse the name or should you rename your project
You seem to consider this important, maybe you could volunteer?
As someone who doesn't use voice channels, I can't even count how many times I've accidentally joined them because I mis-clicked. And then I have to find the "end call" button because, of course, it's small and located away from the channel itself. It is so unbelievably annoying.
The best feature Discord added recently was the ability to hide channels, so I can finally, once and for all, forget about voice channels.
GP is right, frictionless voice channels is a killer feature. Maybe a toggleable prompt or some other feature to prevent accidentally joining can be an opt-in.
I've also been on Discord since 2017, and I've done it many times. Especially on servers which put voice channels right next to text channels. And I'm not the only one either, judging by another comment[0].
[0]: https://news.ycombinator.com/item?id=36439417
> The app even prompts you if you're sure about joining under some circumstances.
The app is even worse! It brings a full-screen pop-up and if you haven't granted Discord microphone permissions, it will bug you, every, single, time.
Anyway, I think opt-in for some kind of friction makes sense.
Nowadays each audio channel has an associated text channel, making it a lot easier.
Keep your mic muted if this is a concern.
Discord makes it clear when you're in a call.
I simply do not believe in adding friction because of bad users.
If everybody were “considerate” then a simple toggle wouldn’t cause any issues.
Revolt has your mic muted by default.
It's a good reminder indeed, I hadn't considered the old gaming toolkit we used as teenagers and I work with 100% technical people that can figure out an apt install mumble
The sticking point for me is the lack of persistent messages, something the devs strangely think is a privacy plus. Issue open since 2016: https://github.com/mumble-voip/mumble/issues/2560
If you drop out for a minute you won't have access to anything that was posted in chat, which makes it useless for anything other than voice only comms, that might suit some business purposes but I've always needed to post links or screenshots in chat during meetings.
This sort of is yet another data point related to a conundrum: on one hand, applications that integrate multiple functionalities are convenient but there's always one or more functionality that doesn't fit your needs; on the other hand, applications that focus on one functionality do it well, but you have to hand pick one-by-one to fit all your needs, perhaps add some glue scripts/plugins to make them work nicely together, and this is inconvenient (in particular if you are not alone and not in an organization that "dictates" those choices) and a slow process.
Basically it is Office365/LibreOffice/Emacs or Browsers (with plugins to add chat, email clients, etc.), issue trackers (sometimes feature Wikis and more), Git online front ends (sometimes offer Wikis and issue trackers), versus e.g. raw Git, Vim/Notepad/Nano, bare-bones browsers (Surf, Midori browsers), ...
I favor the dedicate apps for things I do a lot - usually I eventually know them pretty well and I have the know-how to make them interoperate. For more casual stuff, I'm like the random user - the convenience just wins.
But for communication applications, as long as people jump the bandwagon of the latest private service provided "for free", you have to go with the flow or only be the nerd that talks with nerds on obscure networks.
This is my complaint about Discord and such as well, though. People seem to love platforms where what you typed last week is never looked at again and isn't searchable/accessible from a regular web search. HN is also moving more and more in that direction: threads always dropped off very fast (matter of up to 3 days if you have a top-of-the-year popular thread) but then, at some point, editing was restricted to only be 2 hours (countless times I run into not being able to add a correction or addition, so posts are now less good/useful in posterity), and last week I noticed I couldn't reply to someone anymore after 18 days (they had replied to me, I had finally gotten around to checking their suggestion, and wanted to reply back ... alas).
I am on my way to bed but, damn, you're getting me curious about the delay that Mumble has versus speed of sound. Knowing it uses Speex ("This is an example of Speex ..." x100) which has a minimum delay of 30ms (https://en.wikipedia.org/wiki/Speex), and that you have <1ms ping on gigabit LAN so ignoring that by comparison (even if you>mumble>someoneelse is 2 hops), sound travels...
$ qalc
> 340m/s * 30ms
(340 * (meter / second)) * (30 * millisecond) = 10.54 m
If you say it was ~11+ meters (36 ft), I may be curious enough to create a test setup :p. But I'm assuming you mean the person sitting next to you, not someone who put Mumble on huge speakers across a hall.
It was also in 2009 so it could even have been Celt rather than speed or opus
I played Eve Online and had to use Mumble. Damn, I wish more people used Mumble, it's such a nice piece of software and it's open source! If only we could have text chat mixed with the audio backend from Mumble, all this together in one app, I believe it would be amazing.
(The only difference between before covid and after is that we are more people and have more calls that take longer. Text chatting is a lot more structured and efficient and inclusive because nobody has to wait for a turn while the topic evolves past five persons before it gets to you, but whenever a topic gets more than a handful of messages, invariably $boss will propose to stop wasting time and "plan a meeting" .... but I also have that experience with IRL meetings when there are more than, say, five people involved)
You could probably make that work in VC but the UX is going to be awkward and un-intuitive no matter how you slice it.
So the best option (online/available status and 1:1 calls which is what we have now) is probably the best alternative.
It's still exactly one conversation you can be part of at a time. This compares to in person conversation where you can be part of a greater conversation while also carrying on a smaller, secondary conversation with the people immediately adjacent to you.
I've seen some conference software try to address this with a "tables" system where you sit at a table of a few people but are in a greater discussion room. Your table conversation is only heard at the table but the room conversation is heard at all the tables. then the table channel is "open mic" and the room "push to talk" (or both being bound to different "push to talk" buttons).
That kind of addresses the issue but it's awkward and doesn't translate well to anything other than conferences. Maybe a 2d/3d game style environment with range chat would work the best for something like this but I've yet to see an interface for this that isn't miserable outside of actual games. It'd solve the "walk up and talk" issue but it'd add 10 other issues all of it's own.
Its very different.
Lets log into Discord. We see Alice, Bob, and Charlie are in Room A. Domingo and Ed are in Room B. Francine, Greg, and Hoarice are in Room C. To swap between these three conversations, we just double click on one room or the next. We're instantly swapped between these calls.
Lets say your group of friends has three different calls going on in Skype. How do you quickly see who is talking to who? How do you quickly hop from one conversation to the other? Like in Teams, if a few people are in a call together, how do I know? Sure, I can see Alice and Bob are in a call, but how do I know they're in the same call? How do I know that Charlie is also in there? How do I join their call in progress if not a scheduled meeting? If I'm in the call wtih Alice, Bob, and Charlie, how do I know that Domingo and Ed are talking about the topic of Room B?
The ergonomics of the "call/meeting" versus "room/channel" is vastly different. They both very much have their place, but they're not interchangeable. Forks are good for eating, but it turns out spoons are useful too.
IRL you might just grab an empty office or room and hit the whiteboard for ten minutes.
In other tools you need to invite specific people to a chat, and they have to find and respond to that specific event.
In discord you say “let’s meet in the engineering channel” and anyone who also wants to join can do so.
It’s a seemingly simple difference but I found discord so great for remote work relative to slack. It’s just much more casual, like real life.
But I use slack for work and some org's community space is also on slack so I make the best of it that I can.
By making their backend AGPL they've left themselves a path to some kind of profitability for companies that want to run custom versions.
They're running Docusaurus for docs but adding manual timestamps instead of using the built-in showLastUpdateTime variable... this hurts me.
(Not a leading question. I haven't used Discord/Matrix/etc. more than a handful of times and don't know what I don't know.)
Or maybe Matrix has some issue I don't know about, which is a more interesting question. Element seems to have both video and audio chat, but leaves a lot to be desired on the UI side sometimes. I can definitely imagine the more the merrier when it comes to open source UIs for open protocols.
Another thing that can trip people up or make Element hard to use in a company is that the Element clients have certain defaults. For example, the video calls by default use a pre-defined Jitsi instance. Other aspects also use external service by default, even if connected to a self-hosted server. That is pretty much a nightmare if there are compliance/privacy concerns and a company wants to host everything in house.
What's really pleasant is how verbose and easy to understand the matrix protocol is. It's quite easy to create bots, send messages over the API etc. So it can be easily integrated into other business processes.
There's the Spaces [0] API but it's not really meant for creating "servers" (servers as Discord labels it, meaning a top-level room or thing that contains children voice or text rooms) and as such there's no easy way to have any type of per-"server" RBAC or other permissions that Discord's model provides because of the Room + Power Level paradigm Matrix follows.
There's also difficulty with enforcing recursive operations, e.g. in Discord you can just kick/ban somebody and they are removed from the top-level (Server) and all child channels- but there is not really a way to perform any such operations with Matrix without a lot of hacking around and writing custom app services.
[0] https://spec.matrix.org/latest/client-server-api/#spaces
A) you need to create an account for the bot and provide an access token (which is cumbersome to obtain). In Discord that type of moderation of users works ootb.
B) There is no mechanism for role-based permissions. In Discord, you can create a role and assign specific permissions to that role which can control different rooms, etc. in your server. That is not possible in Matrix currently even with Mjolnir or custom app services because of how power level mappings work.
It's a problem I'm interested in solving but it would require MSCs drafted to alter the Matrix spec to create a new permissions model and will have extremely far reaching implications for homeserver implementations.
[0] https://user-images.githubusercontent.com/48614497/159062202...
Both are very important for replicating Discord's low friction. Opening a full window when it's just a voice channel anyway is also distracting and increases friction.
It looks like it's a b2b app anyway
Element is hardly b2b lol.
---
[0]: https://matrix.org/
A good starting point if you're tech literate is this:
https://blog.gitea.io/2022/10/a-message-from-lunny-on-gitea-...
Their founder claims to have invented Gogs (he was one of the early committers) when the original author is another engineer
https://en.m.wikipedia.org/wiki/Gitea
> Gitea was created by Lunny Xiao, who was also a founder of the self-hosted Git service Gogs.
https://about.sourcegraph.com/blog/three-years-at-sourcegrap...
> About the author Joe Chen is Software Engineer and maintainer of the open source project Gogs, a painless self-hosted Git service. You can chat with Joe on Twitter @jc_unknwon or our community Discord
I'm unsure about the wording on Wikipedia, but I don't recall Lunny ever trying to take all the credit, just that he was an early and frequent committer.
It's become dangerous for open source to rely on anyone who can cut off your air supply. Look at the current flap over Red Hat.
My team does CI in gitlab, and many big organizations use self-hosted instances GitLab like KDE and GNOME.
Not sure if it’s 100% compatible yet, but that’s their goal.
"Run this script in this container and cache these outputs."
e.g. for a repo at mholm/myrepo
git clone https://github.com/mholm/myrepo.wiki- Github actions putting Microsoft "telemetry" into projects being built.[1]
- "Please log in with your Microsoft account."
- "But first, this word from our sponsor".
[1] https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_a...
The trust we hand these silos in exchange for convenience is just ludicrous.
Also: How do voice channels work in this thing? I've been thinking for approximately forever about making Jitsi meet more flexible to support channels, but never got around to it (I've done some basic ground work on it, in case anyone wants to pick it up).
"All progress depends on the unreasonable man."
Zulip was created with a focus on keeping history as usefully as possible - mattermost as another open chat platform.
Except for timing - mattermost and zulip might both have been built on matrix (the servers and clients weren't there yet when theses projects were started).
That might be the case for Revolt too.
Personally I'd love to see more innovation on top of matrix.
And by "strokes" I mean use-cases, design preferences, integration needs, etc.
Personally I'd use RevoltChat if they offered SSO/SAML/OpenID support - I like the UX and the Discord-esque vibe as opposed to the Slack-esque vibe the alternatives you listed carry.
With corporation you need to have some competition if you want to keep their power in check, but their shareholders understand that it only weaken them (that's why M&A are so ubiquitous).
But for open-source, it's pure deadweight loss.
Vim isn't made weaker by emacs, or vice versa, quite the opposite. Neither can rest on their laurels. That's very good.
This is a very common worldview nowadays, in fact it's probably the core tenet of the contemporary credo[1], but that's also an extremely narrow view of human psychogy: humans routinely seek to achieve the best they can do without any kind of competition.
Worse, with competition people tend to optimize for the specific metric the competition is about, and everything end up looking the same (from movies to retail product, that's the ”ice cream vendor paradox”), if you want to explore the entire problem espace you need to remove competition and let people set their own goals. Competition is also only a stimulation when you're in a good position to win, otherwise the desperation faced when you only have very little chances of winning is very likely to destroy your motivation (the school system is extremely prone to this phenomenon, and so is competitive cycling).
In fact, since there's almost never a reward, the vast majority of open-source products exist solely because their creator wanted it to exist, and they are maintained because their creator just want their creation to be perfect.
Oh, and by the way, biological evolution isn't about competition either, that was just Victorian England elite projecting their worldviews on a biological phenomenon: species don't want to win anything[2], some “packs of genes” just happen to be more suited to persist over time than others.
[1] even above the “myth of Progress”, which is currently being challenged by the "myth of the golden age"/ “myth of Decadence”
[2] “species” don't even exist in the real world, it's just a simplifying (and useful) model of the world (if you're interested in learning more about that, look for “Beefalo” and “pan-genome”.
A short (incomplete) list of my git history from the past 1 year: - May 15 2023 Remove activities ("Discord Birthday" ;)) - May 1 2023 Remove nitro super reaction - Apr 9 2023 Remove nitro ads - Dec 22 2022 Remove new features popup - Dec 22 2022 Remove snows giving seasonal event - Sep 5 2022 Remove floating unread indicator - Aug 31 2022 Remove new member badge
I personally won't donate free work to organizations that want the option of releasing nonfree software.
- No standard authentication system, you have to go private message someone called NickServ.
- No chat history built in unless you run a bouncer.
- A lot of weird legacy features with multiple ways to negotiate them (CAP, PROTOCTL, ISUPPORT, just assuming you can use something, etc.)
- Inscrutable and incompatible user and channel modes across different IRCds.
- No voice chat unless some client is implementing it via some kind of DCC command, and even then no multi-user voice chat and requires direct IP connection.
- Horizontally scaling IRC is… interesting.
If I were to even think about using IRC as a base, I would overhaul a significant amount of the protocol and break compatibility with a lot of existing applications! None of these are insurmountable problems but to fix then you would be inventing a lot of bespoke parts of the protocol!
You can (ab)use IRC as a generic datastore, the same way you can Twitter, SMS, or anything else that allows for data to be stored, but it's a terrible idea, and you'll end up with something overly complicated and without any sort of compatibility with generic IRC clients.
And honestly, complaining about Electron apps is just lazy. It may not be the choice you make when you have unlimited resources and time to write separate native applications for every platform, but it's perfectly accessible for a first iteration. Also a great way to make sure all your platforms can have roughly the same behavior. Would much rather have an Electron Linux app (which is easy to port and costs little to maintain) than no client at all.
How far stuff moves forward in short time.
1/40th of an average human life isn't really that short. That's 400-700 calendar work days depending on your work ethitcs, possibly thousands of man days.
That's an eternity gone in the blink of an eye, not a short time.
Life is what is short. :(
it’s up to you.
- The technology was attempted and failed 50 years ago, like so many other things.
- 12 years ago, video calls (1-to-1) became available to everyone
- 4 years ago, for inexplicable reasons, demand spiked for videoconferencing. MS Teams gained an annoying foothold.
- Around the same time, Jitsi Meet usage goes up as an easily accessible open source solution.
- 2 years ago (looks like only 1 when checking), Matrix replaces integration with a native feature, for standalone feature parity with the rest of the space.
Not that exciting a timeline...
Imagine if everyone goes to heaven after they die but the first thing they must do in the afterlife is to watch a perfect recording of their entire life before they enter heaven. How many of those viewers are going to complain that life is too short?
Open source is friggin great. Some open source game addon manager I was using made a bunch of moves that pissed me off, but it was a breeze to fork it and just maintain my own version with a couple of patches applied
Or a plain and simple C client?
You mean native binary? Why? It is too slow?
That said, for something discord like, the best small clients for interop would be an IRC bridges augmented with special and specific commands. There are many implementations of IRC clients and, what is very important, it is easy and reasonable to code an alternative (on top of a crypto lib ofc).
It's closed source?
Which should be default for anything that offers dms.
I wanted it for Discord so I created an E2EE client on top of it: https://www.discryptor.io
So there's definitely a trend.
I guess the idea is that your name stands out precisely for this reason, so people remember it. But yeah once it becomes a trend, hard to keep track & the trend changes.
Revolt and Riot at least require a huge amount of communication to kick off, and Discord requires some large amount of people. Any one person can slack off on their own.
> Hold on, this article is quite old at this point, just a few things to keep in mind:
> - Federation may end up being part of the project in some capacity in the future, just at the moment it is not part of any feature (at least publicly) on the roadmap.
> - The complexity and time arguments below are still valid but may be necessary to tackle in the future.
> If you have some general ideas on where and how federation could be implemented, feel free to drop into the Lounge #Revolt Development.
Anyway, this gets into a philosophical point about the whole Reddit exodus - ID federation and content federation are two different things, and when people talk about the friction of joining a forum vs clicking subscribe on reddit, ID federation is what gives you that, not content federation.
And content federation introduces a lot of scalability problems, and difficulties deleting comments/etc. Yes, someone can notionally always crawl/cache you, but having it on your server is different from intentionally putting it out into a peer-to-peer CDN, or serving it to a bunch of different pods so they can put it in their members' feeds. Some people don't want that part, they want the content to stay on their self-hosted instance.
Identity federation also runs into the problem that oauth, etc don't let you have the same account on multiple oauth providers as a backup in case one of them shuts down.
If Revolt supported federation it would be trivial to just turn that feature off if you had privacy concerns in that regards.
This is for folks that want a self-governed / "no big brother" Discord alternative, it's quite nice for that purpose, but it's lacking the Discord integrations (audio chat, etc.) that make it better for gamers.
This should be a Matrix implementation with some implementation specific extensions that will be included in the standard in the future.