I'm pleasantly surprised! They took the route of "promising but underdeveloped technology" rather than settling for a well-developed solution that compromises their principles (which, frankly, I wouldn't have faulted them for; at the end of the day you still have to get work done). With luck maybe we'll see Mozilla contribute to Matrix? There is, after all, an implementation written in Rust: https://github.com/ruma
I actually interviewed the author in August for our Rust podcast, on which he says he's waiting for async to mature before progressing further: https://rustacean-station.org/episode/001-ruma/
Thanks! Also, while we're here, let me advertise that this is not just "my" podcast, it's a community-based podcast that accepts audio files from anyone who wants to make any Rust-related podcast content but who doesn't want to go through the trouble of setting up a website, file hosting solution, podcast index integration, and so on. Contributions accepted. :) https://github.com/rustacean-station/rustacean-station.org/
Of our seven episodes only one hasn't been a product of me or Jon: an interview with Armin Ronacher about using Rust in production (https://rustacean-station.org/episode/004-rust-in-production...). Though we're about to publish our second externally-produced episode tonight, an interview with the creator of static site generator named Zola (née Gutenberg).
Plenty of people say tell us they're going to contribute, but you know how life gets in the way. :) We're not bothered by having a low-volume or irregular release schedule, this is just a fun side project for us.
It is a bit hard to follow their project since they have split it up in so many tiny repos. I personally prefer when a set of closely related crates are developed in one mono repo.
For rust it's sometimes useful to split it like that, because it makes it easy to publish small subsets of your project on cargo. Say you develop a custom datastructure, or an extension on Streams.
The same applies to other languages to some degree, but crates/cargo just makes it very painless to grab crates that are on a seperate git.
But Cargo supports having multiple crates in the same git repo. Many projects do this like regex (regex and regex-syntax are in the same repo) and openssl (openssl, openssl-sys, openssl-errors). Maybe I am missing something but it seems very easy to handle multiple closely related crates in the same repo.
What makes this possible is Cargo's "workspace" feature, which is relatively new enough that it's not hard to imagine that some older projects may simply predate it.
Would something like git subtree help here? Allow people to continue working with their individual repos but present a unified view for outsiders to follow along? We could automate this, right?
Cargo workspaces are more of an optimization in that they let all the crates in your project share the same output directory[0], so built dependencies can be shared among every crate, as opposed to each crate needing to (re)build all of its dependencies independently.
This helps to reduce compile times when working on projects where you frequently switch between crates.
The latest status seems to be https://github.com/ruma/ruma/issues/189#issuecomment-5539555... from a month ago. It looks like he is working on the client while he waits for Rust web server frameworks to adopt the recently-released async-await language features.
So after testing matrix and riot with friends for a couple of months, there're still a ton of work to be done. We all used the most common setup - matrix.org homeserver, riot and riotX as apps. (Also please don't point me to dev version, I am only considering what's in stable.) Random stuff not in particular order:
1a) e2e is a choice that affects experience in riot, a lot - you can't use search, you don't see recent images/files ...
1b) you have to verify each others devices, N:M; although they're working on a change
2) I hoped that riotX will be a lot better at the end of this year, but there're still lots of bugs, messages get stuck at the bottom, mobile - mobile e2e can't be decrypted sometimes, you have to have another device online; and you can't even zoom in or save an image that's sent to you which is infuriating
3) matrix.org homeserver performance, although a lot better now is still sometimes utterly slow
4) riot is still missing crucial functions like copy entire message, online status, jump to date, and lacking any good notification system(the current one is really simple/stupid) and you can't even enable notifications without sound e.g.
4) also it's still lacking custom emote support although many ppl asked, there's no option to pin/save messages...
1a/1b and 2 is where all our work is going currently. We're trying to get E2E on by default in Jan, and likewise exit beta for RiotX/Android around the same time. We're going as fast as we can.
3: Matrix.org homeserver performance should be absolutely fine now. Delays when doing things like joining big rooms are unrelated to the hardware, but perf optimisations we need to do to synapse in general. They're on the radar.
4: This is literally the first time i've heard an ask for 'copy entire message'. The other features exist in labs, and yes, we need to fix notifs and add custom emoji. "Many people asking" doesn't magically produce features unfortunately, especially when we are battling points 1 & 2. Contributions help though. Thanks for testing though.
After spending several months convincing a few friends to use Riot, the ongoing fiasco with E2E has caused all of them to leave within a couple of days. Obviously they're unlikely to ever come back.
It's a real shame. These are technical people who don't particularly mind verifying a key by hand. In fact I personally even prefer it.
The problem is not only that certain things are not done automatically, but that the UI is designed to make it difficult to do them even manually!
E.g., I have one device 'foo' which you already trust. I add a new device 'bar'. Why on earth would you want to verify its key manually when I could just send you the new key from 'foo' which you already trust?
Even worse, the key for 'bar' is not straightforwardly available anywhere in the UI on device 'foo'. It should be easily viewable in the right hand pane where the list of devices is, but it's not. The only way to get the device ID and key is to send a message from 'bar' to 'foo' and view the details of the message. Why?
> E.g., I have one device 'foo' which you already trust. I add a new device 'bar'. Why on earth would you want to verify its key manually when I could just send you the new key from 'foo' which you already trust?
This particular issue is being worked on right now in Riot, and should be fixed early in the new year.
Thank you for your quick and patient answers to my perhaps too demanding questions.
Cross-signing is obviously better, no question about that. However this simple UI change would be at least 95% as good, and certainly good enough to have prevented my friends from giving up on Riot.
I hope that is at least somewhat constructive. Thank you for your work.
I recognize this is a common attitude, but it makes no sense to me.
Some software you tried today isn't designed in a way you prefer, so you go back to using something else. Okay. Makes sense.
But to declare the whole project forever hopeless as if it can never be improved upon because the snapshot of your first experience with it was negative is truly irrational.
Keep in mind the only reason they tried the software is that I regularly pressured to do so for months, before they finally caved.
After all that they quickly come to realize that something simple like adding a new device is a massive pain in the ass.
It's not that they declare the whole project as forever hopeless, it's that they invested time and effort into trying it already and it turned out (for them) to be a waste.
It's just a bad taste left in the mouth. In order for them to try it again, they not only have to overcome their natural laziness/time constraints, but also the rather unpleasant memory of the last time.
The same thing happened to me, but I am thinking of having another go and just discouraging the use of E2EE. (The community I’m thinking of is currently on Slack, so there would be no marginal loss of privacy.) Have you considered that, or is your group already using another E2EE platform that isn’t a massive pain in the ass? I’ve yet to discover one myself.
I think it's less that people assume that it can never be improved and more that they find something else that is "good enough" and they won't leave that ecosystem until it stops being good enough. Generally speaking, I've found others (and myself, at times) don't re-evaluate their options until there's a need for them to upgrade or its brought to their attention by someone else.
On 4, yes, please support "copy entire message". It already works if the entire message is a code block, and it's unfortunate there is no alternative when it is not.
I've often encountered this when I paste one of my Markdown notes from my knowledge base into the chat in order for it to be rendered so that the other participants may read it in a visually appealing form. But then I decide that I also want to give this same note to someone else in another room, but there's no way to copy the message and simply paste it at the new destination.
Conversely, sometimes I write a worthwhile Markdown note directly in Riot and I'd like to save it in my notes system, but it's hard since there is no "copy entire message" button.
ad 1a - E2E by default - meaning you'll flip the switch once there's a feature parity with non encypted rooms in riot?
ad 3 - from my testing it's fine for about 98% of the time, but sometimes it takes ~3-8seconds to send a message (sitting on 300 or 500Mbps wired connection), in e2e direct message room
ad 4 - @ copy entire message - interesting, i needed it just recenly so i went into the submenu and there's show source, show decrypted source (which is cool but maybe something that should probably be enabled in via a toggle in the options menu) and quote but no message copy (and using quote messes up markdown formatting...)
ad many people asking - i totally understand that, however, this could be used as a roadmap for shipping features. And since I don't write code (read javascript) I am trying to contribute with testing/reporting bugs (so although not obvious from my OP, my testing continues as is suffering of my friends ;) )
1a: Yes. the second we have parity, we'll start turning it on by default for private rooms. We'll probably start with DMs, and we'll probably do a fairly soft roll-out to sneak in some final testing. Current status is that we have E2E Search working (github.com/matrix-org/seshat); we have E2E cross-signing almost done (https://dashboard.lant.uk/#/plan?epic=vector-im/user-stories... we have eyes on the remaining causes of undecryptable messages and are working through them. We're aiming for Jan.
3: Interesting. It could be a very temporary CPU saturation on the Matrix.org CPU master. We're working on sharding the master per-room to mitigate this, but it's going to be a few months to land.
2) could be partially solved by backing up all of your keys from all devices. After that, non-decryptable messages decreased about 95%.
Ironically, backing up your keys is done by recovering your keys from a backup – Settings → Cryptography Keys Management → Encrypted Messages Recovery → Restore from backup.
(Web version: Settings → Security and Privacy → Key Backup → Restore from Backup)
You can verify that you set it up properly by checking if the backups are signed by all your currently used devices (and possibly old ones, too).
3) can be mitigated by using workers. You'll need a beefy server, but message transfer and synchronisation will be super fast.
The other things you mentioned are works in progress and I think the progress is outlined pretty transparently on Github, even if some people disagree with how the Matrix team is handling things.
This is really good news. I have only one question for Mozilla: why choose a solution whose hallmark is decentralization and the libre model- only to become a customer of a centralized host (modular.im). Why can't Mozilla actually federate? That's a step backward from your IRCd in my opinion.
I hope Mozilla gets onboard with everyone else running their own Synapse, hacks on it, and pay their dues with patches, rather than with their cash.
They are using a hosted provider, run by the makers of Matrix themselves. This lets them get the benefits of federation while making the hosting someone else's problem.
Of course, we all want to see Mozilla bootstrap their own Matrix instance, but maybe the cost/benefit equation worked out differently for them than we would have expected. I can imagine this lets them replace IRC with a better solution faster while still supporting the development of an open standard by becoming a client of the company that's developing it.
Does this forebode something more sinister? I hope not...
Is Mozilla an example for the next major adopter of Matrix or are they not? If they are, and everyone else signs up for modular.im as well: at what point does this ship of Theseus called Federation only exist inside a bottle?
WordPress exists as as OSS even though WordPress.com exists. And there's a clear migration path from being hosted by WordPress.com to running your own private WordPress.org instance (or vice-versa), that can be taken at any time if someone's needs change. I don't see what's so different here.
If it were me, I would want to a) support the existing players in the ecosystem and b) do the migration piecemeal if possible.
Working with a third party lets them start standing up rooms immediately, and get their people using the new standard without being blocked on a long process of setting up their own infra. It’s federated. They can easily migrate onto their own hardware at a later date.
It also injects money into the community they are trying to support. Even if they did start running all of their own instances, I would hope they keep a support contract with Modular for that reason.
Paying Modular + using Matrix widely immediately + beginning work on their own infrastructure is a strictly bigger shot in the arm for Matrix than just putting a couple devs on pre-planning and prototyping infra would be.
If Mozilla will use their own ___domain name they will be free to move their federated Matrix instance wherever they want. Modular.im will only provide the hosting expertise. I expect that in the future self-hosting your own Matrix server instance will become much easier.
I don’t have experience with running Synapse but it looks like a beast. Dendrite and Ruma look very promising though; can’t wait to have a lightweight home-server ready for prime-time.
Assuming the purpose of the messaging system selected is to help Mozilla's community work together on Mozilla projects, what benefit of 'decentralization' do you think would improve their ability to work together effectively?
I encourage reading the earlier posts on HN from exple.tive.org about this over the past year, as I think they may speak more to the reasoning you’re interested in discussing.
Well, sure it's possible. They don't need to prove it.
But I don't think Mozilla has such a large userbase that it would make any difference.
I like the publicity angle but maybe that's for the future. If Mozilla validates the transition and wants to get more involved with Matrix.org then it'd make sense to own and manage their own stuff.
I like that they are being cautious and not jumping with both feet in.
At a technical level, the Mozilla homeserver will be as decentralised as any other server in Matrix: i.e. entirely independent, and federating with the rest of the Matrix as normal.
At a legal level, it's true that the server will be admined by New Vector via Modular.im - but this is basically Mozilla just outsourcing their sysadmin to Modular, while also helping fund Matrix development (given that Modular subscriptions are used to fund development on Synapse and Matrix in general).
Matrix servers are kinda a pain in the ass to get up-and-running and to manage versus, say, XMPP or IRC. Especially if you can't get away with just running someone else's pre-built docker images for it, or whatever.
I've administered both XMPP and Matrix servers and I must say I don't see either as much of a hassle. Synapse had some growing pains but is pretty painless for me these days.
Not true in my experience. Synapse is just as easy to stand up as Prosody, and in fact requires making less choices since you don't have to pick which modules to enable and stuff.
Can you tell me more about the modular.im behaviour/policy towards federation? Is it explicitly turned off?
Also, IRC has federation too by having multiple servers in a network. IIRC Mozilla hadn't allowed you to do this for moznet did they? So how is this different?
Nice, given how the discussions were going some months ago I was worried that they would pick some closed source solution like Discord or Slack. I have not used Matrix so I do not know how good it is, but I do not like the lock-in of Discord and Slack.
Agreed, this is a huge relief. I was getting quite worried that Mozilla would go to Discord, like Rust and other projects have done. I don't know anything about Matrix, but I know it's free, and if it has Mozilla's endorsement, now I'm actually curious to try it... maybe even via an IRC bridge!
FYI #rust-beginners is on discord, but many of the teams have transitioned to Zulip because it has threads. I'd love if Zulip was OSS, but at least it's a highly innovative company that's improved a lot on the UX of IRC (far beyond not needing to setup a bouncer).
The mismatch between Discord's targeted audience of gamers can get funny at times. One rust dev has had their status we to "playing systemd" for days.
Edit: How did I miss that Zulip is open source??? Thank you to the commentators who pointed this out, you made my day :)
Edit2: Just learned what I said about rust decision-making was totally wrong. Thanks to Rob Pike in the other thread for his detailed comments.
I wouldn't describe Zulip as coming from the IRC tradition -- it was built by MIT students as an improvement on MIT's Zephyr. There's a split between line-at-a-time messaging like IRC or Slack, and paragraphs-at-a-time messaging with per-message channels like Zephyr, Gale, and now Zulip.
I said "paragraphs-at-a-time", not "paragraph-at-a-time". You can't type paragraphs at a time on IRC because a single message can't contain newlines.
But even then, paragraph-at-a-time is hard on IRC because there's a max line length that's surprisingly short (and usually just truncates the rest of your message once you exceed it!), and just because you'd stand out as being the person writing much more than everyone else and being slow to reply. IRC simply isn't a medium designed for carefully considered thought like that.
I know I'm not supposed to talk about voting, but I'm going to anyway. Why are people upvoting me? The comment is completely useless because almost everything in it is wrong.
I haven't managed to properly use Matrix myself, but I am part of a number of Gitter rooms that includes people using the Matrix bridge. I certainly wouldn't call that bridge "nice": all their messages are posted by a single user called matrixbot, that simply prefixes it message by their Matrix username in backticks. I'm not sure if the people in the room who aren't aware of Matrix understand that that's what's going on.
I understand why it works this way and I wouldn't know how to do it better; it was more of a general critique of the bridging approach, I guess, and hence a reluctance from my side to call it nice.
The official successor to Synapse homeserver is Dendrite written in Go (https://github.com/matrix-org/dendrite). There is homeserver project in Rust called Ruma (https://github.com/ruma/ruma). Ruma was waiting for async/await to stabilize. But it doesn't seem to have much activity even after that.
It looks like Ruma was waiting for an async web framework to emerge, and the web frameworks were waiting on hyper to upgrade, and hyper was waiting on h2 to upgrade, and h2 was waiting on http to upgrade, and http was waiting on bytes to upgrade, and everyone was waiting on tokio to upgrade. In the six weeks since async await has stabilized, the web framework that my company uses has only just managed to upgrade to stable async/await last week. I wouldn't fault Ruma for waiting for other frameworks to upgrade before making a choice.
No problem. :) I just don't want potential contributors to write off Ruma as something worth looking at, especially since with this announcement it ought to be be more relevant than ever. And having multiple independent implementations of a federated protocol is very important to proving out the specification (the Ruma author has already filed several bugs against the spec as a result of implementing it).
There are quite a lot of Synapses out there right now, and Synapse's featureset is pretty mature. Given we have pretty high profile people running Synapse (e.g. all of the French government) we have no choice but to invest the time to polish it and make it more efficient and stable. In an ideal world we'd have paused on Synapse ages ago and focused purely on a next-gen server, but we can't leave Synapse users in the lurch. Dendrite will be getting some attention in the coming months though, but not as a direct Synapse-replacement, but more of a playground for more experimental stuff.
Ruma isn't written by the core matrix.org team, and has its own community. Dendrite is much further along, so makes sense for us to hack on the projects we created :)
New Vector (https://www.vector.im/) is hiring more designers to come work fulltime on Riot’s UI and UX as they shift Riot’s focus from being developer-led to design-led.
Seriously, I feel like it’s such an indictment on native app tool development that we have a bazillion new electron apps written by ppl all the time for weekend projects yet almost no one spitting out native apps to interface with services.
It’s clearly in demand (if a bit of a niche kind of demand)
You can write a pretty and functional Electron app in a weekend.
To implement the same level of functionality and prettiness in a native app toolkit like Qt is at least a month of work.
It's the same story as Python versus C, or C versus Assembly.
When C was introduced, the old-timers had the same complains like we do today: why would you program in such a slow and inefficient language? Real programmers (TM) use Assembly, C is for lazy people who don't want to learn and who don't care about the awful resource wasting. 3 KB for a hello world? That's an absolutely ridiculous level of bloat.
> You can write a pretty and functional Electron app in a weekend.
You can also do so in Qt and other frameworks.
The fact that you are proficient in web frameworks does not mean other tools are less productive.
In fact, being proficient in modern web dev, including HTML, CSS, JS, TS, React, etc. takes way longer than learning something like Qt. And if you go to easier frameworks like Delphi or VB6, you would be amazed at the productivity speed.
"In fact, being proficient in modern web dev, including HTML, CSS, JS, TS, React, etc. takes way longer than learning something like Qt."
But there are already a ton of web developers who already know those web development technologies, but don't know Qt. So it would be extra effort for them to learn Qt. Much easier to just use React.
The same thing goes for why there so many academics write Java apps for their proof-of-concept research work. That's what they're taught in school and for many that's all they know.
Curiously, Python was able to make huge inroads in to the academic community, but that was largely due to having a killer app (Jupyter notebooks) along with having a bunch of desirable tools for scientific computing, data processing, and visualization. I'm not sure if there's anything as compelling in the Qt ecosystem that would be as attractive to web developers who already know HTML, Javascript, React, etc.
I still find WinForms to be a very productive and pleasant way to write native Windows apps, even quick weekend MVP’s.
Yes, it’s Windows only, but if you really want tight efficient native apps then you’ll want a custom built app for each platform anyway, with a nice standardized API for them to connect to. So I don’t see the Windows platform lock-in as a downside if the goal is good native performance.
If Electron vs Qt/C++ were the only two choices that would be true. In reality there are lots of ways to write cross platform native apps without using C or C++: Gtk + scripting language of your choice (even Javascript); Tcl/Tk; WxWindows; Mono/C#; lots of Java options; Delphi/Lazarus.
> To implement the same level of functionality and prettiness in a native app toolkit like Qt is at least a month of work.
Qt is not native in the way that matters: using platform widgets. In fact, the choice of language really doesn't matter if you're using them right: if you have a platform-to-language bridge and it works, generally the end product is not too bad.
This is not at all the same thing. Programs written in C aren't inherently low-quality, everything abusing the web stack as an application platform – including Electron – is.
If you had said low performance, you would have had a point. Even then, someone else could say that programs based on Electron at least aren't inherently insecure, like programs written in C are.
Native development on OSX and iOS both kind of suck unless you completely embrace objective C and coaca. I think that’s what’s turned so many people off to it.
It’s comparatively easy to write complex portable applications with tk (or even just strait win32 and whichever X11 widget toolkit is your favorite.)
Well yeah that gives you an OS X app and you get to reimplement it completely from scratch for all the other platforms. So it’s exactly the same problem as objective C (except you can at least compile objective C on other platforms you just don’t get the GUI stuff.)
Has anyone had experience with both Matrix and Mattermost? What are the main differences between the two?
Apropos of nothing, currently I am running:
* Signal
* Wife
* Family
* Google Hangouts (web)
* Friends and ex-coworkers
* Slack
* Vendor A
* Vendor B
* Team C
* Team D
* Keybase
* Some friends
* SMS
* My Stepdaughter
* Skype
* Coworkers too stubborn to open Mattermost or change what they do
* Mattermost
* Coworkers
* Various teams and groups
* Remote Desktop
* Microsoft Teams
* My team
* Client coworkers
* Other teams at client
* Microsoft Skype for Business
* Chats from people who don't use MS Teams
* Meetings
* Gitter
* Spacemacs chat
* IRC (web)
* Various random channels
Out of all of those, only SMS isn't on my macbook, and I'm sure I could put it on there if I wanted to.
Mattermost is currently a better UX with a more stable codebase, but I suspect that the Matrix/Riot federated model will one day overtake Mattermost.
Personally I use Mattermost at work and Matrix/Riot for personal chat. If Matrix/Riot began to overtake Mattermost in terms of UX, we would probably replace Mattermost with Matrix/Riot at work.
You've just described my nightmare scenario. I'm currently experiencing "Messaging app fatigue" and I'm not using even a quarter of the apps that you are.
I use SMS, Slack, Discord, Skype, IRC, Google Hangouts, Facebook Messenger and WhatsApp, so you have me beat by 3. :) It would be amazing of Matrix and its bridges got good enough so I could reduce this number a bit.
the first image is Riot circa 2015 (back when it was called Vector). You can run it if you really want from https://riots.im.
Tchap meanwhile is opensource at https://github.com/dinsic-pim and there are unofficial builds which let you use it as a general purpose Matrix client.
However, we're busy improving Riot's UX in general to make it easier to grip - on Mobile that ends up being a rewrite (RiotX), on Web we're iterating incrementally.
Not really: anyone can run an IRC bridge, and many people do. The #mozilla_#wherever:matrix.org namespace is the preexisting moznet bridge run by Matrix.org (not Riot.im), but anyone with their own server could also run their own bridge, much like they could run their own bouncer today. There is then additional decentralisation from the fact that the room history is replicated throughout all the participating Matrix servers.
Anyone can, few do. At least in terms of what I see on the 20 IRC networks I'm connected to. The only one where people actually tend to run their own Matrix servers is on OFTC with the Freedombox (https://wiki.debian.org/FreedomBox) people. On Freenode I don't think I have ever seen someone connect from a Matrix server that wasn't riot.im since the creation of the Matrix protocol.
How would you even know, though? When running personal bridges I just have them auth as my normal user account like a bouncer. Or are you looking at CTCP versions?
The 'Real Name' field shows where they're proxying in from. Like the normal riot.im "@username:matrix.org" or self-hosted "@username:theirserver.address.tld". Is this an option that isn't the default for most matrix bridges/clients/whatever?
I guess if it doesn't show in their realname field I wouldn't see it. But I imagine since the defaults seems to be what I described above the amount of users that turned that off will be fairly small and irrelevant.
And them Matrix will happily spam IRC with links to comments instead of the comments themselves.
Matrix is toxic to IRC.
Any widely used IRC channel that has matrix joined to it would do well to ban matrix if they want the channel to pratically continue to exist as a IRC channel.
The default heuristic is that if someone sends a message on Matrix which is longer than 3 lines, it gets sent as a pastebin to IRC. This feels significantly better than spamming an N-line paste into IRC, which could be seen as even more toxic.
Open to suggestions on how to improve it, though...
I'm curious, what's wrong with IRC? Is it too old? Too difficult to monitor and moderate? Too easy to spam? I don't understand.
I've never really understood why mozilla chose their own servers and not freenode. I've never really grasped the whole history of enet vs freenode either.
Mozilla has said they thought it was too difficult to monitor and moderate. Could that have been solved by moving to Freenode? Probably, but there are other issues with IRC.
Having to run your own IRC bouncer increases the barrier of entry, as does nickserv based auth. Modern people also expect to be able to seamlessly post images, large code examples, files, etc. Some people also want support for threaded conversations. None of this is offered by the typical IRC setup which Mozilla probably thinks that it scares away users. I do not think Matrix solves all of these yet, but it solves some of them.
How is the feature parity with newer alternatives? Can I share my screen with someone easily? Can I post a screenshot? Can I be sure every client shows the screenshot properly? Will it handle an animated screenshot?
I wouldn’t want to use one tool for typing text and another for calling a third for sharing files and a fourth for sharing a screen and so on.
For example: Sharing an image as a link isn’t really an acceptable UX these days I think.
A lot of younger developers consider IRC limited and crusty. They are more easily attracted to platforms they've grown used to that behave similar to discord, teams, and slack.
I'm unaware of a hacker news matrix channel (perhaps others can enlighten me), but joining the Matrix HQ channel (https://riot.im/app/#/room/#matrix:matrix.org) is a good place to learn more about Matrix.
There's https://riot.im/app/#/room/#hn:matrix.org, but it's sadly very dead and not bridged anywhere useful. Is there actually a good chat community for HN anywhere?
Any one knows the progress of dendrite? Have not used matrix/riot for a while. It was too heavy to run awhile back. Hopefully they make the client and server more light weight.
Are you guys planning "private communities" usecases ?
When I last evaluated Riot, it was vehemently public...so Slack/Mattermost like usecases were very hard to do.
Ideally a private community should be possible, where users invited to that community have access to all channels. however within the community, I should have private channels restricted to only few invited users.
I was told that the only possible way to do this was make all channels of a community private ..and when adding a new user, you should explicitly invite to every single one of the channels. This is not viable for an org.
I really hope this means more development and focus on building great mobile apps for Matrix. For the past four months the Riot Android app has had this bug where login state expires after a day and the app gets stuck in an infinite loop trying to refresh the token. Supposedly a fix was merged [1], but after four months of not being able to use Riot (and thus Matrix) my friend group has fallen back to Discord.
I don't think this issue is related to soft logout, which is what happens when the user logs out of a device remotely. The issue I was running into was that the app, after 24 hours of being logged in, would get stuck in an initialization loop.
Oh, awesome! I just installed Riot 0.9.9, so I'm going to test that out and see if the issue occurs. After that I'll switch to RiotX and check there as well and report any issues I find.
Are there any other projects using this setup? Also, any write up on the compelling reasons to switch? Are they hoping this move will attract more contributors? Article is unclear.
Compelling reasons to switch: it's an open standard, it's federated (so you can own your own server and avoid vendor lock-in), it has end-to-end encryption, it supports bridging with many other protocols, there's quite a growing ecosystem of tools and libraries around it, etc.
The protocol itself is designed to be really flexible in the kind of data you can send through it (and therefore automatically propagated to and synchronized with other servers) so it can support a lot of different use cases. This includes standard chat app things like audio/video calls but it could also be used for stuff like forums or even serve as a backend for syncing information between organization (I'm thinking of things like medical information between health institutions).
I try matrix on occasion (as in, I set up my own server from scratch). The last time I tried it, support for multi-participant audio and video calls (and screensharing) was still between terrible and nonexistant. Definitely much worse than Discord. Has it improved?
There were some bug fixes in the last year (IIRC) though nothing very substantial, I think. Then again, it's always worked reasonably well for me and I'm using it regularly. I heard it was going to get worked on soon, though.
There was a major upgrade to the conference calling about 6 months ago which took it from being "barely usable" to "almost as good as Zoom". It's different semantics to Discord in that it's classic conferencing rather than a voice channel, but it works well enough for the whole core Matrix team to use it basically constantly for remote collaboration.
The conferencing servers are currently in London however, so you may suffer from transatlantic traffic problems if you are elsewhere in the world.
Ah, thank you for the additional information. Is my grapevine information correct that more work will be done to improve video calls and screensharing in the coming months?
As an example of what could be improved, I do still encounter the occasional bug with call synchronization, the video stream of one of the sides not getting started on occasion and screensharing is hardly discoverable.
I'm confused. Is Matrix actually synchronous or asynchronous? The Matrix FAQ (https://matrix.org/faq/#what-is-a-homeserver%3F) makes it sound like it can be asynchronous. Otherwise, why store communication history at all?
Matrix is asynchronous. You send a message into a room; other people can receive it later or respond to it subsequently - it's not like the data blocks the room somehow until it's read, or that messages disappear after reading.
Each individual Rust team (which govern individual aspects of Rust) got to choose where to jump to; I believe one did choose to use Matrix, but the others mostly chose Discord (because there was already a very large Rust user community there), a few chose Zulip, and one is still on IRC. If Matrix clients were more well-developed and widely-used, I believe there would be good incentive for them to transition--the Rust developers already have enough on their plate without feeling like they need to also develop their own communication protocol.
I still find it inappropriate for a FOSS project to promote closed non federated communication tools. Hopefully they won't be stuck with Discord because "we already switched to it".
I think they are just being pragmatic. No one, not even RMS, ever felt that open source needed to be open source from bottom to top, just the final product. You have to be pragmatic in this life. We can't wait for open source processors running on open source hardware on and open source OS compiled on an open source compiler before something gets released. I find it entirely appropriate for them to be pragmatic and use the tools to get done what they need to get done.
Personally, I see no problem with using Matrix for pragmatism reasons included. Your argument could make sense, if good quality FOSS IMs weren't an option. But they are. So I see no reason to turn to Discord and will not going to use it myself.
That page could have (much) better UX - n.b. that it defaults to showing you only Linux clients; you have to click around to filter by other platforms. It also is outdated and misses many of the newer exciting clients such as http://dittochat.org/ or https://github.com/kiliankoe/nio. A more comprehensive view can be found at https://matrix.org/docs/projects/try-matrix-now/. Updating all this is on the todo list, but writing software >> writing website atm.
One big reason is that the core matrix protocol is incredibly simple to implement. With a good http library, it's a few lines of code to get a basic plaintext client going. However, there is a lot of surface area to cover. So that's how you end up with a lot of 1h/week projects that implement just what the single author cares most about.
Matrix advertises themselves as an eventually consistent global JSON DB. So it makes sense anyone can build a client and stuff something in there and maybe only their client really handles it.
Seems like a better idea given the failure of XMPP. XMPP was a communications protocol lots of products used like Google Talk, but got dumped when they wanted to do their own proprietary stuff. It feels like Matrix will be less likely to get dumped like that since they are just a general purpose global DB.
HTML's middle ages were characterised by competing implementations of similar functionality. Inconsistency would be cause for concern, but incompleteness is expected.
Yes, the ability to create your own client certainly is. Everyone can implement their client as they see fit, as long as they stay compatible with the API. Naturally, you get many clients with different features.
Besides that, there is a reference implementation (Riot).
Maybe if the one "finished" client doesn't work well for some users, e.g. is cumbersome to use with a screen reader, but there's a "half-finished" client that works well for them.
The announcement mentions only two features: safety and accessibility, but places no emphasis on the technical merits of the choice for the majority of users. That is disappointingly irrational for a technology organization.
I don't feel comfortable with the strong emphasis on "progressive" concerns that mozilla (and the rust community) have. It's not inclusive: I have normal liberal views (I'm from a European country and under 40) and I don't think I'd feel comfortable working for one of those organizations because I suspect the progressives there would be angry or offended with my reluctance to embrace the identity politics dogma. I didn't even feel comfortable posting this under my usual account, such is the atmosphere.
Accessibility is clearly important. But "safety" concerns have become overblown: reasonable concerns have become polluted by the politics of the "safe space" contingent, and the sorts of people that are closing down legitimate debate in the name of progressive/identity politics. And technical suitability for the 95% of modally-abled users is still an important consideration.
Disclaimer: I work for Mozilla, and I was quite happy with IRC personally.
The announcement may not mention it, but there were trial instances of a number of messaging apps set up, people could use them and submit feedback, and that feedback was in fact considered as far as I know. Accessibility and safety were not the only criteria at all.
As far as "safety" concerns being overblown... I personally had approximately zero problems with IRC that way, though some of the random spammers who sounded like foul-mouthed 12-year-olds could be annoying at (rare, in my experience) times. But I absolutely have co-workers whose IRC experience was a lot less pleasant. And if moving to a different system lets us get rid of that unpleasantness for them, that is a _very_ strong reason to consider such a move, both on general moral grounds and on purely business-reasons "people who can get their work done sanely get more work done" efficiency grounds.
Note that we're not talking about safety from debate or opposing viewpoints or whatnot. We're talking about people being able to discuss a bugfix with others without being constantly spammed with invective and threats in the process. _That_ is what "safety" means in this context.
Accessibility was actually as far as I understand an argument in favor of staying on IRC (but also in favor of Matrix) since there are IRC clients which work very well with screenreaders (I think weechat for example). It is the proprietary solutions which have poor accessibility.
> technical suitability for the 95% of modally-abled users is still an important consideration.
Are you saying that we should give more advantages to people who already have the advantage of having no significant disability, while adding difficulty for people who already have extra difficulties (or at best making only token efforts toward accessibility)? That seems unreasonable to me.
Fortunately, with an open system like Matrix, everyone can have a client that works well for them.
IRC has the advantage of being usable without any specialized software (although the usability is not as well as if you do have specialized IRC software, it is still at least usable).
Are you talking about a different hack because the only hack I have heard of was not a repo hack (someone stole the SSH keys of a sysadmin via a compromised jenkins server), and they were very transparent about it.
The hack was pretty bad but I do not agree with your description of it unless you are talking about a different hack.
“We need x done” can’t be done at all until it’s approved by those who govern the project.
Actual example of this: years ago, the Servo team really would have liked a form of inheritance, to help with DOM stuff. We thought it wouldn’t be right for the language. Rust still doesn’t have inheritance today.
This argument is also predicated on the idea that full time devs get more done than part time ones do. That’s true in a one on one comparison, but there are far more part time ones, so collectively they do way more work.
Agreed, this together with how they handled the redesign of the website left a sour taste in my mouth. Especially with the promised retrospective that has been promised for over a year now; there have been at least two posts on the internals forum about the followup but still nothing. It's frustrating, especially because both decisions felt like they were made in a vacuum without properly listening to the community; chiefly how the redesign suddenly was suddenly announced close to the 2018 edition release and a whole lot of the feedback and criticism has not yet been addressed. The website still does not have syntax highlighting [0] nor a snippet of Rust code on the frontpage [1], not to mention the lack of addressing the change in the pitch used on the frontpage (compared to the previous website [2]). The language itself is amazing and I love using it and, the community is awesome and I for the most part think the governance is great; but on some issues they have some catching up to do.
And bad accessibility too, which I would argue goes against the Rust project's inclusivity message.
But I do not think it is up to Mozilla corporation to pick communication platform for Rust, that is not their job. The blame lies squarely on the Rust project.
All Mozilla employees working on Rust are under Moco, not Mofo, that's correct. Unless something extremely drastic that nobody has talked about has happened in the last year.
Wouldn't you have a choice between continuing to get paid or continuing to comment? And what if I already knew your decision would be to stop getting paid and quit HN but I still needed you to continue being on HN because your presence here was valuable to me? Would that not mean that I'm paying you, but I can't force you to do anything without harming myself much more than you?
AFAICT they moved off IRC in response to Mozilla's announcement that it was being deprecated and also because IRC was terrible. They tried Zulip but concluded it wouldn't work well. There was already a community Discord server doing well so they set up an official one.
I suspect they might move back to Mozilla's Riot/Matrix instance once it's set up in production, but that hasn't happened yet.
