Finally, something that outright says that its intent is to be a discord alternative. So many platforms try to sell themselves on some other feature, rather than just being open source and self-hostable. So many things, like Matrix, come close, but lack key components to really competing, such as voice channels rather than calls.
The whole "matrix doesn't have voice channels" thing is a bit frustrating, because... in Element, you can hit the voice or video call button in any channel (not just voice channels!) and it will spin up a voice/video conference in that channel. If you then switch channel, you'll stay in the original conference, unless you drop and rejoin the new one.
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 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.
Those all seem like things that could be fixed at a lower cost than creating a whole new app, but maybe there is some technical reason I'm not familiar with
I think the problem is that Matrix has a different scope than being a Discord alternative. It's a protocol and designed to do more complex things like creating federated networks or bridging IRC networks, etc.
The difference is that Discord voice chats work like "meeting 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.
Thanks all for the responses - the whole “matrix doesn’t have voice channels” thing is much clearer now: it’s not the hard bit (voice/video conferencing!) but just the UX of how it’s hooked up. This we can fix :)
"it's not the hard bit but just the UX" – I think this is not a good statement. Maybe I'm reading too much into it, but it shows a certain state of mind: Tech/protocol/crypto/algorithms are hard, but UX is just decor and easy. That's just wrong. For many users, UX is way more important than Key Backups and Cross signing of devices. If FOSS projects want to be an alternative to Slack/Discord, then these things are precisely what matters – a lot.
Well, tech/protocol/crypto/algorithms require changes to all servers involved. UX is something that can be deployed and iterated upon much more easily. That makes it the "easy bit", for some definition of easy.
Good to know you guys are listening, but I'll dispute that UX isn't hard! I think Matrix/Element is great but open source projects at large are let down by UX/UI issues more than anything.
That's great to hear that you are open to addressing this UX feature.
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.
I haven't used Discord or Matrix in a while so please forgive me if I have this wrong, but just reading this comment and the parent comment, the only difference there seems to be that the Matrix voice room can (optionally) be coupled to a text chat room, whereas Discord cannot do this, and the voice chat rooms there are always separate. That actually seems like Discord is doing worse here, if you were aiming for maximum flexibility. (Maybe you aren't, I don't know)
The UX of just being able to naturally sit idling in a voice chat and have friends drop in at will is the point of discord and it's done very well. This user interaction being a first-class citizen is a big deal.
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.
I don't understand, is there some reason you cannot idle in a Matrix room? Again I don't know, but for the sake of discussion it would be good to mention that.
Not GP, but Discord user too. UX matters. People are very sensitive to the context of features, what the subtle meaning of using them is, how we initiate the communication and how it all "feels" like, for lack of a better word.
Kind of like there is no difference between (s)ftp and dropbox, and yet there is.
Ok but just for me as an observer, it's not clear what the actual UX difference here is. The discussion seems to suggest that the actual capability of the UX is in fact worse in Discord, and maybe not worth copying exactly if it causes a feature regression. It would help to specify exactly what you would like changed around, i.e. if there is a button that could change to make it more clear what is happening when you join a voice room, or something like that. It could turn out that this could just be a matter of some small cosmetic changes.
The difference is that the discord UI conveys information that is strictly missing in other UIs. By having a separate voice channel, it's implicitly broadcasting "these people want to talk".
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.
> By having a separate voice channel, it's implicitly broadcasting "these people want to talk".
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 :)
> 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.
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.
The text channels in mumble/teamspeak are pretty much irrelevant because matrix already has good text channels, the IRC part. The text channels there are just to post the odd link or something in mumble/ts.
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)
I'm sorry, I don't understand why you are saying this? This would not be about me copying something or you using something, this would be if you had a feature request to Matrix or to Discord.
I very much want to use matrix over discord so I went and did a cursory check of all the desktop clients listed on the matrix website (again). It's unclear to me that any of the implement voice rooms at all? Am I missing something?
I am not using any Matrix clients right now but I was referring to this GP comment by the Element CEO: "in Element, you can hit the voice or video call button in any channel (not just voice channels!) and it will spin up a voice/video conference in that channel"
In discord you see a room of people in voice chat which features drop in drop out.
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.
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.
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.
The real reason so many people use discord is the network effects. My friends and I joined discord really late in the game but for various reasons we eventually needed it. Eg, game development discussion groups and eventual marketing, or your weekly dnd group uses it, school, etc
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 wanted to point out that Matrix is getting native voice/video calls (for multi people, it already works with 1:1 calls) soon, as well as voice rooms (they've already been designed and the design shown off, just not implemented yet).
The subject line of this hacker news story says that's the intent. I just found 0 occurrences of the string 'discord' on the linked homepage and also its main github repo page. Is the project actually claiming that's its intent?
Also working on a Discord alternative, albeit my project is a decentralized version — neat to see the space has traction. One thing I couldn’t quickly surmise: it looks like your services are centralized and neither servers/spaces (whatever terminology you’re using for logical groupings of communities) nor DMs have support for encryption. Do you have plans to support this? I don’t mean to ask this as a FUD spreader, I just am curious how you differentiate from Discord aside from being open source, and similarly, how you intend to ensure your offering stays open source in perpetuity?
Correct — I suspended development on the repository a few weeks ago to switch from launching centralized and federated initially to going fully decentralized at the start of the public beta. I’m taking the time to work on an extension to double ratchet to extend to group conversations but avoid a painful group ECDH key rotation scheme or take on integrity compromises like with megolm.
Curious why you decided to use MongoDB as opposed to HBase or Cassandra? Discord moved away from MongoDB because its sharding is “complicated to use and not known for stability.” Are these issues not relevant anymore?
HBase is asking for operational pain. Brownouts of region servers, Hadoop dependencies and a million knobs to tune. Add kerberos and that's the road to hell.
Hi, one of the developers here, there was no specific reason why we went mongo at the start, but there have been talks to move to a different database if needed. Currently mongodb is fine for us.
Just want to suggest that if you're interested in doing this in the future, some investment in defining interfaces up front is worth doing. I took a quick look at the codebase and it looks like mongo is "in there pretty good"[0] without any abstraction to make it easily shimmable.
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.
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.
I didn't make the original decision but if I were starting something and I had no idea whether or not it'd be successful, I'd do whatever was the absolute fastest way to get to MVP. That'd probably be a cloud database, honestly -- but a modern MongoDB would be technically fine too (licensing stuff notwithstanding.)
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!
Really appreciate this great, detailed answer! 100% agree with getting to an MVP with PMF as quickly as possible should be the top priority for a startup.
It is not "just fine". They do not have encryption on the wire by default and require an enterprise plan, which is percentage of income based, to enable it.
As I said, if one can afford it. Also not sure what you mean by wire encryption is on for enterprise plan and income based. Their plans are size based.
I worked with them and had meetings with them in person. SSO and TLS were Enterprise-only features, and enterprise pricing was percentage based. It was insanely expensive.
Interesting. Probably it's different now. We use both SSO and TLS and TLS is on by default now. May be they changed their plans since you spoke with them.
Thanks, seems like they indeed changed it (good on them! this always bugged me.)
> 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.
I'd probably recommend ScyllaDB for NoSQL. It's a replacement for Cassandra (which it's mostly compatible with) which is more or less the de facto standard for large NoSQL deployments at big companies, but it's written in C++ rather than Java so it's even faster (and has more consistent latency) and easier to deploy. And it's been around long enough at this point that it's established and not likely to just disappear.
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.
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.
“Best” depends on your use case. I don’t even think a SQL database is an option for a chat app since it’s write heavy. FB Messenger uses HBase and Discord uses Cassandra and they’ve done their research at scale, so those could be possible options.
Which self hosting instance would go at the size of Facebook or Discord?
Just because Discord took a method doesn't mean a competing product should too.
People opting to use a meme "database" instead of a real DBMS is kind of a large red flag to me. I am hard pressed to imagine data more relational than chat messages and user accounts.
I refuse to believe this is due to technical reasons, as long as we are talking ACID compliant data storage. A well configured PostgreSQL will blow MongoDB out of the water while actually caring about your data.
Especially interesting as they intend to support a matrix bridge: https://revolt.chat/roadmap#checkbox40. It seems like it would be easier to just use Matrix "natively" and then you also have a mostly-working Discord bridge for free.
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.
On the other hand, matrix was explicity designed with bridging in mind, and if this is designed to have a good matrix bridge natively, it'll probably work pretty well without having to stay up to date and without having to implement the full matrix spec.
But the point is: why? Why yet-another messaging protocol? If they wanted to have a different client (which I totally understand, given that Element client is currently just a poor mix of all of Slack and Whatsapp and Discord), they could just focus on the client.
> easier (...) to implement quite a large existing spec
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.
I disagree, the use of MongoDB reflects poorly on the future of the project. In my opinion, a custom protocol does not. They intend for the app to be an alternative to a giant like Discord, so the protocol being custom leaves them with the freedom to introduce features Matrix didn't consider.
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.
the specific task that matrix was built for is super generic: syncing encrypted blobs of json in realtime across a decentralised network. you can build pretty much any comms system on top of that; the question is more whether you want to write your own thing from top to bottom or build on an existing protocol. If you want decentralisation or e2ee for free, then Matrix is a nice way to get it. It doesn’t stop you layering other features on top - you just have to know what you’re building on.
Hi, one of the revolt developers here, we wanted something contained and selfhosted instead of something federated, see https://developers.revolt.chat/faq/federation on why we dont plan on adding federation
Suggestion: lift yourself up without tearing others down. Remove the comments at the end about Matrix leaving a sour taste in your mouth and being buggy: the reasons on this link are sound, engage your audience with all positive energy.
Can't hate you for being opinionated, and I appreciate that you drew a line somewhere.
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.
> From personal experience, I’ve generally found federated protocols to not be suitable for real time communication, Matrix is incredibly buggy at times and it’s left a sour taste in my mouth.
Not sure this is a good reason for not adding it, Element is not buggy at all.
Well… the developers are self described students of the ages of 17 to 19.
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.
This is actually a pretty strong reason. If your target is to build an app like this, getting distracted by a completely different technology which might or might not be more usable for some subproblem is the easiest way to loose interest. And without interest, the open source project is dead in the water.
There's not much (any ?) open-source self-hostable good slack/discord-like apps. Open source projects usually focus on federation and/or encryption when Revolt focus on UI/UX. If you're looking for a free software that just works, with good UI and you don't care for encryption, that might just be the best option out there.
I'm not sure you can find anything more convincing.
Mattermost and rocket.chat don't do voice themselves. Discord does, in the client (no jitsi, etc) Matrix with coturn also does localized voip (i.e. confined to the homeserver) if configured correctly.
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.
I mean, there's matrix. Just because you can federate, doesn't mean you have to. You can run it in isolation (in fact, it's even easier). Additionally, you don't have to care about or enable encryption either.
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.
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.
You know, I was tempted to write that to begin like as I'm a fan of irc over slack for non-work chat, but for the same reason I prefer slack for work - it's sufficiently different.
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.
Unless they plan for their repo to have zero contrib policy and open merge rights, they will also have to follow rules and force people to follow their (third party) rules.
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.
However, open source is almost 100% about "selfish" things like exploration, passion, relaxing etc. as shown by the number of projects that have exactly 1 maintainer (almost all of them). Linux and friends are exceptions and majority of devs working on those are payed by big corps and that is their regular job.
> 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 :)
You're doing some of the most important work on the Internet right now, and I for one am profoundly grateful.
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.
Just look at the screenshot on the RocketChat page.
"Use on a production system is not recommended at this time"
And looking at how buggy RocketChat is without federation I trust them not to use it.
I wasn't defending Rocket.Chat's implementation. I haven't tried it myself.
Matrix is the practical solution, and Arathorn's sibling comment gracefully addressed my real criticism. Federation is absolutely possible on these applications, although tricky.
Is it really "disturbing" if it's maintained by mostly college students? If this was done by industry veterans I could understand your stance, but the way things are this feels uncalled for.
Everyone on the planet is using IPv4 and the internet, yet the understanding ends at 'what is a LAN and what is a port' for a shocking portion of developers. Not knowing about federation[0] doesn't seem so bad.
[0] Most likely this is referencing the term and the structural pattern; as you correctly pointed out, the concept is quite widespread.
Alternatives are always a great thing but I wonder already about survival of this application. Were you guys thinking about any monetization plans already or maybe you going to ask community for support, or you have other ideas if of course such will be needed?
Also, the scrollbar on roadmap page in desktop Vivaldi version doesn't seem to be doing anything.
I'm one of those people, but for a discord alternative, I think it's a pretty fair trade off. My WhatsApp groups are mostly under 100 people while discord servers get much, much bigger. The only thing I feel like would be viable would be one shared encryption key for large rooms that just gets shared between the members via a resource-intensive diffie-helman-like message once and then after that everyone just uses the same key.
> The only thing I feel like would be viable would be one shared encryption key for large rooms that just gets shared between the members via a resource-intensive diffie-helman-like message once and then after that everyone just uses the same key.
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.
Is there a group of people who use WhatsApp who care about e2e encryption and hold it as the standard? Surely its common knowledge that you cannot trust the parent company of WhatsApp, or its encryption since being broken.
500 isn't really asking for much, Signal does up to 1,000 in a group using standard direct messaging encryption (client side fanout). Whatsapp uses a shared hash ratchet and just spins up new keys when someone leaves, this allows it to do 10,000.
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.
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 probably wasn't as clear as I could have been on that. The Discord numbers were meant to provide a point of comparison on how little e2ee really impacts scaling active users vs a traditional system but I wasn't very explicit that's why it was being mentioned.
You can of course install from your package manager [1][2][3][4]. If you're not going to install from your trusted source then I'm not sure curl https://... | bash is really worse than downloading and double clicking a msi/dmg/deb/rpm. Especially if you're not going to verify that or verify it using keys downloaded from the same https host.
>You can of course install from your package manager
Debian 11 was released a couple weeks ago and the rustc it ships with is already so out of date (7 months old, gasp!) software written for modern rust versions can't be compiled with it. And this isn't a Debian only problem.
Is this a Rust only problem? Decided to pick the most well known Go project, kubernetes, and the Go version (1.15) included in Debian 11 is too old to build the first kubernetes project in my search results, kubernetes client as it requires go 1.16, released february.
I've certainly had issues with e.g. the Python or Node version being too outdated on Ubuntu, RHEL, CentOS etc. And when that happens, it's a bigger problem, as it's a runtime dependency, not just a build time one. It's the risk you sign up for picking a fixed release distro.
Consequently, if you're developing cutting edge software in those languages, you're probably running nvm, your favourite virtualenv wrapper (poetry, pipenv, pip-tools), or letting your IDE download a runtime for you. And yes, these tools are full of curl | bash or curl | python install instructions.
It is a rust dev cultural problem that will go away with time and general adoption. Right now almost all people writing in rust are the bleeding edge types that use the latest backwards incompatible features without caring. Combined with these new features being added every couple of months it is almost required to use insecure rustc installation from outside your repos no matter the distro.
Bash actually gets new, backwards incompatible, features pretty often too but you never have to run a bash script in a container or some third party interpreter. Bash devs simply care about having their software be able to run on setups more than a handful of months old.
> It is a rust dev cultural problem that will go away with time and general adoption. Right now almost all people writing in rust are the bleeding edge types that use the latest backwards incompatible features without caring. Combined with these new features being added every couple of months it is almost required to use insecure rustc installation from outside your repos no matter the distro.
And yet at the same time the people working this way are pushing their changes out in a way that affects the rest of the world looking for stable repeatable systems.
There was a brief few weeks at the beginning of this year where pyca/cryptography had a hard dependency on a rust compiler being on the local system. pyca/cryptography is a dependency of a large number of important applications, notably Ansible.
You're fucking up my automation if you're expecting me to `curl <website> | sh` in my build pipelines. pyca/cryptography's maintainers were completely not understanding of the situation and derided anyone who criticized them for it along with statements like "I refuse to work in C++." Zero concern from them about breaking the world for lots of people.
> There was a brief few weeks at the beginning of this year where pyca/cryptography had a hard dependency on a rust compiler being on the local system
To build. Not to use. Your ansible use case would be totally unaffected, as ansible can just pull the manylinux, Windows or Mac wheel from pypi [1] or the python{,3}-cryptography package from your repo[2]. The one major distro where you can't use the manylinux wheel if you decide to build yourself is Alpine, and Alpine packages a sufficiently modern Rust compiler to build the module since 3.12, released May 2020 so it's a non issue there. The last Alpine version without a sufficiently up to date Rust compiler, 3.11, goes out of support in 1.5 months.
This is not like an application depending on a specific Node or Python version, where it must be there at runtime. You can use Ansible with no rust compiler in your life.
Anyway, the current commit of python-cryptography requires Rust 1.41, from January 2020 in the latest commit. This is only two months newer than the required Python version (3.8, from October 2019) for the current commit of Ansible...
At the time (back in february or so) it was to use, before a change was made to use a built version of the library. Pip did not have prebuilt wheels at first. It is just to build as you said _now_.
There were several threads started about the situation at the time and I was also affected by it.
Ultimately the problem is really the shitshow that is Python packaging, but I'm not winning that battle at work anytime soon. There aren't really great replacements for Ansible out there.
That's not the only issue, however, as switching to Rust removed support for a number of niche platforms. pyca/cryptography is also a dependency for OpenWrt which runs on a number of these now-deprecated platforms.
Compatibility is a property of two releases, and it is usually discussed in the context of the API you provide to consumers. It's Rust that's providing APIs here, not the projects themselves. Either way, the parent is talking about Rust here, so that's the perspective being shown.
It appears that 1.16 is available in testing as different package. Chance is high that you will be able to install it without much hassle, since they shipped current stable like a week or so ago.
The Rust packaged in Debian works to build Debian packages; for that purpose, it's fine. For other Rust work, I'm hoping that at some point Debian packages rustup, which would let people use Debian's secure trust chain to bootstrap into rustup's secure trust chain.
Also rust updates fine in gentoo, as I know from compiling Firefox, but mentioning Gentoo all the time as an alternative to Ubuntu got old in 2012, hah.
EPEL does, however. Don't most RHEL/CentOS users enable this? The default CentOS repos don't even have software like nginx or Ansible, and I think it'd be hard to argue that these aren't "mature"
But also, if you're using RHEL/CentOS, haven't you implicitly signed up to _not_ running the cutting edge software? You get what the vendor will support. That's the tradeoff you have chosen by picking such a distribution.
> haven't you implicitly signed up to _not_ running the cutting edge software
Yes, exactly. Meanwhile the Rust community, in its current fast-changing, cutting-edge state is doing its best to work itself into being a basic dependency for everything. In the name of safety.
> Yes, exactly. Meanwhile the Rust community, in its current fast-changing, cutting-edge state is doing its best to work itself into being a basic dependency for everything. In the name of safety.
I don't understand your complaint here. It feels like you want to have your cake and eat it. You want nobody else to use anything too new to be packaged in enterprise Linux repositories, yet you want freedom to use the latest versions of these software, despite having perfectly usable versions for your era of software packaged in that enterprise distro.
Rust is now an indirect dependency of ansible and you need to go outside the RHEL supported process to build the latest commit of ansible (or Firefox, or linkerd, or whatever) on your RHEL/CentOS 7 system. Or you could just use the RHEL supported version of ansible.
The current RHEL version (RHEL 8) even has Rust packages, in the same repository and level of trust as such famously cutting edge software as nginx, node and dotnet.
Take a survey of how many companies are or will ever be on RHEL 8...Most likely only the ones that have 100% of their infrastructure on RHEL and nothing else. A rare few, even in finance these days.
I'm not trying to have my cake and eat it to, I'm asking for package maintainers to use their fucking brains. pyca/cryptography only runs on Rust 1.41 now after efforts that were made to downgrade to a more stable/available/packaged Rust version.
And on the Rust community/leadership, urging everyone to use the bleeding new (curl rustup | sh) instead of stable packages is herding a bunch of lemmings who really should know better, professionally speaking, into building a world that is less maintainable than when they started.
At the risk of replying to an overtly aggressive post on language bashing nonetheless - can you explain why rustups implementation of `curl https://sh.rustup.rs | sh` is worth mentioning? My understanding, from the 1,000 other times these flames start, is it's done properly and no more dangerous than any other way of running 3rd party binaries from a remote source.
Regardless of any other thoughts on Rust folks I'll tip my hat to them for they definitely have made talking about security more common... one way or another apparently :).
Many of the things in this link are avoided by our script. For example, that last one is made impossible by putting the contents of what is to be executed in a function, and then invoking that function at the end. If the connection closes early, nothing will be executed.
The last ones are the same as any other way of downloading software that's executable, and not specific to curl | bash.
Why did you guys go out of your way to make the marketing website more restrictive? I can't select any text on the page, or even find out more about your privacy claims. There's a bit of text that looks like a hyperlink but I can't click it.
How is bot support ? (Or just regular accounts that can send messages using APIs and not GUI clients)
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.
From what I've seen, the quality of the experience is astounding. Well done!
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.
> Please delete user 01FEY4XQ988G9BYFH45JKQZF5R .. .
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.
They could literally create a #DeleteAccount room on the Revolt "Server" or a specific user/bot that could handle deletion request instead of using emails. (Revolt is literally a communication platform!)
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.
Have been using another discord alternative, ripcord [0] for a while (with native (Qt) UI instead of electron). Recently we ripcord users keep getting soft banned from discord (have to reset our password) [1], is it something this project also suffers from?
Discord explicitly disallows third-party clients, and will outright ban you if it detects API usage that obviously originates from self-bots (eg. posting embeds as a regular user). The ripcord ban might be a temporary ban more reliant on heuristics intended to prevent nitro scams like this one[0] where it performs no out-of-the-ordinary API calls but still purchases a bunch of Nitro gifts.
I run the infrastructure department at Discord which includes our anti-spam engineering team --
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.
I got banned a couple months ago seconds after joining the Discord server for a game (https://www.reddit.com/r/LoopHero/comments/lwx8m8/loopers_jo...) and lost all my account information and the servers I had joined, I tried reaching out through that form but got a mail that told that I had indeed abused (without knowing anything about what the abuse was - I barely use discord, as in, I was connecting to chat maybe once a week and am confident I did not violate guidelines, yet this is the mail I had gotten: "Your account was disabled for violating our Terms of Service or Community Guidelines. We’ve reviewed and have confirmed this violation, and we will not be reinstating your account.").
Support n° was 12080748, any chance I could get it back at some point ?
> 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).
Maybe they can cooperate - use the backend of this project in Rust and the native Qt UI from Ripcord instead of this Electron abomination. A perfect synergy.
Discord flagged my account with my main email immediately after registration. Temp email works fine. Support replies with unhelpful canned responses and contacting them didn’t solve my problem. All this is one more reason why an open source alternative is needed and why this is good news.
This might be a dumb question but curious what the issues are with discord? Im a little concerned since I just finally got convinced to start using it.
There's nothing wrong with it per se, in fact Discord is very good software, but it being a for-profit company using closed-source code comes with the usual privacy and free-software concerns. For example here's a post on reddit about some privacy concerns with discord: https://old.reddit.com/r/privacy/comments/eiicah/trawling_th...
I really don't understand people who are 'disappointed' with anything that uses Electron. Sure, it's not as performant as a native app, but writing and maintaining a different native app for every platform you wish to target, and then keeping their UIs united, is unreasonable for most people.
I'd be more disappointed if they didn't use Electron.
I don't like bad software. Almost every Electron app that I've ever encountered was quite bad. They are laggy. Installers in hundreds of megabytes and installed apps are even bigger than that. Yes, it's not that much on it's own but they compound. Even React Native approach is superior to Electron and it's possible to do better than that while not developing separate native app for every platform.
QT QML for the win... (ducks)... Seriously, I still like it. But I write apps that run on phones. Including image editing. Electron, even with wasm is just ... no way.
This is awesome and all, but I don't understand how it will support itself? Unlike Matrix which has plenty of money from government contracts (and venture capitalist money, which kinda sucks but whatever), I don't see how a centralised chat platform with video, voice, data rich messages, etc. relying on donations can support a large user base without one day compromising on privacy respecting data collection.
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.
Repository management and self hosted scripts in Shell. Documentation in HTML and JavaScript. Powered by git. And github. Built in editing in vscode support. Icons in PNG. Badges in SVG!
I don't see anything in the roadmap about being able to listen to multiple voice channels and setup different push-to-talk keys to speak in specific channels.
So it feels like nothing more than another discord clone.
Hi, one of the revolt developers here, bridges between other platforms are planned to be a built-in feature, see the roadmap https://revolt.chat/roadmap
I hate the name personally. I would not feel comfortable asking a normal person (or, now that I think about it, even someone tech-savvy and privacy conscious) “hey come and join my Revolt server”.
At best, it sounds like I’d be inviting them to play some online game.
Honestly, I find it better than naming a chat protocol "Matrix", which either brings to mind the movie or the mathematical structure (it also makes it a pain to search for and distinguish from linear algebra libraries). I'm more bothered by the laziness of using a thesaurus on a competing product which was badly named to begin with (Element was previously Riot). I'd rather have it some nonsensical (Zulip, Jitsi) or misspelled something, partially descriptive (Rocket.chat), or better yet based on a portmanteau (Talkyard, Mattermost) or some kind of clever wordplay.
It’s not like the term “discord” didn’t invite allusions along the same vector. In this regard, the “namers” chose a name that did a hat tip to the original term and communicated “but more!”
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?
Not sure "written in Rust" is a headline thing that's worth mentioning anymore. Particularly amusing in this case when parts of Discord are written in Rust too.
Personally I see “Written in rust” as more of a meme, often using buzzwords like “blazing fast” and “memory safe.” Electron is definitely worse than rust is good.
Don't get me wrong there's a lot of room for speed in programs we use regularly, but I make two observations:
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.
Basically I don't like weird meme based marketing of tech. I'm a grumpy old man already and I'm the ripe old age of 20
You were the one that cynically asked if the advertised performance improvements were real or imaginary, not me.
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).
I’ve always seen “written in Rust” as relevant for a specific sort of software. Because CVEs are inevitable in C/C++ software and dealing with CVEs has become part of the user interface to that software. Knowing something is “written in Rust” means its attack surface is much smaller. Working in tech, the “drop everything and migrate to a version that isn’t vulnerable” instances are far too common and disruptive.
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.
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.
The issue is that the alternatives to Electron--GUI frameworks that use native controls--are so hard to use and inconsistent that Electron seems good by comparison.
Ah, the monolithic HN myth again. That's right, let's just ignore that this place has thousands of readers, thousands of commenters, and that there's no thing called "HN" to talk about as it if had intentionality and/or opinion.
While the readership may be large and diverse, there is nevertheless a Hacker News zeitgeist, especially due to the way downvoting causes comments to be greyed out. The acceptable range of discourse does not extend to anything non-flaggable, and comments do not stand or fall based solely on their thoughtfulness or logic. This forum is still a popularity contest, and there are both winners and losers.
Greyed out comments are still legible. I regularly see people saying things like "I'm sure my comment will be flagged", and days later, it just isn't. Sure, there's a popularity contest - unless you get rid of voting and display-in-vote-order, there always will be. But I would say that paying much attention to that rather than the contents of comments represents a personal choice to be distracted by the noise of the "contest", even while the signal remains in plain sight.
Sometimes folks probably feel HN has three people: the person, the people that agree with the person, the people that disagree with the person. Four, if you count moderaters (who I imagine are cooler than Robocop).
Electron is MAX_HATE, Rust is MAX_LOVE, but Discord is more Electron than it is anything. As in, I don't care if Rust runs on their servers if Electron runs on my desktop.
Loves Rust? My eyes glaze over whenever rust is mentioned in a headline. At this point rust really isn't novel anymore, it's a language loads of programs use.
Hi, one of the developers here, we use electron because its hard for our small amount of devs (there are about 4) of us to maintain multiple clients, this is the same reason we use the same web client for mobile.
Did you consider Qt or some other cross-platform native option? There was just recently a HN article [1] on the topic of cross-platform development and UX, with a few alternatives proposed. I think some teams just reach for the Electron tool by default now, instead of weighing each alternative and then choosing it with eyes open. Maybe your team did examine the pros and cons, but it seems the overall software industry is headed toward a simplistic "Cross Platform Client equals Electron" which is disappointing.
It reads as though there's some confusion between "simplistic" with "simple". Electron is the simple answer, and "simplistic" is frequently used to try to shit on that. (Its implementation is complex. So is Qt's. But nobody cares about that for either, because it's done.) Qt's definition of "cross-platform" is functionally limited to "Windows, Mac, and Linux" unless you want to do way more work for a way worse result. That's not simple at all.
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).
Personally, managing a QT application across multiple OSes is itself harder as I’ve spent a lot of time doing platform-specific UI work (eg. fonts on macOS and DPI scaling problems on Windows) compared to Electron. The only similarity was in doing platform-specific tooling for deployments/code signing which is par for the course.
"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.
There's a bit of a chicken-and-egg thing going on here, though. As a close-by comment noted, there are signs of a convergence of thinking towards "cross-platform means Electron", when this is not actually the case (or is not required to be the case).
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.
I suspect "everything is a web app now" has become a really big consideration. JavaScript has essentially succeeded in doing what Java tried to do two decades ago: be the One Language for both client and server. So if you're building a server-client application like a Discord competitor, it sounds like just an awesome idea to be able to use JavaScript to build your server back end and your web app and your various desktop client apps.
FWIW, as a mostly backend/native developer, I know that I've spent way too much time looking for a widget set that works well enough for my needs. These days, if I need a front-end, I'll be targeting the web or Electron.
A friend and a bunch of her friends had visibly too much time and implement a chat protocol with a server implementation in rust, one in go and one in swift. As well as a client in flutter, rust (iced), Vue and Qt. https://github.com/orgs/harmony-development/repositories
Would be amazing if you worded it as Free Software rather than just open source, since the practical and ethical advantages are indivisible, which is a characteristic of the former and not the latter.
it'll be neat to see if ya'll end up near slack or discord levels of resource consumption, or whether you are slimmer/leaner. is this at all a concern of the team? is chat data all kept in memory or does some of it get stored/loaded on demand, in service worker caches or indexeddb or sqlite or other?
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.
Performance is more important that cross-platform support. If a user has money to feed more and more and more resources into a gluttonous, hideously inefficient web browser masquerading as a program, they have enough money to get on the platform everyone else is on.
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.
Not very familiar with Discord, but from what I understand it seems everyone runs their own server? Like every game/topic/etc community has their own server?
I think a "server" on discord is more like a "organisation" on slack than an actual server. i.e. it's a tenant partition on a multi-tenant centrally hosted system.
On anything you can self-run it's a very useful qualifier. Personally I ignore anything that says "written in Node" because I don't want those headaches.
It's interesting, I suspect we all have our thing we avoid like that - for me it's Java stuff. I don't say that to 'defend' node, I'm no JS fan boy or particularly experienced with it, it just doesn't bother me the way Java stuff does - the dread I have for a Java stack trace appearing from something I'm trying to run is enough to make me see if there's an equivalent that ticks the same boxes in another language!
These days Java applications are supposed to embed the JVM using jlink images or even native installer (see jpackage). So you shouldn't even know if the app is written in Java when you run it.
As someone who now does more operation than devloppement, I want my server side Java app to run on a full JVM, attaching jconsle or jstack to a running process is so usefull. No other runtime on Linux gives the observability you get by default when you run on a full JVM.
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.
The problem with jpackage/jlink is that most teams are stuck on an antiquated runtime and those tools didn’t ship until Java 14 (correct me if I’m wrong about the version). My own company is still making new projects on Java 8.
At work, we use some pretty complex stuff in our builds, including linking to C libs, Groovy testing, Kotlin modules, as well as the majority of the code in Java. It took quite a lot of effort, but we managed to move to Java 11 this year.
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.
> I can't understand why anyone would start something new in Java 8,
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.
... if the application was written recently. Get something from last year on your 'now' computer and let the suffering begin. Without a docker setup, I really find node horrible vs let's say .NET Core, Java/Closure or Go. But ymmv. A project I inherited has node_modules of 780MB with 150k files with many deprecated and vulnerable ones in them pinned versions: I would not call that easy. I never had that with .net: usually you need a few nugets and if you update them, they still work. That I would call easy. I have used both (and java for over 20 years) for 10+ years, I just do not like the ecosystem (or language but that is ok with typescript and purescript and cljs): I have to anyway.
It's not JS or node that's the problem, it's the JS ecosystem. Badly or too broadly defined dependencies can (and do) lead to pulling a new version of a dep that introduced a breaking API change and tada, you have to start hunting for the right version.
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.
Yep, I know the pain all too well. ESM is also currently a disaster as many popular packages migrate without transpiling to CJS and you cannot call ESM from CJS contexts.
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.
Ditto. It's a good indicator of being a sloppily-written pile of dependencies I don't want to touch. I also discriminate against Electron software, at least as much as I'm able.
Totally agree. It's not good for HN to have this kind of repetitive language promotion on the front page. I could see if this was the first major project written in the language, which would make it noteworthy, but something like this needs to stand on its own without the upvotes of Rust fans.
This is the way it’s always been though. First it was Java, then Ruby, then Clojure, then Go, then Node, and now Rust. As languages get popular, multiple projects get rewritten in them. At first it’s a novelty, but it is often useful to see what the strengths and weaknesses are of a language to implement an existing project. Eventually, it becomes annoying to have “written in X” attached to articles and links, but soon, that will diminish.
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.
> As languages get popular, multiple projects get rewritten in them.
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.
Because as fashion driven industry that is the only way many will get experience on language X down on their CV or favourite source code repository for head hunters.
Disagree- three of the first six most recent submissions containing "in rust" are simply educational/about the rust language in general and not showing off a project (while using "rust" as a selling point).
It makes sense to specify the language for open source software. A lot of us are devs who might actually fiddle with the source, if it's written in a language we like to fiddle with.
Exactly what I said yesterday in a different thread:
> 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").
Similarly I used to have an issue with the number of projects submitted to /r/golang that are “a whatever server written in go”. If I wanted to see a new whatever server I would be looking elsewhere and wouldn’t particularly care what language it’s implemented with.
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.
People often use "written in" when they are targeting devs and contributors as no end-user cares about in which jargon we write stuff. In this case, I don't get why they brag as this definitely hits my spaghetti detector: https://github.com/revoltchat/delta/blob/master/src/database...
For me I think “written in Rust”actually does add a lot.
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.
Only "easier to deploy" and "faster in general" are valid points. Most languages used to write servers are practically memory safe, and there are lot of hipsters in rust crowd too.
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".
I guess Rust isn't guaranteed to be memory safe considering unsafe blocks but it does make it much more memory safe than languages which only offer manual memory management.
I didn't know about that preamble, but I definitely got the vibe of "written on a write-only mindset"... just from reading their docs :) not to say trying to delve in the source code!
Rust hasn't magically solved concurrency safety either, as linearity is not enough.
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.
For any open source project, you are marketing as much towards potential developers as you are end-users. Note that their home page doesn't say "Rust" at all. However, on Hacker News, there are potential contributors, and so giving them a bit of information about the project can be useful.
They can use tauri. A new fresh tech and it is efficient also. They should consider it as the title of this post says revolt is written in rust. So they can try more rusty ways making revolt.
As far as I can tell, Electron is the only cross-platform UI toolkit where it's even possible to get accessibility right on every OS.
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.
I'd rather have UIs that are true to their platform (and all the nice little accoutrements that come with) than this universal, inconsistent crap that works OK at best
That Rust has rapidly gone from niche language to powering projects at some of the biggest names in technology, and will almost certainly continue to increase in that marketshare.
To be fair, as a Rust fan I think Kotlin and Swift definitely do better in app development still. They have a lot of good language features and their communities are stellar.
I don't insist on everything being Rust. But it gets very close in many areas IMO.
That Rust is gaining both mind-share and market share.
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.
I would consider it was a interesting flag if I was an investor.
Many startups choose languages because of the benefices that they have, I cant see discord as it is nowadays without Elixir for example.
But obviously, some startups choose because its cool, this ones you shall avoid.
Do you have any plans for capturing game audio on Windows and Linux? It's very annoying to have to boot into Windows if I want to stream a game with audio to some friends.
I'd wager that in general the crowd frequenting this site are much more interested in what the back-end / protocol is written in than what the web app is.
Funny that they are not encrypted and also based in the EU, so any kind of "revolt" against the status quo couldn't ever happen using their platform. https://revolt.chat/aup
Giving this project such a politically charged name is a bit cringey.
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.
When political parties are constantly trying to undermine privacy in most of the world with excuses ranging from terrorism to "think of the children", it's hard to pretend it's not political.
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.
Ok having read the about page, it starts to tell a narrative. It's helpful and gives me a better idea about the motivations behind thebproject, but as a brand name you dont get to force everyone to read your /about when they first see the name Revolt.
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.
Amateur activism across our political spectrum has been a net-negative in my opinion, so I agree, but privacy has no chosen political party or agenda. In that way, I'd caution you from thinking of it "politically" in terms of camps and more "politically" in terms of policy changes needed that both of our parties object to.
>consider if someone is a proponent for privacy, but isn't sure if the're joining software created by activists they disagree with .. the folks behind Gab
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.
Yes, it's just not a good name. Revolt sounds very similar to Riot... which was a messenger that got renamed to Element last year - https://element.io/blog/welcome-to-element/
I hope this goes somewhere!