Revolt: Open-source alternative to Discord
revolt.chat
revolt.chat
I hope this goes somewhere!
I think that's basically precisely the same capability as you get in Discord - except in Discord you can switch between the 'voice rooms' by clicking on them in the room list, rather than 'opting in' to the one in your current room. Also, you can do toggle mute via hotkey (which we have a draft for at https://github.com/matrix-org/matrix-react-sdk/pull/2280), but this is surely a bonus feature.
So, am I right in saying that Element effectively has voice/video rooms today - it's just that the UI is very subtly different to Discord? Or am I completely misunderstanding something fundamental about Discord's voice rooms?
I don't want to call everyone in a channel, I want to see who's already hanging around and join them on a whim. It's not really "calls" per se as you don't actually call anyone and they're not coupled to actual text conversation channels.
That's the big UX difference, and it's a big deal for gaming and more casual communities with many participants.
Maybe alien to some people, but I've spend the last 17 years of my life hanging out in Xfire/Teamspeak/Vent/Mumble/Discord and I think it's one of the absolute best things that tech has been able to give us, just constantly being in a room with all your friends.
Kind of like there is no difference between (s)ftp and dropbox, and yet there is.
It's also broadcasting who -is- talking; I've very frequently made a binary choice of "do intrude" versus "don't intrude" based on who's actually talking. I know based on the social circles that if person A and B are talking, they're likely "talking shop", because person A commissions work from person B. But I also know that if it's person A and C, they're probably just gaming, and I'm welcome to join them.
This implicit social signaling is obscenely important. It's a make or break feature.
When I'm using slack, by comparison; I can see that a coworker is in "some mysterious voice call" but I have absolutely NO IDEA who they're calling, and whether I'm welcome to join. I have to openly intrude on their time, and ask that explicitly, and that's inherently rude. I'm able to do that with close friends because I have a huge buffer of goodwill, but interrupting people is always inherently rude.
Discord gives you a way to get this information without being rude.
If the only way to do it is to be rude, then - here's the kicker: It introduces an outright failure state! Quite a few people will actually decided "gosh, I don't feel comfortable interrupting this person I barely know, I'm just not going to." They literally DON'T make a call they otherwise would make, and it's 100% down to UX. It's a full on, binary, "failure to provide service", and it's because of how your software psychologically runs on the people using it.
There are two computers running your software, not one. One of them is electronic, but the other one is biological. UX is about that second wetware system; some of it is calculable, consistent stuff that holds true for a statistical majority of people - just like how certain optimizations will benefit a "consistent majority" of the electronic computers running your software.
Is that significantly different from making a new channel and labeling it "voice channel"? To me it doesn't seem to be, but I haven't tried it.
>It's also broadcasting who -is- talking
That sounds like a legitimate feature request, if it's not in the issue tracker already?
On the rest of your comment: thank you for the context, it was an interesting read, but I think I got what you meant with the first three sentences... maybe edit out some of that that if you file a github issue :)
Yes it is. For matrix currently you'd need to have the discipline to always leave and join that text channel too when you join/leave a room. And another use case is having multiple rooms. Consider the scenario of four friends sitting in a channel and playing 2v2 games and they randomize team every round. With discord/mumble/teamspeak etc. this is extremely simple, you just switch channels with one (double)click.
Another one is that sometimes we have multiple sub-groups of our friend group sitting on the teamspeak server (e.g.) playing different games in different voice channels at the same time. Because you can see all the channels and who's currently actively talking in them, sometimes we just pop over to the other guys and ask if they're up for a round of game X. Sometimes they are, sometimes they're not and we just pop back into our channel.
And there's a lot more things that I personally consider absolutely mandatory, like push to talk, voice activation, individual volumes etc.
I honestly believe anyone who's doing VOIP seriously needs to look at how gaming VOIP has always done it with teamspeak/mumble etc. Discord has successfully copied this too, and imo all other VOIP is so far behind it's not even funny.
Maybe there should be another feature request to auto join voice comms when entering a channel?
There's a reason discord is winning, and i'm saying that as a matrix+mumble/ts user. They integrated modern IRC and modern (worse but free)/teamspeak nicely.
Honestly, I don't really want to file feature requests about this because if it's not as good as mumble i'm not going to use it for voice.
And making it as good as mumble is not trivial, because browser tech sucks. WebRTC is entirely inadequate imo. (I have messed around with POCs myself)
You can them independently drop in and drop out of any text chat room.
The most common way to share text channel based content is to say "hey I'm posting an image in voice chat check it out"
The important part here is making voice the first class primary communication while not prohibiting the use of any text channels because there is no coupling.
Complete independence is better than coupling imo.
Separation can be done with permissions for both a single text and voice channel.
Also as long as someone has access to the voice channel they have access to the video channel of all active live streams.
It feels very different? And the use-cases are different.
Being able to hang out in a room alone to signal that you are open to chat if someone wants to join makes for a completely different user journey from calling someone and interrupting your interlocutor.
Proper Push-To-Talk with global hotkey is one of those features that doesn't seem important but when you need it (organizing Raids in games, big meetings, etc) it makes a world of difference. That and lack of click to join voice rooms is definitely making it harder to move gaming groups over.
I use Discord and Element/Matrix exclusively, and have groups of friends that use both. They always gravitate towards Discord for voice. I think there's a couple small reasons that kind of add up
1. When there's an active call going, you can't see who's in it unless you join. It's just this ominous box with some unknown number of participants, and it creates this feeling of "should I join them? Am I interrupting? What's going on in there?". In discord, being able to see who's in a room and even who's talking goes a long way in removing that little anxiety.
2. As others have said, having the voice channels listed as their own room, showing the current participants, that you just one-click-to-join feels different. For whatever reason it feels less like you're joining a conference call and more like you're just popping in and out. I can't fully explain why, but it does.
3. The jisti widget is pretty janky. It doesn't really size correctly, the text overflows, and it general it just doesn't feel native.
I've been using, self hosting, developing for and prosthelytizing Matrix for many years now. It started out rough, has steadily gotten better, and now I think in many ways surpasses other chat services. But the voice just doesn't quite do it.
It's an absolute must have for gaming. Near useless without it. I suspect some of the other features that are 'almost there' in fact are deal breakers in some use cases.
I think you are. Think back to messengers like ICQ or MSN, they had a group chat feature. It's like comparing that to IRC.
I personally use a separate mumble (and a teamspeak) server, instead of discord.
I hope this succeeds but it’s going to be hard to take market share. I hope the signup flows and Ux are really smooth, foss software is often pretty hard to get started with for non technical people
Just a little specification around the that interface (Trait) will go a long way to making other backends possible and should make it much easier to know and manage the API contract a capable database must provide.
[0]: https://github.com/revoltchat/delta/blob/master/src/database...
As someone who has administered too many MongoDBs, those are some famous last words.
We (Discord) moved off of MongoDB for various reasons and are quite happy about that decision but managing Cassandra/Scylla clusters is not exactly a walk in the park either.
Most startups fail not because they picked a suboptimal database for their usage but because they didn't build something that was good or it didn't achieve product market fit. I wouldn't worry about your database over-much in the beginning (unless it's critical to what you're doing and in that case, worry like hell, but you will probably know if that's the case.)
Many of Discord's issues with Mongo were exacerbated that we were using TokuMX which was abandoned shortly after we started using it. A few years into Discord we found ourselves with a rapidly scaling dataset and userbase that was built on top of an abandoned and not super popular third party version of MongoDB. (Funny story: at one point towards the end we realized that all of the packages had been pulled from every mirror we could find and literally the only place we could find the package files was off of some gov.uk mirror... that was a bad day. Thankfully we had the hashes and were able to validate the packages...)
FWIW, we did honestly debate moving our core user model (which was what was left in TokuMX by the end there) into a modern version of MongoDB -- some of the things we did (reverse indexes, secondary indexes, locking, etc) are much more complicated in a database like Scylla. It was tempting to just migrate the data from one "Mongo" to another and call it a day.
We didn't for a variety reasons, not least of which is keeping things simple by reducing the number of technologies you have in production (like when we chose to embrace Rust we went back and migrated nearly all of our Go systems).
Anyway, I'm pretty happy with not running MongoDB anymore, but not because MongoDB is inherently bad. It's popular for a reason!
> Atlas requires TLS connections for all Atlas clusters. After July 2020, Atlas will enable Transport Layer Security (TLS) protocol version 1.2 by default for all new Atlas clusters regardless of the MongoDB version.
The last time I interacted with them was in 2019.
I'd suggest you and your team shouldn't rule out SQL-like databases, given a lot of very competent NoSQL databases have SQL-like syntaxes (say Cassandra or ScyllaDB, what Discord went with). And regarding hiding it behind an ORM, if you want or need cream of the crop performance not only do you need to have chosen a database that fits your needs, but you will also need to occasionally work very close to the database to avoid abstraction inversion situations.
It's a shame your devs don't like SQL. It's probably my most useful developer skill. Saves so much time elsewhere. Having said that, a messaging app that you really want to scale HUGE (like Discord or Facebook Messenger huge) is one place where the NoSQL solutions are justified.
SQL the language or defined schema and relational data?
I'm honestly curious what it means to "not like" sql - and what/why one would prefer eg mongodb.
Ed: looks like they're running quite close to the db - but doesn't look like there's much tooling?
https://github.com/revoltchat/delta/blob/master/src/database...
https://github.com/revoltchat/delta/blob/master/src/database...
Plus the likely value here is largely the client, so you can consider reusing, or at least building on top of an existing matrix server.
Staying on topic, Dendrite is written in Rust, meant to be super performant. Stoked for hybrid-P2P via Bluetooth LE for offline usage.
Edit: looks like I got confused. Conduit is written in Rust. Ssenica was right, Dendrite is written in Go. To coffee I go!
They don't have to implement all of the spec themselves. Nothing stopping them to leverage the existing base libraries and SDKs to build the functionality for the client.
> or they just wanted to.
Well, ok, but when I see such a strong manifestation of NIH syndrome it really reflects poorly on the project.
In opposition of NIH syndrome, using others work often locks you into the framework of their thinking, which can often be flawed. So to make improvements within the framework, you must think outside of it. Matrix might not be flawed, but it is purpose built for a specific task, a task that likely won't capture all possible use cases of this project. Perhaps it would be the right move to use in the beginning, but once the project matures it may become a limitation.
However, saying that 'nobody actually wants it' is at the very least a little disingenuous. Transitioning to self-hosted and distributed systems is totally the way to go, but we're inevitably going to run into a systems problem. IRC struggled to reach the mainstream because of how fractured it was, and if you don't do anything to address that you're liable to run into the same issue again.
Not sure this is a good reason for not adding it, Element is not buggy at all.
Well, yes, it is honest, but it also is disturbing - which other well-known network principles were unknown to them?
[0] Most likely this is referencing the term and the structural pattern; as you correctly pointed out, the concept is quite widespread.
Really? I wonder how Rocket.Chat federation overcame this "inherent incompatibility"
https://docs.rocket.chat/guides/administration/administratio...
Most of their features is just PR. For example they do advertise E2E while it has the same amount of warnings and not even a doc page https://docs.rocket.chat/guides/administration/administratio...
Matrix is the practical solution, and Arathorn's sibling comment gracefully addressed my real criticism. Federation is absolutely possible on these applications, although tricky.
> Matrix is incredibly buggy at times and it’s left a sour taste in my mouth.
Speaking as project lead for Matrix... I can see where this is coming from. Were we doing Matrix from scratch again, we'd have a smaller scope and polish each feature more before releasing and moving onto the next thing. However, we're very aware of this, and these days do almost nothing else other than polishing the current codebase - for instance, Synapse's RAM usage has dropped enormously (https://twitter.com/matrixdotorg/status/1434912387933560837) - all the main serverside bottlenecks have been removed; we're working on speeding up joins enormously; Element's performance is improving massively; we're working a complete rethink of the client-server sync protocol to ensure that only the bare minimum data is ever synced to clients by default. The only new feature work we have on the horizon is exiting Spaces (groups of rooms) from beta, and adding Threading. Otherwise, it's "just" a matter of fixing remaining E2EE bugs; reworking E2EE onboarding UX, and lots and lots of polish.
Critically, *NONE* of these bugs are due to federation or decentralisation. Ironically, the federation bit of Matrix is one of the most robust bits these days - after we spent ages polishing it in 2018-2019 to fix bugs in the merge resolution code. So I think the...
> Federation and Discord-style protocols are inherently incompatible
...assertion in the revolt FAQ is completely false, and Matrix already disproves it. Residual bugs in Matrix implementations are more thanks to the complexity of federation/decentralisation/encryption sucking a lot of energy away from the more business-as-usual things which you'd focus on if building a Revolt/Rocket/Mattermost style thing.
Anyway: Revolt looks cool, and we wish them the best, and hope that they will indeed bridge into Matrix in future, which is honestly quite a good compromise - https://matrix.org/blog/2020/12/07/gitter-now-speaks-matrix#... is the guide to follow to rapidly plug an existing chat system into Matrix, much as we did with Gitter :)
Keep polishing it and silence the haters
Seriously, for anyone else reading, this attempt to provide federated privacy of communication is the kind of thing Saint iGNUcious himself might bless (I don't know if he does but am hopeful).
I had a chat with a friend recently and he said in response to my declination to use Signal:
"(I appreciate the commitment to decentralisation, but the battle of messaging apps ended up elsewhere). You're still fighting for the emperor in the jungle but the forces in the war changed years ago :)"
Decentralisation is the very purpose of the Internet, and federation is how it will work.
We just need to help you solve all the user experience problems, and they are very soluble.
Keep up the great work!
As if the world needs yet another slack-like.
xkcd_15_competing_standards.png
Making a project just to learn is par per course. Chat… especially non federated chat isn’t really that hard to implement as a protocol. It’s the UX that’s hard to nail down, and if they can get it right it won’t matter if Matrix existed first.
Sometimes it's worthwhile to consider that the "third party rules" you don't want to abide, are there for good reason.
Furthermore, sometimes the underlying reason for those rules is something you can hack on and open up.
"Oh we won't ever support feature X because of legacy arch Y so no PRs for feature X please". Well, perhaps you can solve legacy arch Y and help everyone at a more fundamental level.
You mean another IRC-like? :)
As much as we can all agree that IRC-likes, and even IRC's predecessors are wonderful and responsible for much of the progress we have today, I think we can also fairly say not every chat application from now unto forever is an IRC-like.
I would (and I think fairly) catagorise a set of slack-likes and IRC-likes differently, with matrix occupying a grey area inbetween.
When I hear discord I generally think of voice/video chat and screen sharing, and less about text chat; this may be a side effect of all the bridges, though, as I tend to chat on IRC and all three of my primary discord channels are bridged.
I run matrix, mattermost, and rocket.chat. I like the api/whatever of mattermost but I really like the overall feel of matrix the best.
Mumble/Murmur and Teamspeak have better voice functionality than Discord, because they really are designed for voice chatting.
> But not in text (Mumble severely lacking, Teamspeak marginally better).
Concur, and this, along with all-in-one Slack-like rich URL handling leads to selections of discord.
A more OSS friendly stack of Pidgin + Daemon | IRC & Mumble/Murmur seems to have the best scaling, and the best of both worlds, at least in my opinion because it has the lowest cost, richest functionality, and can scale the highest in terms of users without being dependent on a commercial service. I say this because I have seen Mumble/Murmur with > 2000 active users which is possible due to the rich permissioning system and excellent performance.
Matrix also has nothing to do with UI or UX. The clients do. Write a new client if all you care about is UI/UX. You have a much higher chance of success.
Also, the scrollbar on roadmap page in desktop Vivaldi version doesn't seem to be doing anything.
I agree on that extent. I find Telegram on this grey area which people recommend it as an alternative to Signal or WhatsApp (these people ask for group e2e) and at the same time many communities use Telegram channels and groups as alternatives/complementary to Discord. An app as Telegram is not going to please the majority and maybe this could be the case for Revolt.
Discord gets to 25,000 active users before they move to throwing resources at the problem for a hard max of 500,000 total users able to join (but not be active at once, that number is a little fluffy) so it doesn't seem e2ee is really slamming the breaks on scaling vs how far you could normally get.
Signals approach https://signal.org/blog/private-groups/
Whatsapps approach https://scontent.whatsapp.net/v/t39.8562-34/122249142_469857...
Finally if you allow tying and verifying to real world identity and don't require forward secrecy then the encryption side of the problem is no more difficult than PGP.
I run an instance of matrix for alert bots only but Synapse is too heavy and Dendrite is focusing too much on federation and less of chat related features.
To the Revolt developers: I believe your "Verify your Revolt account" email contains a link that can only be clicked once. I've heard that gmail (and other email clients) automatically visit the links of email, so that may cause some problems.
It's one thing to make a valid complain about there not being an automated account deletion feature yet, requiring you to send an email. And even then it's not that bad since it's literally a "mailto:contact@revolt.chat?Subject=Delete my account" link. It's another thing to make a temper tantrum out of it: https://imgur.com/U2DJwm7
Please don't be the guy that's technically right but an ass about it.
I created my account from an email address that could not send emails. (Unless I manually create an alias.)
They told me "Well, did you sign up just to delete your account afterward ?, You could look at the screenshot on the homepage."
I just wanted to test the platform, I don't need a specific reason to have my account deleted.
It reminds me of theses business where you can subscribe through internet but where you need to call them over the phone to cancel the subscription.
It was simpler to create a Curl loop to get my account deleted then sending an email.
[0]: https://cancel.fm/ripcord/ [1]: https://dev.cancel.fm/tktview?name=8f8ecd4b60
0: https://support.discord.com/hc/en-us/community/posts/3600683...
Just want to +1 what you're saying and confirm that we are never trying to ban third party clients (that aren't self-bots). Honestly, it would be a waste of our time and basically do nothing good for Discord. But as you correctly point out, they do sometimes trip the ever-evolving heuristics we build that try to identify and mitigate spam on the platform.
If this happens to your account you can write in to our TNS team at https://dis.gd/request and they will usually take care of unbanning any accounts that get accidentally caught up in a spam heuristic. It sometimes takes a bit to investigate and respond to these kinds of requests but they generally come out right in the end.
It's still against the TOS -- my point is only that we don't specifically look for third party client users and we have no specific plans to do so.
> You agree not to (and not to attempt to) (i) use the Service for any use or purpose other than as expressly permitted by these Terms;(ii) copy, adapt, modify, prepare derivative works based upon, distribute, license, sell, transfer, publicly display, publicly perform, transmit, stream, broadcast, attempt to discover any source code, reverse engineer, decompile, disassemble, or otherwise exploit the Service or any portion of the Service, except as expressly permitted in these Terms;
It's a catch-all but the best restriction that prevents third-party clients is probably 'prepare derivative works based on' and 'reverse engineer' (which you would need if you want your third party client to use any regular client API calls, or if you want to support signing in with the user-facing login page/qr login).
It also wasn't made by reverse engineering any of Discord's code. Even if it were, these rules still wouldn't apply to using third party clients.
Support n° was 12080748, any chance I could get it back at some point ?
I'd be more disappointed if they didn't use Electron.
With Matrix, everyone can help share the load by setting up their own homeservers, if they want to. Plus, P2P is going to be part of the protocol at some point with embedded servers in the clients.
So what's the monetisation strategy? I wish they were more upfront about that, even if the answer was "we have no idea yet". And if the plan is not to monetise, an answer as to how a centralised server with high demand will keep up with capacity would be appreciated.
The backend is in Rust, frontend is Typescript.
So it feels like nothing more than another discord clone.
I was interested, now I've bounced.
At best, it sounds like I’d be inviting them to play some online game.
That said, not a fan of either name myself.
The ad hoc poll going forward for funsies could be: if/when you the reader do a discord clone, which language will you be bragging it’s done in, and which name will you be choosing for your project?
Biggest problem is that installing any app includes a free black hole.
Most projects don't define the node version that their project runs on either, so what ran in node 8 might not run in node 14 now.
What's wonderful to run into is non-JS dependencies: node-gyp happens to be used here and there. Sometimes the native lib will be pulled, sometimes it will be built, who knows why. And node-gyp might then depend on python2 which might not even be present on newer distros anymore.
And so on and so forth. If it doesn't come in an AppImage or docker image, there's no chance I'm getting myself into a node mess.
As you said, it's good to separate the ecosystem from the language/runtime. Things will improve over time, but everything has just been in transition for so long. I dream of the day that transpilers are no longer needed and TypeScript is baked in to all browsers. Until then it is a mess.
> node-gyp might then depend on python2
`cmake-js` is the preferred option now. And Rust native deps don't have this issue.
This is gospel at this point.
Npmming and yarning are giving me anxiety these days.
On Windows that another story since you have ETW which is incredible and works with anything. But on Linux, if your application doesn't offer observability, you have to resort to strace and adhoc EBPF that you have to write, to diagnose a missbehaving application in production.
It's great to be able to use new Java language/platform features. We're moving to Java 17 next year once the dust settles (it will be the first LTS release in 3 years and comes up this month - Sep 2021)... it will be a much easier migration as there's nothing like the big Java 9 barrier to cross.
I can't understand why anyone would start something new in Java 8, all traditional Java tooling already works really well with Java 11 and even Java 17.
Quite frankly: they just don't know better and they just don't care. I could go on for pages, but in short the people running the show are just really inexperienced and are pretending not to be. I'm going to start applying for jobs soon as its beginning to feel hopeless.
It is a signal that this will be easy to build, easy to deploy (because it is compiled into a single binary in general), memory safe, and likely to be written by a someone that cares about performance and efficiency.
I think those are all valuable hints.
That's an incorrect assumption if you haven't audited the code.
> likely to be written by a someone that cares about performance and efficiency
Ah, the stamp of approval that comes from signalling to the "right people". Reminds me of the preamble to almost every C++ Boost library -- "written with performance in mind".
Even without an audit, the odds of a Rust project being memory safe are so much higher than in comparable languages.
Furthermore, Rust makes auditing so much easier by allowing you to concentrate on unsafe blocks.
GC'd languages (Java, Go, Haskell etc) are safer than Rust by default, you just have the tradeoff of GC. Note that this isn't always a tradeoff as GCs can outperform static allocation in scenarios like large dynamic heaps.
Haskell is the safest for concurrency because of the strictly typed functional semantics.
> That's an incorrect assumption if you haven't audited the code.
Audit the code? Simply `grep unsafe`.
Nowadays I’ve come around to appreciating the opportunity to see what other gophers are doing. I usually skip over those posts but occasionally I look at the code and learn something new.
Even when I’m dealing with compiles binaries, I slightly prefer something written in a language I’m familiar with just so there’s a better chance I will be able to diagnose any bugs I encounter.
The only time when I think it’s really appropriate for a mature language is when the language itself is a feature. But that is really rare for that to be the case.
Other languages (eg Python, Haskell and Erlang) are in the mix too, but more evenly distributed and less fad-ish.
This is just part of the hype cycle of languages. I’m not saying Rust is only a fad, but we are definitely in that part of the cycle for Rust.
Lately I've been thinking, it's kind of funny how the modern development mindset is so all about code reuse what with its giant dependency graphs and reliance on cross-platform frameworks; and yet the favorite sport is still rewriting perfectly good applications in the new hotness.
> One thing that makes me appreciate it even more is the fact that it's written in rust without the authors trying to make it into a primary selling point, which is annoyingly common in these days("X written in rust").
So have you measured it or do you just mean you haven't implemented as many features? -> Usually the latter.
1. Speed is usually found by by people have worked on
existing tools in the space, and they don't often make
that much of a song and dance about it beyond that
theirs is faster.
2. Speed is found in the minds of people not in their
tools. When you get past a certain amount of native-
ness, you get optimizations by knowing more or having
a brilliant insight into the problem rather than using
a new meme-language. It might be necessary for certain
types of programming but it's not sufficient.
To your point, many of the improvements from Rust-based tools appears to come from the ability to express performant semantics safely and elegantly in the language. You could write an equivalent in C, but the Rust one comes naturally, can be expressed at a higher level with better abstractions, and often comes out with top-tier performance before even investing in microoptimizarions (as long as the Big-O performance is in check).
People rag on Electron with the same shallowness as they praise Rust. I bet you can make slow things in Rust. It's all a soup of trade-offs, resource management and hype.
But as soon as you get into consumer software with auto-update mechanisms and an expectation that end users won’t be computer professionals who know how to read a CVE and evaluate its urgency, the “written in Rust” distinction becomes a mostly irrelevant implementation detail. Or, worse, it’s an indication that the GUI will feel wrong in some way because the Rust community seems averse to writing GUIs with GTK, UI Kit and whatever the hell Microsoft recommends using for Windows these days.
I would say, it depends very much on the developer. There are probably only a handful of people, who can write a fast GUI in C/++ that is also safe, plattform independent - and a joy to use.
(I am definitely not among them)
But there are a ton of devs, knowing how to accomplish it - with the webtoolkit.
In other words, I indeed would prefer a electron app, over some hacked together GUI in a "performant" language. Security, performance - and UX wise.
The Revolt.chat SPA looks decent, if featureless, and will probably be fine as the project progresses. This has just launched its beta, after all.
Okay, enough navel gazing for me!
My private computers they are mostly Electron free as far as I can tell, and yes I even pay for Sublime Text.
I think it's perfectly reasonable for you guys to do it, and I am pretty certain that most of your userbase won't care.
Best of luck and thanks for dropping by!
If your dev team thinks in web-like terms, Electron is a more comfortable place to be. Better? I'd agree with you that it's probably not.
Not really disagreeing, but "Better" is just constrained by the real ressources at hand. You have a team, specialised in making plattform independent QT apps? Sure, that is what you do. But chances are you don't, so you just target the web as web devs are plenty around.
"Academic" metrics of what is theoretically more preferable as a plattform and should be considered "better" are usually not very helpful to actually build things.
To the extent that this is true, it acts as disincentive for people wanting to pursue non-web-dev pathways in their careers, which then further limits the availability of such developers, which then further "confirms" the "cross platform is Electron" idea.
Developing with Qt is (I am told [0]) not much harder than typical web equivalents, but it is different. The result is generally more performant, both in terms of UI and also data handling/computation.
[0] I personally work with GTK, not Qt; Qt goes much further with hand-holding developer helpers than GTK does.
Qt runs in a web browser via WebAssembly but building an application that way--I mean, if you want that to work, good luck, but it's a presumptuous ask to make of a developer. If you want to have a client somebody can log into via Chrome or Firefox? Hi, now we have two codebases that aren't sharing logic.
Qt also doesn't work well on iOS or Android. Attempts have been made. They're not viable without significant work that "Qt is cross platform" elides, and you're probably forking your entire codebase for what you can actually salvage. And when you've built a Qt application, there's a whole lot less that's reasonably sharable when you eject out of it on those platforms (because you will), as opposed to the large amounts you can effectively share between React and React Native (see also the web-hosted option above).
So, +1 to the developers of Revolt.
Discord is an obscene drain on resources. That's the problem that's easy to solve: just stop with the bad programming choices.
That said, I didn't realize at first that Revolt is in fact meant to be a REPLACEMENT top to bottom, and not just a rogue Discord client like Ripcord. You're hawking it on the basis of privacy, rather than speed (since it obviously won't be much better there). But the privacy angle is laughable from the start. Do we run our own servers? It's not clear to me from reading the site. You talk about "creating" servers, but Discord users "create" servers as well: on Discord's hardware. If Revolt genuinely allows for the creation of independant servers, with no control or access by the Revolt devs, that is at least something. If not, I don't see the point.
The backend and the clients are both open source, so I think the idea is that people do run their own servers. There's certainly nothing stopping you. I assume the hosted server is just for convenience and/or demo purposes.
You have to be where the people are to make it worth anyone's time to complain about performance.
telling the author what their priorities need to be... nice.
Hate on HN does not predict any kind of product metric.
Thank you for writing for all.
on my 4gb, 6 year old daily driver i dont find electron apps to be difficult. personally i dont think it's that worthwhile to try to appease the vast ranks of anti-electron anti-web zealots (i doubt any of them would ever be satisfied no matter how many gains were made). but it would be interesting to hear of folks adopting more advanced techniques to keep resource consumption down.
https://foundation.rust-lang.org/members/ just look at the companies that are a part of the foundation.
Headlines like the one on this submission makes me think "finally, someone has started to write that thing in a sensible language".
I'd rather use a click listener with TS/Kotlin/Swift than be forced into idiomatic Rust's architectural workarounds.
This project made the right call, using TS for the client.
I don't insist on everything being Rust. But it gets very close in many areas IMO.
A lot of the HN folks wage meaningless language wars that are a distraction from the actual success elements of Rust: namely that it removes a class of bugs by the mere virtue of your program compiling. Add to that a stellar quality and very dedicated community, sprinkle amazing tooling on top (semgrep filters, tree-sitter support, code-generation libraries) and it is a clear winner. Hence, "the writing on the wall" comment.
From HN and several other forums, plus a few companies I worked in, plus some meetups, I got the impression that the chief factor of slowing down Rust's adoption are a lot of C/C++ graybeards on influential positions that have an axe to grind against it and never bother to give actual technical arguments in a discussion. Unproductive and somewhat juvenile but hey, people being people.
That, plus the mind-boggling amount of C/C++ code that has to be rewritten should the world accept Rust as their successor is, shall we say, a very valid reason for its adoption to not be super fast. (And a fairly valid reason at that.) This problem sadly still exists. But with the Linux kernel starting to pay (some) attention to security problems, I have hope that such efforts will begin sooner rather than later.
It was a while ago, but I haven't asked around lately.
So a more apt comparison would be that you can use it on, say, 5 to 8 levels, and you could be absolutely fine on each of them.
It does require a bigger upfront investment for sure but it's not as big as many claim.
But obviously, some startups choose because its cool, this ones you shall avoid.
Better than "written in C++" and it kind of implies the code base may be fresh than inheriting some old implementations from a decade ago.
At least for me, the story quite simply ends there. No, it's not the GUI toolkit I wish I had, but, if the goal is to develop for the 21st century, then I think that being accessible is the ethical choice. And, given the current tech landscape, that goal is satisfied by three options: Electron, developing three different native desktop GUIs, or deciding not to support less popular platforms.
the backend is written in Rust
if you use Discord, you don't care about the backend, it doesn't run on your machine
This is something i notice about rust users, they promote "written in Rust" more than the products
Very bad marketing
Solutions should solve a problem. Tech demos should demonstrate tech.
This application solves a problem. An application is more than its front end...
Right, but for a self hosted project this might of interest.
If you use Discord you probably don't care about self hosting, which a Revolt user might.
It could turn some people off who would otherwise be interested.
Unless of course you're only interested in targeting a more narrow group to begin with. That's ok to, it just potentially limits the reach of the user pool.
For an app whos success will be governed by 'network effects', it helps to cast that net as wide as possible instead of narrowing it.
They're marketing to a privacy aware audience which is, unfortunately these days, political to some.
But on the specific issue, consider if someone is a proponent for privacy, but isn't sure if the're joining software created by activists they disagree with, maybe the equivalent of the folks behind Gab, for example.
Gab is a hilarious example because it is a non-federating fork of Mastodon.[0][1] This is especially noteworthy because the ActivityPub "Fediverse" is full of antipathy between camps of users who run Mastodon (more Left) and those who instead run Pleroma (more Right) to the point where you can predict a user's politics by the software their homeserver is running. Is this the future of FOSS that we want?
If you support the right of individuals to run social networks, and if you believe in libre software, you have to understand that sometimes people will use the tools you release for free to do things you disagree with.
An analogy: if you're a manufacturer of hammers, you have to accept that someone could use your hammer to commit a murder.
[0] https://joinmastodon.org/ [1] https://blog.joinmastodon.org/2019/07/statement-on-gabs-fork...
That said I don't find "revolt" all that bad. Out of context it's only political if you let it, just like "master" branches aren't a statement about slavery by themselves.