Really interesting. I do believe that this is the way to go. We already have a lot of communication platforms and apps that unfortunally can't communicate among them. I hope this should be the kickstart for a change in how communication apps are built, because communication doesn't means being able to communicate only with people who use the same app i use.
> I hope this should be the kickstart for a change in how communication apps are built
We've had this since 1988. Its name is IRC. Anyone could communicate on a protocol shared by any kind of app you wanted (not that I'm arguing that IRC is the gold standard of chat protocols necessarily - Matrix seems an improvement to me - but it was an open chat protocol before most of what we now think of as the internet existed). The fact commercial chat apps aren't interoperable is a decision they made to screw the user for corporate interests (i.e. force everyone who wants in on the network onto their app that they can track and advertise on), not because cross-app communication is a new or novel concept.
But yes, I believe this is the way to go. Unfortunately it will never be the way the mainstream goes because the ad money from the walled-garden apps funds their own marketing campaign to keep them in the forefront of users' minds, but both ecosystems will probably exist side by side in perpetuity (at least until the walled-garden lobbyists convince the government that open apps have to be outlawed because of children or terrorism or something).
The removal of cross app communication was a UX improvement for the average person. When Discord rolls out a new feature, you can trust it to work for everyone on day one. There is no querying available features for the other side, it just works. And you know it shows up how you imagine on the other side every time.
IRC spent most of the last decade rolling out the V3 spec which came with hard hitting features like logging in to accounts (SASL), away notifications, showing the time a message was sent rather than the time it was received by your client.
Still working on signing up for a new account on the todo list.
The glacial pace of open standards like IRC is the reason proprietary tools which can just get things done took over.
Being an open standard certainly slows down progress of IRC; but the main reason IMO is that barely anyone is paid to work on it.
This is were Element excels: they managed to get investors on board, allowing them to get hundreds people paid to work on Matrix, allowing Matrix to move fast. (Too fast if you ask me, as other clients and servers struggle to keep up with the flagship implementations; but that's another discussion.)
> Still working on signing up for a new account on the todo list.
Do users really care about those shiny new features? For me most of it was stupid stuff. Stickers, shaking windows..
The ability to turn that crap off is entirely why I'd want a different client.
And it's not really like you can have your feature available everywhere on day 1 really, even on a proprietary client. People often lag behind updating their apps on their devices.
I managed a fleet of 60k mobiles of which 40k byod (personally owned). and we often ran into issues with people not updating even included apps like chrome for years and we'd have to email them and even ban them when a serious vulnerability was found in the wild.
The stupid stuff is all important to someone. The stickers on telegram are the main reason furries use the platform over discord for example.
And mobile platforms auto update now so while it’s possible there could be an old version out, not much effort is put in to making it work. Telegram shows a basic text showing the message is not supported on your version and prompts you to update.
Even the stuff that is hardly a feature but more a UX prompt is important. Discord voice channels are not that much functionally different to traditional group calls, but that way they get used is dramatically different because the UX is.
Imagine if someone bridged discord to some other IM app and when someone joins a voice channel, it starts a group call on the other app which opens a ringer on that persons phone. The compatibility is close enough right, but that minor difference is enough to make users very upset.
Given that Discord and Telegram are the go-to chat clients for a huge number of people, I suspect shiny new features are important to them.
Even if they don't technically end up using them or really need them, it clearly helps get people using the platform.
I use Telegram because of the stickers and generally great UI experience on both mobile and desktop. Even though I know Signal or Matrix are a better choice from a privacy/security standpoint.
>When Discord rolls out a new feature, you can trust it to work for everyone on day one.
If they have a supported up-to-date browser, yeah...
>There is no querying available features for the other side
Right. If your browser isn't on the short list, it just isn't supported. Want to access discord from a tty over ssh? Go fuck yourself, not supported. Want to access it through your custom text-to-speech system? Go fuck yourself, not supported.
> Right. If your browser isn't on the short list, it just isn't supported. Want to access discord from a tty over ssh? Go fuck yourself, not supported. Want to access it through your custom text-to-speech system? Go fuck yourself, not supported.
Are you seriously mad that a company selling a commercial product doesn't support tty support for their browser app?
Indirectly, the issue is rather that they will ban you if you don't use their client, even if it comes at no cost to them (setting aside losing the ability to run spyware on your device). It doesn't need to be a tty client, it could be a client for a older phone, a native client for GNOME, a client with more features and extensibility, or whatever. They do not know best what every person's wants or needs are. And until this issue is overcome (which I don't expect it to be), the service is unfit for general usage.
> setting aside losing the ability to run spyware on your device
I think you're underestimating how lucrative spyware is.
Remember, Google is basically funded entirely by spyware and 'spyservices'. Data is the new gold. Unfortunately it's your data and someone else's gold :(
I don't know why you're bringing my emotions into it.
I don't think Discord should exist, and the fact that it's a commercial product shaped by the economic self-interest of one company is the reason it's so bad.
You talk about it like the commercial motives actually justify the negative properties. "Someone's making money! How can you object??"
Could you please stop posting unsubstantive and/or flamebait comments to HN? You've been doing it a lot lately, in several threads, including crossing into personal attack. We ban accounts that do that kind of thing because it's not what this site is for, and it destroys what it is for.
There are plenty of commercial chat apps (particularly ones embedded in other applications) that use IRC under the hood. You don't always know that this has happened, though.
In fact, almost every non-IRC chat app around starts out as some variant of "trying to improve on drawback X of IRC." For a long time, IRC was the default choice and you only did something different if you wanted to fix one of the problems with IRC.
But IRC isn’t meant to be a global system, right? There aren’t even usernames. Connecting even a few servers together creates netsplit problems and traffic spikes. I’d say XMPP is the real alternative.
But IRC is also looking back on three decades of completely separate networks without even the tiniest bridge and the number of networks that have grown big enough that users forget that other irc networks exist has been been increasing ever since. Yes, they do share roughly the same protocol, yes, clients can be connected to more than one of the networks at the same time, yes, most (all?) of the big networks are federated within themselves on the server side. IRC itself is an example of existing side by side.
I really don't see the point. We have lots of communication platforms because they largely have different feature sets, different strengths, weaknesses, etc.
All the compatibility shims and bridges between platforms have been largely disappointing. You reduce the experience to a lowest common denominator of features which is the worst of all worlds. The Matrix paid subscription bridges are the best implementation of this I have ever used but I still frequently check Telegram after sending from matrix because I don't have faith that my message was accurately represented on the other side. Plain text largely works fine but you have no idea if a link embed worked, if your sticker shows up properly. Even for an image, when you send in matrix, it often shows as an uncompressed image on Telegram which is sometimes what you want but usually not. But since matrix has no concept of compressed vs uncompressed images you don't get the UI to select like you do on the real Telegram client.
This is fine - different chat clients can have their own features and UXs. Telegram can have two ways of uploading an image - compressed and uncompressed. Matrix can have one. WhatsApp can have storefronts attached to business accounts, other chat providers may implement it differently. Each chat provider can build features that fit their customer demography.
But the a common protocol of communication (or even bridges) can help people use any chat app they wish to. If your chat provider does not provide the feature you want then simply switch the chat client and take your chat history with you (in an ideal world).
The problem is the downsides of poor compatibility are far greater than having to use multiple apps.
I don’t have trust in the matrix bridge to accurately represent my messages so I don’t like to use it because several times I have sent something and it has not come out right on the other side.
It’s like the emoji fragmentation issue on a much bigger scale. Chat is very complex and social/communication cues are very susceptible to being affected. I once sent someone a YouTube video with a timestamp and found out that ms teams did not load the video at the timestamp if clicking the thumbnail. I now kill the embed when sending a timestamped video because this caused a lot of confusion for the other person. Stuff like this happens much more for bridged communication where you don’t even have access to the UI to see how it worked or disable embeds
I count myself as a huge fan of matrix - both the protocol as well as the federation concept - and even i feel that bridges are a compromise...but i don't blame the matrix folks. In fact, bridges are the best compromise that i can think of in an ecosystem of outwardly hostile (or at least not cooperative) other chat services. If many chat systems used a singular messaging protocol - much like email uses the same underlying protocols - then i would imagine different systems and client/apps could differentiate on features, performance, price, stability, etc...Not so different from email providers might compete today. In other words, i don't think anyone *wants* bridges...its merely an artifact of others not cooperating. If more systems like rocket chat came out and began to leverage a universal protocol, then everyone wins - the app owners/designers, the app users, etc.
This is so tedious - it’s like having subversion users pop up every time someone mentions git and bemoaning how git should have just been built on svn. Or BSD fans complaining bitterly about Linus wasting time writing his own kernel when he could have just used 4.3BSD or Minix or whatever. If the same amount of effort went into improving XMPP as goes into complaining about Matrix, then XMPP would be in a much better state.
I was replying to someone who said everyone should switch to Matrix, and calling "uncooperative" anyone who doesn't, as if Matrix was somehow objectively superior to every other IM protocol. I agree it is better than most (maybe even XMPP), but this is a subjective matter, and protocols who don't switch to Matrix like Gitter or Rocket.Chat did do not deserve to be called uncooperative.
> If the same amount of effort went into improving XMPP as goes into complaining about Matrix, then XMPP would be in a much better state.
It goes both ways. I don't know about XMPP, but IRC would be in a better state if people who complain about IRC would spend as much effort checking out newer IRC software (which already exists!) instead of using legacy stuff, then throwing the baby out with the bathwater.
To clarify, my comment about non-cooperative chat systems was in reference to MS Teams, Slack, etc. I didn't bring up XMPP. XMPP *might have* been an ok universal protocol to standardize on, but many players (like Google et al) took things in a non-cooperative direction. Thereby somewhat killing its benefit of federation. Also, as much of a fan boy that i am about matrix, i acknowledge it may not be the most perfect, but i feel it is pretty damn awesome from a technology perspective...But even more awesome, are the people and community behind it who - more than any other effort that i'm familar with - actually listen to the rest of the members of the community, and try to find some accord for what is best for all. Finally, i could be wrong, but some of the founders of the matrix protocol (and community) actually loved and came from the IRC world. Obviously, you have a right to your own opinion. :-)
That's pretty cool, but I wish they'd deal with all of their other problems first. I ran Rocket.Chat for over a year and I encountered more errors than any other program I've hosted. It culminated in one problem causing a database corruption, which was the final straw.
Slightly related, but Rocket Chat is one of the most important projects using the Meteor framework. How's this going in 2022? Is Meteor still relevant when compared to new players like AWS Amplify and Remix?
Yes! I’ve built startup with Meteor in 2014-2017 and came back to it this year for my current job and I want to say it is still the best. It’s the only thing that works out of the box. I can get designers and PMs running it locally in minutes and have them help make things pretty in css/html etc
Amplify: I’ve worked with Amplify but it’s not production ready, they change and break things and you have to intimately know cloudformation. Developers used to wait for me to fix the problems. It was taking a lot of time from me to keep things reproducible across all dev environments. You don’t have time for this stuff when you run a startup and you have to prove business is viable.
Have you faced serious scalability issues with it? In my shallow research, a lot of devs complain about Meteor's performance, but it might be misuse or a misunderstanding of how the platform works.
There are number of areas where scalability issues can come up. Most of them are usually due to not well optimized database queries. There was time when real-time data subscriptions were too slow for me with Mongo but now you can seamlessly add Redis for that and bottleneck goes away.
Any particular area you are concerned about?
So I can't speak for Rocket.Chat, but I can say the hairiest stuff we deal with for Sandstorm.io is MongoDB-related at this point. It'd be really nice to use a different database at this point I think.
(I think nearly every database should probably be SQLite.)
Also i think big chat apps will be surprised how few of their users switch. I still see open source projects regularly moving from rocket.chat to discord for the UI.
It just doesn't have the important features (impromptu voice chats, mainly). Same deal with Element. Maybe soon™, but until then I don't find it fit for all-round collaboration.
I think Rocket Chat started development after the Slack craze and tried to fill the niche of being an open source version of the latter. Since I last used it, it seems like a good alternative for on-premise, open source Slack-like, still.
Now that we have Matrix, I'm not sure where it's place is but I'm sure some orgs are fine using it for internal communications without having to pay Slack for your history/premium features?
It has administration features accessible in the UI that no Matrix client does. The capability to edit other people's posts as an administrator without having to go into the database is very useful for when somebody can't update something important, like an announcement. Generally, it's far more customizable out of the box, without having to rewrite parts of it, and many features taken for granted in it are not supported by any Matrix client so far.
The downside is that it is, and always has been, incredibly buggy and prone to total failures.
A few years ago when we needed an on-prem chat tool (around the time Atlassian killed HipChat), rocket.chat had the benefit of being easy to set up. For Matrix you needed a Synapse (Dendrite wasn't ready back then) backend, a Vector frontend, some arcane backend for authentication, and you had to connect everything together by hand, while rocket.chat had a docker-compose file you could add Keycloak to and spin everything up with a single command.
I just wish that Rocket.Chat were actually fully open source, instead of open core that hides features like SSO, read receipts, and canned responses in closed-source modules.
Or you can see it the other way around: if it wasn't for the money those closed-source modules make for them (presumably?), there might be no Rocket.Chat at all, open source or not.
I just don't know if that's what sustains the people working on the oss parts of the project, so it was all a big supposition on my side.
Like, if someone sees a business opportunity for selling proprietary modules, to the point of hiring people, making a team, and creating an oss project to support it all, then without those commercial parts the open pieces of that project wouldn't even have been written to begin with, right?
Modern hosting platforms have made this less viable. AWS, Azure, and GCP will just integrate this as a one click service at a cheaper price than the actual development company can afford and drain all of the profits out.
AGPL does nothing to help here. AGPL simply requires you release the source for any changes. AWS is still free to host and sell the software without contributing any funds back to the project.
It’s not closed source but it’s also rejected by the major open source institutions and violates the OSI definition of open source which is what most people based off of.
Offtopic: is there an on-prem alternative for Discord? Is there not a demand for SSO enabled, self hosted, open source communications app with persistent voice chat channels with pushtotalk?
Not really, they’re just speaking matrix natively. In theory this will help Beeper, since they won’t have to maintain a Rocket.chat bridge. In practice, I’ve tried to sign up to Beeper multiple times, but they never get back to me.
Okay so it wasn’t just me. I was confused too. I had to reply saying I heard I can start using it soon if I pay. Then I think I got a Stripe link or a landing page link that went to Stripe.
No, but that's interesting. I manually setup Docker containers for Mautrix bridges alongside my Docker container for Synapse. Thinking I might switch to this though for less maintenance, that's a very nice find!
The ansible workbook is great (I use it for my matrix homeserver). I've bridged multiple chat apps into matrix and things just work.
But Beeper is a better client for this usecase. It has better UX for a all-in-one chat app - single button to turn bridges ON and OFF, a great client with filters, search (in all chats), etc. So unless you want run your own servers, beeper is a better choice (ems[1] is also an option)
Both beeper/element get laggy if you have way too many chat's. Wish Beeper would let me have a blacklist/whitelist option so i could only use it for a subset of my more actively used chats, vs trying to connect to absolutely everything.
EDIT: Oops, i should have also clarified that the free account does *NOT* seem to include bridges...but the paid accounts do for an additional nominal cost (honestly seems a fair price): https://element.io/personal-plans
