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.
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...
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.
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?
This particular issue is being worked on right now in Riot, and should be fixed early in the new year.
If I could then this would be a minor inconvenience at best, I'd just copy/paste the key from the already-trusted device.
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.
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.
Now, if it is obvious that something is a work in progress then I personally wont mind giving it a new shot.
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 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...)
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.
4: Looks like there is a bug for this already - please upvote https://github.com/vector-im/riot-web/issues/10649.
Testing & reporting bugs is absolutely invaluable - thank you.
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.
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.
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.
Moving synapse databases around isn't too difficult, and certainly Modular.im would be able to provide the data on request.
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).
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?
Might as well ask, right?
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.
I'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.
Interesting. I had the impression that the Rust version would have priority.
That's great news!
It’s clearly in demand (if a bit of a niche kind of demand)
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.
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/
That's what I'd like to see.
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 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.
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.
And they have a robust ecosystem
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.
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.
Apropos of nothing, currently I am running:
* Google Hangouts (web)
* Friends and ex-coworkers
* Vendor A
* Vendor B
* Team C
* Team D
* Some friends
* My Stepdaughter
* Coworkers too stubborn to open Mattermost or change what they do
* 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
* Spacemacs chat
* IRC (web)
* Various random channels
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.
Sadly, it doesn't work with iMessage, nor Signal.
I just wish it was a native app, although I appreciate that'd make the effort involved 100x more.
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.
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.
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.
An example: https://blog.irccloud.com/slack-integration/
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.
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 has changed.
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.
Discord is admittedly awesome, but not in line with openness.
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".
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.
Compare that to Slack, which only has one client, and it gets worse seemingly every day (somehow?).
Besides that, there is a reference implementation (Riot).
Looking at the pricing on modular.im 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.
(excuse me if channel is not the correct terminology)
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.
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.
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.
Self plug: it also makes me more motivated to return to https://github.com/Ericson2314/matrix-client
The hack was pretty bad but I do not agree with your description of it unless you are talking about a different hack.
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.
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.
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.
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.