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 :)
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.
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
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.
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.
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)
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.)
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.
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.
> 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.
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.
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.
> 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.
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.
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.
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.
Daily reminder that Rust uses Discord, a closed source piece of software with draconian privacy and data retention terms.
Steve Klabnik will predictably reply to me saying that it was the decision of the community and blah blah, but the Mozilla Corporation should not have allowed it.
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?
“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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
HTML's middle ages were characterised by competing implementations of similar functionality. Inconsistency would be cause for concern, but incompleteness is expected.
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.
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.
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.
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.
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.
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?
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.
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 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?
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.
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.
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.
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.
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.
257 comments
[ 2.8 ms ] story [ 248 ms ] threadI'm hoping with Mozilla's backing the product, there's a lot of features that get built out.
There's no reason this cant be a Slack-beating product now.
I'm betting a Rust based homeserver replacing Synapse.
To quote the founder:
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.
https://news.ycombinator.com/item?id=21767057
https://news.ycombinator.com/item?id=21836684
Interesting. I had the impression that the Rust version would have priority.
One of the responses there was: "there is so much hate here that it is making impossible to discuss asensitive issues like security "
It was the lamest excuse ever.
The hack was pretty bad but I do not agree with your description of it unless you are talking about a different hack.
https://github.com/ruma/ruma/issues/189
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.
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.
This helps to reduce compile times when working on projects where you frequently switch between crates.
[0] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
It’s clearly in demand (if a bit of a niche kind of demand)
It’s comparatively easy to write complex portable applications with tk (or even just strait win32 and whichever X11 widget toolkit is your favorite.)
You can try all-Swift development with SwiftUI.
https://www.outrunlabs.com/revery/
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.
And they have a robust ecosystem
https://hackernoon.com/why-i-prefer-nw-js-over-electron-2018...
https://github.com/nwjs/nw.js
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.
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.
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.
That's really only true for web developers trying to make native apps, and only because they're used to the mess that is web development.
It's a piece of cake to build a small app in Qt with C++, and it's even easier using Python or Common Lisp or one of the other language bindings.
Like everything, it depends on each developer's experience which one is easier for them.
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.
https://github.com/Nheko-Reborn/nheko as a Qt telegram-like
https://github.com/quotient-im/Quaternion as a Qt xchat-like
https://github.com/manuroe/messagerie for instance is a SwiftUI client proof-of-concept that should work on macOS as well as iOS
None are as polished as Riot functionalitywise, but we will get there eventually - even more so if people contribute.
That's what I'd like to see.
https://github.com/alphapapa/matrix-client.el/
Fractal is the GTK counterpart https://wiki.gnome.org/Apps/Fractal
Thunderbird also has a Matrix back-end, though XUL is quite close to electron.
Lots of other clients https://matrix.org/clients/
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 really miss the paragraphs style.
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.
"Sorry this is so long. I didn't have time to make it shorter."
Maybe I was thinking about this comment by someone else when I wrote that???: https://news.ycombinator.com/user?id=kibwen
Just so you know, the Rust Embedded guys went with Matrix back in June and several people do use the IRC bridge.
https://github.com/rust-embedded/wg/issues/357
Steve Klabnik will predictably reply to me saying that it was the decision of the community and blah blah, but the Mozilla Corporation should not have allowed it.
Do you see the problem with that line of thinking or do I have to explain further?
Almost all of Mozilla is under Moco.
I could go my own way and comment for free (as I already do) and then I would be able to do whatever I wanted.
But as long as I am funded by you, yes I should do what you ask of me.
Saying Rust development isn't owned by Mozilla is more laughable than saying Go development isn't owned by Google.
Goverance: We should complete the async work before we do X
Pay master: We need X done. Do the async work later.
i.e. the person who is paying the money gets to set the priority.
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.
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.
Baiting people like this is inherently uncivil.
> the Mozilla Corporation should not have allowed it.
Mozilla has no say over what the Rust community does.
[0]: https://www.rust-lang.org/what/networking [1]: https://www.rust-lang.org/ [2]: https://prev.rust-lang.org/en-US/
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.
In general, the teams are allowed to organize themselves as they wish.
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).
All in all, there's a lot of potential in Matrix.
The conferencing servers are currently in London however, so you may suffer from transatlantic traffic problems if you are elsewhere in the world.
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.
GNOME and KDE are also using Matrix.
Are those clients ever going to be released to the general public ?
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.
Really glad to hear you are upgrading the game on the front-end/UX/UI !
edit: well, I give up :D. Been playing for 40 minutes with yarn build/dist and config.json and missing olm and async_hooks dependencies.
[1] https://github.com/vector-im/riot-android/issues/3249
https://github.com/matrix-org/dendrite
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.
If a client has different functionality from the spec, then it simply means that the client is unfinished.
It's not like XMPP where different servers/clients implement different XEPs.
A client either implements the spec and is complete or it does not and it is "beta".
Besides that, there is a reference implementation (Riot).
Compare that to Slack, which only has one client, and it gets worse seemingly every day (somehow?).
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.
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 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).
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...
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.
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?
Moving synapse databases around isn't too difficult, and certainly Modular.im would be able to provide the data on request.
Might as well ask, right?
No. In theory it is, but in practice it's a big centralized IRC bouncer in the sky where everyone is reliant on riot.im servers.
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.
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.
Open to suggestions on how to improve it, though...
I for one would really like code blocks formatting & syntax highlight in the linked text, maybe even show all formatting :)
Do you also plan to replace offensive words in messages?
Forcing people to load a URL to a remote server to see a message is one of the most hostile things I've _ever_ seen an attempt at IRC integration do.
Looking at the pricing on modular.im[1] it starts at $10/month for up to 5 "active users," $73/m for up to 50, on and up..
Though modular's credentials look good, it seems like there'd be scope for some serious price gouging if Matrix had more takeup.
The standard (android) client's default servers are patchy enough to make this worth looking into, IME.
1: https://modular.im/services/matrix-hosting
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.
See https://ircv3.net/.
An example: https://blog.irccloud.com/slack-integration/
(excuse me if channel is not the correct terminology)
That's great news!
https://apply.workable.com/new-vector/j/6CB817C79E/
Discord is admittedly awesome, but not in line with openness.
Self plug: it also makes me more motivated to return to https://github.com/Ericson2314/matrix-client
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.
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.
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.
It seems that the most significant complaint is bad mobile experience.