[HN Gopher] Revolt: Open-source alternative to Discord
___________________________________________________________________
Revolt: Open-source alternative to Discord
Author : adamnemecek
Score : 497 points
Date : 2021-09-06 14:29 UTC (8 hours ago)
(HTM) web link (revolt.chat)
(TXT) w3m dump (revolt.chat)
| rnotaro wrote:
| Please delete user 01FEY4XQ988G9BYFH45JKQZF5R. Can't even delete
| our own account....
| Felk wrote:
| > Please delete user 01FEY4XQ988G9BYFH45JKQZF5R .. .
|
| It's one thing to make a valid complain about there not being
| an automated account deletion feature yet, requiring you to
| send an email. And even then it's not that bad since it's
| literally a "mailto:contact@revolt.chat?Subject=Delete my
| account" link. It's another thing to make a temper tantrum out
| of it: https://imgur.com/U2DJwm7
|
| Please don't be the guy that's technically right but an ass
| about it.
| luke2m wrote:
| Would love to see bridging.
| Zomatree wrote:
| 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
| platz wrote:
| 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.
| 1MachineElf wrote:
| How come a similarly politically charged name hasn't prevented
| the wide adoption of Discord?
| platz wrote:
| because the definition of the word discord isn't
| *politically* charged.
| croes wrote:
| How come Riot changed it's name to Element?
| opan wrote:
| A large part was due to confusion with the company that
| makes League of Legends, from what I understand.
| hammyhavoc wrote:
| Came here to say that we adopted Riot once it rebranded to
| Element.
| jstx1 wrote:
| 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/
| kodah wrote:
| https://revolt.chat/about
|
| They're marketing to a privacy aware audience which is,
| unfortunately these days, political to some.
| alpaca128 wrote:
| 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.
| platz wrote:
| 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.
| uselesscynicism wrote:
| >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...
| kodah wrote:
| 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.
| platz wrote:
| I have no issue with privacy. The product is not called
| Privacy. The product is called Revolt.
| toiletfuneral wrote:
| If it would make you feel better , just fork it and rename it
| 'bootlicker'
| Shadonototro wrote:
| 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
| jsuqo wrote:
| 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
| Felk wrote:
| Note that this post was not made by any of the developers but
| by a third party, and they chose the title.
| breakfastduck wrote:
| 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.
| hammyhavoc wrote:
| I guess I'm not a part of this "general" then.
|
| Solutions should solve a problem. Tech demos should
| demonstrate tech.
| robertlagrant wrote:
| > 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.
| adamnemecek wrote:
| > 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.
| Shadonototro wrote:
| Good point
| donkarma wrote:
| how about a discord-compatible backend?
| hammyhavoc wrote:
| The advantage being what?
| evv wrote:
| Advantage goes to MSFT shareholders.
| Zomatree wrote:
| Hi, one of the revolt developers here, We plan to have a built-
| in discord/matrix/etc bridge.
| DoctorOW wrote:
| What would be the point? There's explicitly no third-party
| clients allowed for official Discord.
| crocodiletears wrote:
| A Discord compatible backend would allow existing bot
| frameworks to work with the platform.
| meibo wrote:
| This is super exciting, Discord needs some real competition that
| is attractive to their current userbase. Good luck :)
| mumblemumble wrote:
| 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?
| mekster wrote:
| 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.
| kahlonel wrote:
| It's a well known way of getting your post to HN frontpage.
| steveklabnik wrote:
| 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.
| schmorptron wrote:
| This makes a lot of sense to me, and I've never thought of it
| like this before. Excellent point!
| edem wrote:
| Rust is such a niche language still that I'd consider it a red
| flag if I was an investor.
| pdimitar wrote:
| You would make a bad investor if you can't recognize the
| writing on the wall.
| edem wrote:
| Which is?
| cthalupa wrote:
| 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.
| pdimitar wrote:
| 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.
| verdagon wrote:
| 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.
| pdimitar wrote:
| 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.
| Flow wrote:
| 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".
| verdagon wrote:
| 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.
| pdimitar wrote:
| 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.
| shiryel wrote:
| 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.
| dagmx wrote:
| What makes it niche to you? It's got quite a strong foothold
| now in a lot of major companies, and projects.
| edem wrote:
| Just look at the numbers.
| dagmx wrote:
| What does that mean? The numbers show that a lot of
| companies are using Rust. Which numbers do you think make
| it seem niche?
| tomc1985 wrote:
| We want to make sure it's not being written in Electron
| ejj28 wrote:
| I welcome apps using Electron, most Electron apps I use work
| great and have nice UIs that are consistent across platforms
| tomc1985 wrote:
| 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
| mumblemumble wrote:
| 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.
| tanaypingalkar wrote:
| 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.
| ShrigmaMale wrote:
| Front-end is, though: https://github.com/revoltchat/desktop
| goodpoint wrote:
| If only we could filter out this stuff.
| _han wrote:
| 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?
| HoppyHaus wrote:
| Finally, something that outright says that its intent is to be a
| discord alternative. So many platforms try to sell themselves on
| some other feature, rather than just being open source and self-
| hostable. So many things, like Matrix, come close, but lack key
| components to really competing, such as voice channels rather
| than calls.
|
| I hope this goes somewhere!
| Arathorn wrote:
| 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?
| mikenew wrote:
| > 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.
| jelv wrote:
| This
| thayne wrote:
| 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
| gsich wrote:
| The workflow and "feeling" is not the same.
| meibo wrote:
| 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.
| e12e wrote:
| 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.
| Arathorn wrote:
| 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 :)
| preya2k wrote:
| "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.
| iamstupidsimple wrote:
| 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.
| xfalcox wrote:
| 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.
| lavabiopsy wrote:
| 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)
| MINIMAN10000 wrote:
| 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.
| lavabiopsy wrote:
| 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.
| errantspark wrote:
| 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.
| lavabiopsy wrote:
| 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.
| trulyme wrote:
| 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.
| lavabiopsy wrote:
| 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.
| cdash wrote:
| You are free to not copy it and people are free to
| continue to not use it. Seems simple to me.
| lavabiopsy wrote:
| 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.
| errantspark wrote:
| 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?
| stryan wrote:
| > 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.
| simonh wrote:
| >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.
| lawl wrote:
| > 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.
| Rd6n6 wrote:
| 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
| tiagod wrote:
| Considering the Discord backend uses a bunch of Erlang/OTP AFAIK,
| I'm not sure Rust is an upgrade.
| mcintyre1994 wrote:
| 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...
| [deleted]
| mathw wrote:
| 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.
| CR007 wrote:
| 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...
| bachmeier wrote:
| 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.
| mbreese wrote:
| 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.
| AnIdiotOnTheNet wrote:
| > 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.
| dgb23 wrote:
| I think it matters to communicate the language/tech in an
| open source project specifically.
| busterarm wrote:
| It bothers me that we don't view it as a problem on this
| board the fact that we have an entire upvote/downvote brigade
| that reacts purely on whether you're speaking good or ill
| about Rust.
|
| I'm not one to tell moderators what to do but on some boards
| people get told off severely for such behavior.
|
| "x in rust"[1] threads are so prevalent that they should get
| a ranking penalty.
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu.
| ..
| sodality2 wrote:
| Disagree- three of the first six most recent submissions
| containing "in rust" are simply educational/about the rust
| language in general and not showing off a project (while
| using "rust" as a selling point).
|
| https://i.imgur.com/WCD7iem.png
| jhgb wrote:
| Why not the fifth entry? That seems similar to the
| highlighted ones.
| sodality2 wrote:
| Yep, that one is informative as well. My bad!
| nabakin wrote:
| 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.
| [deleted]
| [deleted]
| marsven_422 wrote:
| It's good it say rust since I fail the "correct political
| opinion" test for using rust I will be unable to install it.
| axegon_ wrote:
| 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").
| [deleted]
| onionisafruit wrote:
| 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.
| timdorr wrote:
| Also, only the backend is written in Rust. The desktop client
| is an Electron app: https://github.com/revoltchat/desktop
| Zomatree wrote:
| 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.
| ryandrake wrote:
| 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
| chipotle_coyote wrote:
| 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.
| eropple wrote:
| 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).
| judge2020 wrote:
| 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.
| PaulDavisThe1st wrote:
| 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.
| hutzlibu wrote:
| "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.
| PaulDavisThe1st wrote:
| 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.
| dancemethis wrote:
| 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.
| AnIdiotOnTheNet wrote:
| That's a shame.
| rektide wrote:
| 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.
| arcturus17 wrote:
| 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!
| ognarb wrote:
| 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
| ergot_vacation wrote:
| 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.
| nicoburns wrote:
| > 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.
| auxym wrote:
| 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?
| nicoburns wrote:
| 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.
| eropple wrote:
| _> 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.
| rektide wrote:
| > _Performance is more important that cross-platform
| support_
|
| telling the author what their priorities need to be...
| nice.
| Griffinsauce wrote:
| Great choice, thanks for being practical and realistic.
|
| Hate on HN does not predict any kind of product metric.
| lpcvoid wrote:
| Electron is almost never a great choice for anything. It
| saddens me to see people on a website for nerds defend
| it.
| sam0x17 wrote:
| That's odd honestly because there are excellent rust-based
| bindings for electron
| the__alchemist wrote:
| One of the wonderful things about rust is it's a nice, modern
| language with good performance. Electron will be a
| performance limiting factor.
| jstx1 wrote:
| Now I want to know if HN hates Electron more than it loves
| Rust. Or do they perfectly cancel out?
| cartoonworld wrote:
| 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.
| DiabloD3 wrote:
| Electron is MAX_HATE, Rust is MAX_LOVE, but Discord is more
| Electron than it is anything. As in, I don't care if Rust
| runs on their servers if Electron runs on my desktop.
| jstx1 wrote:
| Yeah, Electron feels more like a choice that matters.
| kingofclams wrote:
| 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.
| hutzlibu wrote:
| "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.
| mhh__ wrote:
| > Blazing fast
|
| So have you measured it or do you just mean you haven't
| implemented as many features? -> Usually the latter.
| stouset wrote:
| Cynicism aside, from what I've seen it's been the former.
| See regex and rg by burntsushi as an example.
| mhh__ wrote:
| Don't get me wrong there's a lot of room for speed in
| programs we use regularly, but I make two observations:
| 1. Speed is usually found by by people have worked on
| existing tools in the space, and they don't often make
| that much of a song and dance about it beyond that
| theirs is faster. 2. Speed is found in the
| minds of people not in their tools. When you get
| past a certain amount of native- ness, you get
| optimizations by knowing more or having a
| brilliant insight into the problem rather than using
| a new meme-language. It might be necessary for certain
| types of programming but it's not sufficient.
|
| Basically I don't like weird meme based marketing of
| tech. I'm a grumpy old man already and I'm the ripe old
| age of 20
| jasonhansel wrote:
| 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.
| Griffinsauce wrote:
| Is Rust as blazing fast as Electron is slow?
| [deleted]
| pizza234 wrote:
| Electron is not necessarily slow - see Visual Studio
| Code; it's certainly not as reactive as Sublime Text, but
| it's fast/reactive enough.
| ginko wrote:
| Rust is about as fast as C++, so I'd call that normal
| speed.
| grishka wrote:
| But Rust runs on the server while Electron runs on the
| client. You can't compare them like that!
| curun1r wrote:
| 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.
| neutronicus wrote:
| Rust people tend to love Electron, since (as with most
| niche programming languages), Electron is arguably its best
| GUI story
| PaulDavisThe1st wrote:
| 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.
| tomrod wrote:
| 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!
| xeromal wrote:
| 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.
| rectang wrote:
| 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.
| PaulDavisThe1st wrote:
| 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.
| potiuper wrote:
| Hatred for misleading headlines outranks hatred of
| Electron.
| noobermin wrote:
| 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.
| vlunkr wrote:
| 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.
| steveklabnik wrote:
| (Discord also uses Rust NIFs with their Elixir)
| DennisP wrote:
| 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.
| drcongo wrote:
| 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.
| OJFord wrote:
| 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!
| brabel wrote:
| 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.
| nick__m wrote:
| 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.
| vips7L wrote:
| 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.
| zbrozek wrote:
| 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.
| Aeolun wrote:
| That's a shame. Node is quite easy to run.
|
| Biggest problem is that installing any app includes a free
| black hole.
| vagrantJin wrote:
| > includes a free black hole.
|
| This is gospel at this point.
|
| Npmming and yarning are giving me anxiety these days.
| vaughan wrote:
| JS and Rust are best friends. Deno is written in Rust. And
| many Node native libs are being written in Rust.
| Popegaf wrote:
| 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.
| vaughan wrote:
| 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.
| tluyben2 wrote:
| ... 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.
| RcouF1uZ4gsC wrote:
| 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.
| chakkepolja wrote:
| 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.
| spopejoy wrote:
| > 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".
| posixplz wrote:
| >> memory safe
|
| > That's an incorrect assumption if you haven't audited the
| code.
|
| Audit the code? Simply `grep unsafe`.
| sodality2 wrote:
| Well, perhaps `rg unsafe` if you want to use the rust
| counterpart to grep, ripgrep ;)
| j1elo wrote:
| 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!
| adamnemecek wrote:
| > 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.
| cjbprime wrote:
| That's a confusing statement -- JS/Node and Golang are
| comparable (memory safe) languages for API server
| backends.
| zozbot234 wrote:
| Golang is only memory safe if you're not using the
| concurrency features. It doesn't protect against data
| races which can break safety.
| nabakin wrote:
| 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.
| colejohnson66 wrote:
| Just `leak` all your variables before they go out of
| scope ;)
| [deleted]
| jedisct1 wrote:
| This is getting very lousy.
| hestefisk wrote:
| But apart from the advertisement of language choice, an OSS
| alternative is quite good, no? I'd be keen to try it out.
| NmAmDa wrote:
| Captcha is not working on Firefox. And it is required at each
| login.
| ztgasdf wrote:
| Working for me, Firefox 91.0.2 on Windows 10. Perhaps check
| your blockers?
| IceWreck wrote:
| 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.
| KitDuncan wrote:
| What about Conduit? Recently entered beta and is also written
| in rust.
|
| https://conduit.rs/
| Zomatree wrote:
| 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
| nabakin wrote:
| 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
| anchpop wrote:
| How does it compare to matrix? Would have been nice to use that
| since it's an open protocol that already takes privacy seriously
| metasyn wrote:
| matrix bridge and e2ee are listed in their roadmap, but there
| aren't a lot of details
| mbrubeck wrote:
| Their FAQ on "Why no federation?" is relevant:
| https://developers.revolt.chat/faq/federation
| Arathorn wrote:
| 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 :)
| aceArtGmbH wrote:
| Element keeps getting notably better :D
|
| Keep polishing it and silence the haters
| Arathorn wrote:
| Thank you :) and yup, this is our masterplan :D
| eointierney wrote:
| 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!
| evv wrote:
| "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.
| ..
| aceArtGmbH wrote:
| 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/adminis
| tration/administratio...
| evv wrote:
| 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.
| DocTomoe wrote:
| > "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?
| Felk wrote:
| 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.
| KitDuncan wrote:
| I mean it is a little absurd, when everyone on the planet
| is using email, which is federated...
| Arathorn wrote:
| i've even heard that some people use some kind of
| federated packet-switching network these days to
| communicate. it'll never catch on :)
| prashantsengar wrote:
| Also absurd that so many of us use SSDs but still don't
| know what quantum tunneling is...
| theelous3 wrote:
| 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
| matbatt38 wrote:
| 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.
| gsich wrote:
| There is Mumble and Teamspeak. Voice-wise they are equal or
| better. But not in text (Mumble severely lacking, Teamspeak
| marginally better).
| NmAmDa wrote:
| There is Mattermost which is very good self hosted
| alternative to slack. Big players like CERN are using it.
| majkinetor wrote:
| Contributing is hard. U have to follow 3rd party rules.
| theelous3 wrote:
| 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.
| majkinetor wrote:
| 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.
| Fabricio20 wrote:
| 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
| theelous3 wrote:
| That is some of the weakest reasoning I've ever read,
| but... I guess I can't stop them.
| true_religion wrote:
| 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.
| jedberg wrote:
| > As if the world needs yet another slack-like.
|
| You mean another IRC-like? :)
| theelous3 wrote:
| 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.
| arkh wrote:
| 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.
| adamnemecek wrote:
| Github link: https://github.com/revoltchat
|
| The backend is in Rust, frontend is Typescript.
| mirekrusin wrote:
| 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!
| pkdpic_y9k wrote:
| 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.
| Felk wrote:
| 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...
| sam0x17 wrote:
| So is it fully decentralized? Nowhere is this talked about so I
| assume not. If not, how are they going to pay for servers?
| icy wrote:
| It's not decentralized and they don't plan to decentralize it.
| Felk wrote:
| One thing some may consider "decentralized" is that you can
| self-host
| schmorptron wrote:
| Like TeamSpeak
| jpxw wrote:
| 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.
| travisgriggs wrote:
| 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?
| notthemessiah wrote:
| 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.
| rusht wrote:
| 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?
| Zomatree wrote:
| 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.
| Conan_Kudo wrote:
| I would strongly urge you to consider migrating to an
| alternative database, given MongoDB's SSPL license that is
| difficult to comply with.
| Zomatree wrote:
| What are the best nosql databases? half of our devs dont
| like sql much (ive tried to make them use orms too, didnt
| work)
| carlhjerpe wrote:
| unQLite or SQLite would be a great way to encourage self-
| hosting.
| Felk wrote:
| > 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.
| lpcvoid wrote:
| 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.
| nicoburns wrote:
| 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.
| rusht wrote:
| ScyllaDB looks interesting but that AGPL license is a no
| go for some organizations.
| nicoburns wrote:
| True, but revolt seems to be using AGPL themselves, so I
| doubt it would be an issue for them.
| e12e wrote:
| > 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/datab
| ase...
|
| https://github.com/revoltchat/delta/blob/master/src/datab
| ase...
| rusht wrote:
| "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.
| mekster wrote:
| Which self hosting instance would go at the size of
| Facebook or Discord? Just because Discord took a method
| doesn't mean a competing product should too.
| rusht wrote:
| I am assuming they want to provide a hosted service just
| like Discord at some point.
| hardwaresofton wrote:
| 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/data
| base...
| vorpalhex wrote:
| > Currently mongodb is fine for us.
|
| As someone who has administered too many MongoDBs, those are
| some famous last words.
| mrits wrote:
| Cassandra or HBase are not exactly a utopia either though
| zorkian wrote:
| 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.
| rusht wrote:
| 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?
| baq wrote:
| discord has a good writeup of their migration from mongo
| to cassandra. https://blog.discord.com/how-discord-
| stores-billions-of-mess...
| neeleshs wrote:
| 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.
| junon wrote:
| 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.
| neeleshs wrote:
| 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.
| neeleshs wrote:
| 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.
| hammyhavoc wrote:
| Instead of yet another app/platform, why not Matrix protocol?
| Zomatree wrote:
| 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
| hammyhavoc wrote:
| You aren't forced to federate with Matrix. It's as self-
| contained as you want/require it to be.
| smoldesu wrote:
| 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.
| ringworld wrote:
| 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.
| holler wrote:
| well said, that's a good rule for life in general
| stiltzkin wrote:
| > 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.
| steveklabnik wrote:
| I run into Element bugs all the time. It's not the worst,
| but "not buggy at all" is not my experience.
| stiltzkin wrote:
| I agree is not a black and white experience.
| Arathorn wrote:
| 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.
| geozh wrote:
| > why not Matrix protocol?
|
| here's why:
| https://gist.github.com/maxidorius/5736fd09c9194b7a6dc03b6b8...
|
| you're a clown if you think Matrix or this new Revolt thing are
| any better than the garbage fire that Discord is
| kevincox wrote:
| 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.
| rglullis wrote:
| Another interesting point is that Conduit (Rust-based
| implementation of the Matrix homeserver) got a beta release
| last week.
| hammyhavoc wrote:
| 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!
| sseneca wrote:
| Dendrite is written in Go, Conduit is written in Rust
| hammyhavoc wrote:
| Oops! Well spotted! Edited my comment to reflect that.
| schmorptron wrote:
| 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.
| rglullis wrote:
| 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.
| schmorptron wrote:
| I dunno, maybe it's easier for them than to implement
| quite a large existing spec, or they just wanted to.
| hammyhavoc wrote:
| Completely agreed.
| cassonmars wrote:
| 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?
| Zomatree wrote:
| Hi, one of the revolt developers here, we plan to have e2ee on
| DMs.
| napworth wrote:
| What's your plan for keeping Nazi's off the system?
| antcas wrote:
| Do you have a link to your project or a way to follow your
| progress? I'm interested in decentralized community platforms.
| schmorptron wrote:
| I was curious too, on their profile it says "Howler", so I'd
| assume it's this? https://github.com/HowlerChat/Howler
| olah_1 wrote:
| Is it that "Howler chat" app? Is it usable today?
| sergiotapia wrote:
| 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]
| Griffinsauce wrote:
| 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.
| pndy wrote:
| 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.
| drcursor wrote:
| Nothing on the Roadmap [1] about encryption.
|
| [1] https://revolt.chat/roadmap
| Zomatree wrote:
| The plan is to make DMs end to end encrypted.
| stiltzkin wrote:
| Be aware people will critique if only PM are only e2e, this
| is what people who uses Signal and WhatsApp downplay
| Telegram.
| schmorptron wrote:
| 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.
| stiltzkin wrote:
| > 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.
| SkyMarshal wrote:
| They do sort of mention it at the bottom (grep e2ee), but don't
| say anything concrete about it.
| busterarm wrote:
| written in Rust!
|
| don't forget to `curl https://sh.rustup.rs | sh`!
|
| Footnote: As the Rust community continues to bash everyone over
| the head about how safe it is while completely fucking up the
| 101 shit we've all been saying not to do for over 20 years, I'm
| going to continue to treat it how it smells.
| zamadatix wrote:
| At the risk of replying to an overtly aggressive post on
| language bashing nonetheless - can you explain why rustups
| implementation of `curl https://sh.rustup.rs | sh` is worth
| mentioning? My understanding, from the 1,000 other times
| these flames start, is it's done properly and no more
| dangerous than any other way of running 3rd party binaries
| from a remote source.
|
| Regardless of any other thoughts on Rust folks I'll tip my
| hat to them for they definitely have made talking about
| security more common... one way or another apparently :).
| busterarm wrote:
| https://news.ycombinator.com/item?id=6650987
| https://blog.dijit.sh//don-t-pipe-curl-to-bash
| https://sysdig.com/blog/friends-dont-let-friends-curl-bash/
| https://www.seancassidy.me/dont-pipe-to-your-shell.html
| Macha wrote:
| You can of course install from your package manager
| [1][2][3][4]. If you're not going to install from your
| trusted source then I'm not sure curl https://... | bash is
| really worse than downloading and double clicking a
| msi/dmg/deb/rpm. Especially if you're not going to verify
| that or verify it using keys downloaded from the same https
| host.
|
| [1] Homebrew - https://github.com/Homebrew/homebrew-
| core/blob/HEAD/Formula/...
|
| [2] Arch - https://archlinux.org/packages/extra/x86_64/rust/
|
| [3] Ubuntu - https://packages.ubuntu.com/hirsute/rustc
|
| [4] Fedora - https://fedora.pkgs.org/34/fedora-x86_64/rust-1.
| 51.0-1.fc34....
| superkuh wrote:
| >You can of course install from your package manager
|
| Debian 11 was released a couple weeks ago and the rustc it
| ships with is already so out of date (7 months old, gasp!)
| software written for modern rust versions can't be compiled
| with it. And this isn't a Debian only problem.
| JoshTriplett wrote:
| The Rust packaged in Debian works to build Debian
| packages; for that purpose, it's fine. For other Rust
| work, I'm hoping that at some point Debian packages
| rustup, which would let people use Debian's secure trust
| chain to bootstrap into rustup's secure trust chain.
| busterarm wrote:
| For those that say that it can't be done, most of
| Haskell's ecosystem updates frequently in Arch.
| Macha wrote:
| Is this a Rust only problem? Decided to pick the most
| well known Go project, kubernetes, and the Go version
| (1.15) included in Debian 11 is too old to build the
| first kubernetes project in my search results, kubernetes
| client as it requires go 1.16, released february.
|
| I've certainly had issues with e.g. the Python or Node
| version being too outdated on Ubuntu, RHEL, CentOS etc.
| And when that happens, it's a bigger problem, as it's a
| runtime dependency, not just a build time one. It's the
| risk you sign up for picking a fixed release distro.
|
| Consequently, if you're developing cutting edge software
| in those languages, you're probably running nvm, your
| favourite virtualenv wrapper (poetry, pipenv, pip-tools),
| or letting your IDE download a runtime for you. And yes,
| these tools are full of curl | bash or curl | python
| install instructions.
| superkuh wrote:
| It is a rust dev cultural problem that will go away with
| time and general adoption. Right now almost all people
| writing in rust are the bleeding edge types that use the
| latest backwards incompatible features without caring.
| Combined with these new features being added every couple
| of months it is almost _required_ to use insecure rustc
| installation from outside your repos no matter the
| distro.
|
| Bash actually gets new, backwards incompatible, features
| pretty often too but you never have to run a bash script
| in a container or some third party interpreter. Bash devs
| simply care about having their software be able to run on
| setups more than a handful of months old.
| steveklabnik wrote:
| Our surveys show that most users use stable rust, with
| few using exclusively nightly.
|
| The issue here isn't about backwards compatibility, it's
| about _forward_ compatibility.
| hypothesis wrote:
| It appears that 1.16 is available in _testing_ as
| different package. Chance is high that you will be able
| to install it without much hassle, since they shipped
| current stable like a week or so ago.
|
| [1] https://packages.debian.org/bookworm/golang-1.16-go
| cpach wrote:
| Let's say you have a channel with 500 participants. Is there
| even any sane way to encrypt that channel?
| zamadatix wrote:
| 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-3
| 4/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.
| DenseComet wrote:
| Discord doesn't do E2E encryption, although those numbers
| for Signal and Whatsapp are pretty impressive.
| zamadatix wrote:
| 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.
| [deleted]
| adrhead wrote:
| Does it offer screen share features and customized stickers?
| Zomatree wrote:
| Both are planned features
| gravypod wrote:
| 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.
| Zomatree wrote:
| screen share wont be a feature for a while, but the hope is
| to capture game audio as well
| hammyhavoc wrote:
| Element (uses Matrix protocol) can capture Pipewire as of a
| few days ago.
| [deleted]
| option_greek wrote:
| Can the backend be used alone with a custom frontend (or any
| plans to convert backend to a SDK) ?
| nicoburns wrote:
| I believe it can. The protocol seems pretty thoroughly
| documented https://developers.revolt.chat/
| k_ wrote:
| 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
| Operyl wrote:
| As far as I can tell this isn't a discord client, but a full on
| server and client project that feels like Discord.
| k_ wrote:
| ... my bad I missed this entirely.
| xvilka wrote:
| 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.
| judge2020 wrote:
| 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...
| zorkian wrote:
| 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.
| xvilka wrote:
| It's not Rust, it's Electron...
| terafo wrote:
| Backend is in rust, but I'm disappointed too.
| poetaster wrote:
| 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.
| ejj28 wrote:
| 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.
| Jyaif wrote:
| 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.
| Felk wrote:
| I've heard that too. But I am using gmail and had no trouble
| registering.
___________________________________________________________________
(page generated 2021-09-06 23:00 UTC)