Revolt: Open-source alternative to Discord(revolt.chat)
revolt.chat
Revolt: Open-source alternative to Discord
https://revolt.chat/
411 comments
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 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?
> the UI is very subtly different to Discord?
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.
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.
This
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.
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.
It really is the difference between channels and rooms, as in visiting rooms or tuning to a frequency to join a radio channel.
It feels very different? And the use-cases are different.
It feels very different? And the use-cases are different.
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.
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.
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.
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.
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.
>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.
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.
I believe mumble/teamspeak have a similar model to Matrix though, in that every room is both a voice channel and a text channel?
Maybe there should be another feature request to auto join voice comms when entering a channel?
Maybe there should be another feature request to auto join voice comms when entering a channel?
You are free to not copy it and people are free to continue to not use it. Seems simple to me.
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.
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.
I think that just elaborates on what was said previously, it's up to you how to set it up if you want the coupling or not.
> 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.
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.
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.
>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.
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.
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.
> Or am I completely misunderstanding something fundamental about Discord's voice rooms?
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 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.
The workflow and "feeling" is not the same.
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
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?
Hi, one of the revolt developers here, we plan to have e2ee on DMs.
Any reason why you think groups shouldn't be able to have private chats?
Group DMs will be encrypted as well
Do you have a link to your project or a way to follow your progress? I'm interested in decentralized community platforms.
I was curious too, on their profile it says "Howler", so I'd assume it's this? https://github.com/HowlerChat/Howler
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.
Any reason to not use the Matrix protocol underneath?
Is it that "Howler chat" app? Is it usable today?
What's your plan for keeping Nazi's off the system?
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.
[0]: https://github.com/revoltchat/delta/blob/master/src/database...
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...
> Currently mongodb is fine for us.
As someone who has administered too many MongoDBs, those are some famous last words.
As someone who has administered too many MongoDBs, those are some famous last words.
Cassandra or HBase are not exactly a utopia either though
Can confirm.
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.
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.
If you had to do it all over again, would you still start with MongoDB or would you go with Cassandra right off the bat?
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!
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.
discord has a good writeup of their migration from mongo to cassandra. https://blog.discord.com/how-discord-stores-billions-of-mess...
If one can afford it, mongodb Atlas is really just fine. As someone said, at scale, all technologies need significant know-how and time investment.
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.
https://docs.atlas.mongodb.com/reference/faq/security/
https://docs.atlas.mongodb.com/reference/faq/security/
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.
The last time I interacted with them was in 2019.
> 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 would strongly urge you to consider migrating to an alternative database, given MongoDB's SSPL license that is difficult to comply with.
What are the best nosql databases? half of our devs dont like sql much (ive tried to make them use orms too, didnt work)
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.
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.
> half of our devs dont like sql much
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...
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...
> half of our devs dont like sql much
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.
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.
unQLite or SQLite would be a great way to encourage self-hosting.
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.
Instead of yet another app/platform, why not Matrix protocol?
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.
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.
Another interesting point is that Conduit (Rust-based implementation of the Matrix homeserver) got a beta release last week.
I'm closely following Conduit and Dendrite. Running a Synapse server currently.
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!
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!
Dendrite is written in Go, Conduit is written in Rust
Oops! Well spotted! Edited my comment to reflect that.
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.
I dunno, maybe it's easier for them than to implement quite a large existing spec, or they just wanted to.
> 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.
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.
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.
Completely agreed.
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.
well said, that's a good rule for life in general
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.
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.
You aren't forced to federate with Matrix. It's as self-contained as you want/require it to be.
> 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.
Not sure this is a good reason for not adding it, Element is not buggy at all.
I run into Element bugs all the time. It's not the worst, but "not buggy at all" is not my experience.
I agree is not a black and white experience.
fwiw we are on a bit of a bug quest currently, so please file bugs as you see them and they will get rapidly triaged & wrangled and maybe even fixed.
Will do thanks!.
Will do!
How does it compare to matrix? Would have been nice to use that since it’s an open protocol that already takes privacy seriously
My question, maybe a bit more meta - is why not instead work on features for matrix and a client like element?
As if the world needs yet another slack-like.
xkcd_15_competing_standards.png
As if the world needs yet another slack-like.
xkcd_15_competing_standards.png
It's in their FAQ[0] as well. But seems to boil down to because they wanted it. And there's nothing wrong with that.
[0]: https://developers.revolt.chat/faq/why_new
[0]: https://developers.revolt.chat/faq/why_new
That is some of the weakest reasoning I've ever read, but... I guess I can't stop them.
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.
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.
It doesn't need to be a success for them to learn from the experience.
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.
There is Mattermost which is very good self hosted alternative to slack. Big players like CERN are using it.
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.
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 was saying that mattermost is reliable alternative to slack. I wasn't talking about Discord.
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.
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.
There is Mumble and Teamspeak. Voice-wise they are equal or better. But not in text (Mumble severely lacking, Teamspeak marginally better).
> Voice-wise they are equal or better
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.
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.
> As if the world needs yet another slack-like.
You mean another IRC-like? :)
You mean another IRC-like? :)
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.
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.
Contributing is hard. U have to follow 3rd party rules.
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.
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.
Their FAQ on “Why no federation?” is relevant: https://developers.revolt.chat/faq/federation
I think the punchline on the FAQ entry is:
> 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 :)
> 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 :)
Element keeps getting notably better :D
Keep polishing it and silence the haters
Keep polishing it and silence the haters
Thank you :) and yup, this is our masterplan :D
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.
Keep up the great work!
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!
"Federation and Discord-style protocols are inherently incompatible"
Really? I wonder how Rocket.Chat federation overcame this "inherent incompatibility"
https://docs.rocket.chat/guides/administration/administratio...
Really? I wonder how Rocket.Chat federation overcame this "inherent incompatibility"
https://docs.rocket.chat/guides/administration/administratio...
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.
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...
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...
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.
Matrix is the practical solution, and Arathorn's sibling comment gracefully addressed my real criticism. Federation is absolutely possible on these applications, although tricky.
> "In terms of the situation, we started the project when none of us even knew what federation was, so it was never even considered from the start."
Well, yes, it is honest, but it also is disturbing - which other well-known network principles were unknown to them?
Well, yes, it is honest, but it also is disturbing - which other well-known network principles were unknown to them?
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.
I mean it is a little absurd, when everyone on the planet is using email, which is federated...
Also absurd that so many of us use SSDs but still don't know what quantum tunneling is...
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.
[0] Most likely this is referencing the term and the structural pattern; as you correctly pointed out, the concept is quite widespread.
i've even heard that some people use some kind of federated packet-switching network these days to communicate. it'll never catch on :)
matrix bridge and e2ee are listed in their roadmap, but there aren't a lot of details
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.
Also, the scrollbar on roadmap page in desktop Vivaldi version doesn't seem to be doing anything.
Considering the Discord backend uses a bunch of Erlang/OTP AFAIK, I'm not sure Rust is an upgrade.
They also use Rust when they hit the limits of the BEAM in specific ways, eg. this is a great read: https://blog.discord.com/using-rust-to-scale-elixir-for-11-m...
Nothing on the Roadmap [1] about encryption.
[1] https://revolt.chat/roadmap
[1] https://revolt.chat/roadmap
They do sort of mention it at the bottom (grep e2ee), but don’t say anything concrete about it.
The plan is to make DMs end to end encrypted.
Be aware people will critique if only PM are only e2e, this is what people who uses Signal and WhatsApp downplay Telegram.
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.
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.
There are opinions, i am not sure if they are real people who care about e2e or just astroturfing from FB.
Let’s say you have a channel with 500 participants. Is there even any sane way to encrypt that channel?
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.
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.
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.
Discord doesn't do E2E encryption, although those numbers for Signal and Whatsapp are pretty impressive.
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.
busterarm(2)
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.
[deleted]
[deleted]
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.
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.
What about Conduit? Recently entered beta and is also written in rust.
https://conduit.rs/
https://conduit.rs/
Some screenshots and features of Conduit would be nice.
It's a server, here are clients for it https://matrix.org/clients/ (with pictures). Features https://matrix.org/discover/
I understand now thanks.
It doesn't seem like they have explicit bot support yet given their roadmap[1]. It's supposed to be in their next update though.
[1] https://revolt.chat/roadmap
[1] https://revolt.chat/roadmap
Hi one of the developers here, bot support does exist, we have multiple libraries in different languages you can use, checkout https://github.com/insertish/awesome-revolt
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.
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.
I've heard that too. But I am using gmail and had no trouble registering.
Please delete user 01FEY4XQ988G9BYFH45JKQZF5R.
Can't even delete our own account....
> 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:[email protected]?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.
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:[email protected]?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.
Not being able to delete your own account yourself is a valid complaint. Having to send an email is 100% not acceptable.
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.
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?
[0]: https://cancel.fm/ripcord/ [1]: https://dev.cancel.fm/tktview?name=8f8ecd4b60
[0]: https://cancel.fm/ripcord/ [1]: https://dev.cancel.fm/tktview?name=8f8ecd4b60
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.
0: https://support.discord.com/hc/en-us/community/posts/3600683...
0: https://support.discord.com/hc/en-us/community/posts/3600683...
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.
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 ?
Support n° was 12080748, any chance I could get it back at some point ?
That sounds like maybe Discord actually supports third party clients? Or is there some subtlety to this that I’m missing?
Define 'supports.'
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.
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.
Just curious -- where in the TOS are third party clients forbidden? I've read it a few times, and I'm not seeing it.
Probably:
> 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).
> 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).
A third party client like Ripcord isn't a derivative work.
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.
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.
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.
Can the backend be used alone with a custom frontend (or any plans to convert backend to a SDK) ?
I believe it can. The protocol seems pretty thoroughly documented https://developers.revolt.chat/
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...
From the website, it is unclear to me what the business model will be in the future. Will you go for a model similar to what GitLab does?
It's not Rust, it's Electron...
Backend is in rust, but I'm disappointed too.
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'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.
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.
Github link: https://github.com/revoltchat
The backend is in Rust, frontend is Typescript.
The backend is in Rust, frontend is Typescript.
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!
Nice touch with the "Open [My email provider]" button/link (to confirm your email) after signing up! Haven't seen that anywhere before.
So is it fully decentralized? Nowhere is this talked about so I assume not. If not, how are they going to pay for servers?
It's not decentralized and they don't plan to decentralize it.
This is super exciting, Discord needs some real competition that is attractive to their current userbase. Good luck :)
[deleted]
Aren't you worried about name similarity to Revolut? Or old RC car game Re-volt?
The verify email process has a link to go to your email provider. that's slick.
[deleted]
How are they going to make money and support the development?
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.
So it feels like nothing more than another discord clone.
Ugh, don't lock the zoom on a mobile page please, especially if you're going to show tiny desktop screenshots.
I was interested, now I've bounced.
I was interested, now I've bounced.
please turn off the captcha
Would love to see bridging.
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
What’s wrong with Discord?
[deleted]
chrome is blocking password resets due to a CORS issue.
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.
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?
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?
I am surprised nobody in this comments section has mentioned "Re-Volt" (1999) yet. https://en.wikipedia.org/wiki/Re-Volt
how about a discord-compatible backend?
What would be the point? There's explicitly no third-party clients allowed for official Discord.
A Discord compatible backend would allow existing bot frameworks to work with the platform.
Hi, one of the revolt developers here, We plan to have a built-in discord/matrix/etc bridge.
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.
Also, only the backend is written in Rust. The desktop client is an Electron app: https://github.com/revoltchat/desktop
Now I want to know if HN hates Electron more than it loves Rust. Or do they perfectly cancel out?
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.
> Blazing fast
So have you measured it or do you just mean you haven't implemented as many features? -> Usually the latter.
So have you measured it or do you just mean you haven't implemented as many features? -> Usually the latter.
Cynicism aside, from what I’ve seen it’s been the former. See regex and rg by burntsushi as an example.
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.
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).
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.
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.
"Electron is definitely worse than rust is good."
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.
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.
Thankfully there is no C++ on Electron.
Is Rust as blazing fast as Electron is slow?
But Rust runs on the server while Electron runs on the client. You can't compare them like that!
[deleted]
Rust is about as fast as C++, so I'd call that normal speed.
Electron is not necessarily slow - see Visual Studio Code; it's certainly not as reactive as Sublime Text, but it's fast/reactive enough.
I know, it was a (admittedly vague) joke.
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.
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.
There definitely are trends on HN and while they don't fit a 100% of the population, they drive a lot of the opinions and discourse.
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).
Okay, enough navel gazing for me!
Okay, enough navel gazing for me!
Discord is not bad for me wrt resource usage, but it wasn't always good and it had problems. I've been impressed by their development.
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.
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.
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.
Rust people tend to love Electron, since (as with most niche programming languages), Electron is arguably its best GUI story
The only Electron apps I use, are doing work time as I have no say in what either employer or customer require me to use.
My private computers they are mostly Electron free as far as I can tell, and yes I even pay for Sublime Text.
My private computers they are mostly Electron free as far as I can tell, and yes I even pay for Sublime Text.
Hatred for misleading headlines outranks hatred of Electron.
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.
1: https://news.ycombinator.com/item?id=28390732
1: https://news.ycombinator.com/item?id=28390732
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).
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.
Electron leverages web-style development, which Qt (or GTK or FLTK, or JUCE, or wxwidgets, or libui ... etc) does not manage to do in any real sense.
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.
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.
"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.
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.
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.
So, +1 to the developers of Revolt.
So, +1 to the developers of Revolt.
People understand this, but they refuse to understand this.
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!
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!
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
Great choice, thanks for being practical and realistic.
Hate on HN does not predict any kind of product metric.
Hate on HN does not predict any kind of product metric.
Electron is almost never a great choice for anything. It saddens me to see people on a website for nerds defend it.
What is "a great choice"?
In my opinion, highly biased - Lazarus/lcl, wxwidgets, Qt, imgui, in no particular order.
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.
Thank you for writing for all.
Thank you for writing for all.
That's a shame.
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.
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.
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.
> Performance is more important that cross-platform support.
You have to be where the people are to make it worth anyone's time to complain about performance.
You have to be where the people are to make it worth anyone's time to complain about performance.
> Do we run our own servers? No, you run them?
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.
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.
> Performance is more important that cross-platform support
telling the author what their priorities need to be... nice.
telling the author what their priorities need to be... nice.
One of the wonderful things about rust is it's a nice, modern language with good performance. Electron will be a performance limiting factor.
That's odd honestly because there are excellent rust-based bindings for electron
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.
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.
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.
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.
That’s a shame. Node is quite easy to run.
Biggest problem is that installing any app includes a free black hole.
Biggest problem is that installing any app includes a free black hole.
... 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.
> includes a free black hole.
This is gospel at this point.
Npmming and yarning are giving me anxiety these days.
This is gospel at this point.
Npmming and yarning are giving me anxiety these days.
JS and Rust are best friends. Deno is written in Rust. And many Node native libs are being written in Rust.
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.
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.
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.
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.
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.
I think it matters to communicate the language/tech in an open source project specifically.
busterarm(1)
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").
> 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").
Yeah that makes sense. Revolt was posted to r/Rust yesterday so OP is probably a person who frequents r/Rust and thought it was notable.
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.
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...
Also, the backend of Discord is elixir/Erlang, which is a great fit for a messaging app. To me rust would be a step back.
(Discord also uses Rust NIFs with their Elixir)
But apart from the advertisement of language choice, an OSS alternative is quite good, no? I’d be keen to try it out.
[deleted]
[deleted]
[deleted]
This is getting very lousy.
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.
I think those are all valuable hints.
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.
[deleted]
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.
> memory safe
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".
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.
Just `leak` all your variables before they go out of scope ;)
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!
> That's an incorrect assumption if you haven't audited the code.
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.
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.
That's a confusing statement -- JS/Node and Golang are comparable (memory safe) languages for API server backends.
Golang is only memory safe if you're not using the concurrency features. It doesn't protect against data races which can break safety.
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.
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.
Perhaps offtopic, but why is it so common with new tools for the language it's written in, of all things, to be selected as the top selling point?
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.
This makes a lot of sense to me, and I've never thought of it like this before.
Excellent point!
It could attract more developers.
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.
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.
We want to make sure it's not being written in Electron
Front-end is, though: https://github.com/revoltchat/desktop
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.
I welcome apps using Electron, most Electron apps I use work great and have nice UIs that are consistent across platforms
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.
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
It’s a well known way of getting your post to HN frontpage.
If only we could filter out this stuff.
Rust is such a niche language still that I'd consider it a red flag if I was an investor.
You would make a bad investor if you can't recognize the writing on the wall.
Which is?
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.
https://foundation.rust-lang.org/members/ just look at the companies that are a part of the foundation.
https://foundation.rust-lang.org/members/ just look at the companies that are a part of the foundation.
IMHO: Rust is going to be very very popular on everything from embedded to client-side web apps.
Headlines like the one on this submission makes me think "finally, someone has started to write that thing in a sensible language".
Headlines like the one on this submission makes me think "finally, someone has started to write that thing in a sensible language".
I very much hope Rust becomes popular in the embedded space... but other languages are better for apps IMO.
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'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.
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.
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.
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.
Would you say that Rust's learning curve is also still an obstacle to widespread adoption?
It was a while ago, but I haven't asked around lately.
It was a while ago, but I haven't asked around lately.
I'd say so, yes, but it's definitely easy to start with it and use it just fine before you have to delve deeper.
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.
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.
What makes it niche to you? It's got quite a strong foothold now in a lot of major companies, and projects.
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.
But obviously, some startups choose because its cool, this ones you shall avoid.
Does it offer screen share features and customized stickers?
Both are planned features
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.
Element (uses Matrix protocol) can capture Pipewire as of a few days ago.
screen share wont be a feature for a while, but the hope is to capture game audio as well
it's not written in Rust, it is written in Typescript
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
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
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.
I guess I'm not a part of this "general" then.
Solutions should solve a problem. Tech demos should demonstrate tech.
Solutions should solve a problem. Tech demos should demonstrate tech.
You might not be, hence 'general' and not 'all'...
This application solves a problem. An application is more than its front end...
This application solves a problem. An application is more than its front end...
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
> if you use Discord, you don't care about the backend, it doesn't run on your machine
If you use Discord you probably don't care about self hosting, which a Revolt user might.
If you use Discord you probably don't care about self hosting, which a Revolt user might.
Note that this post was not made by any of the developers but by a third party, and they chose the title.
> if you use Discord, you don't care about the backend, it doesn't run on your machine
Right, but for a self hosted project this might of interest.
Right, but for a self hosted project this might of interest.
Good point
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.
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.
https://revolt.chat/about
They're marketing to a privacy aware audience which is, unfortunately these days, political to some.
They're marketing to a privacy aware audience which is, unfortunately these days, political to some.
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.
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.
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.
I have no issue with privacy. The product is not called Privacy. The product is called Revolt.
>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.
[0] https://joinmastodon.org/ [1] https://blog.joinmastodon.org/2019/07/statement-on-gabs-fork...
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...
How come a similarly politically charged name hasn't prevented the wide adoption of Discord?
How come Riot changed it's name to Element?
A large part was due to confusion with the company that makes League of Legends, from what I understand.
Came here to say that we adopted Riot once it rebranded to Element.
because the definition of the word discord isn't *politically* charged.
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!