It's not clear whether this concerns Matrix-the-protocol or Element-the-client. The page itself seems to be about the client. Maybe this can be cleared up in the submission title.
I'm using an alternative client, but I see that that space is nowhere near keeping up with the features Element are pushing out. Mine doesn't even support spaces yet. I'd like to use a 'native' client (Linux/KDE person here), but there's not much choice (I never got the Neochat flatpak to work reliable for instance, on a variety of distros). So, one must basically go with the Element (web) client, which is not very light.
I have nothing but good words for the project btw, thanks and keep it up :)
Surprisingly nheko seems to basically work, including spaces and encryption. I also heard Thunderbird 102 added fairly complete Matrix support, but it takes a little while to roll out to Linux distributions so I haven't tried it yet.
I use fluffychat and cinny. Yes, I might be missing out on newer features (threads, widgets, video rooms, etc). But at this stage I'm happy with what these clients offer.
First, can we please stop replacing every word in the dictionary with “experience”? https://youtu.be/nGHbOckpifw
Many of European states (including mine) are looking into ways of replacing Teams and Office 365. Video/voice rooms is a must have and this is a very important update for Matrix. Just updated Element and will be trying soon. :)
I'm not GP but I'm guessing it's for data sovereignty reasons.
Microsoft is a US company subject to the CLOUD Act. The US Govt don't need to worry about this since the act was passed for their own benefit. Other countries do.
The US CLOUD Act is incompatible with the GDPR. The goals are the complete opposite and complying with both is extremely difficult, leading to several recent cases ruling that using Google services is likely illegal in the EU.
Congrats to the element team for delivering the first decentralized messaging system that can be used in a modern context (open, full E2EE, hostable and not only text oriented)
Plus points for showing the world that you don't need a blockchain for this :-)
> Plus points for showing the world that you don't need a blockchain for this :-)
Who said you did need it for this feature in the first place? I don't think anyone did.
Since no one suggested to use a blockchain for this particular feature, it is more likely that crypto supporters want to add crypto wallets in messengers which is what most competitors have already done, unlike Element. Notably Signal which still has a crypto wallet where I see many Signal fans getting extremely upset about that.
You better pray and hope that Element does not introduce a crypto wallet, just like what Signal, Session, Keybase has done.
Not likely since the Matrix ecosystem seems to be open source even in practice, where outside development is accepted and encouraged. Disabling features is unproblematic.
The other systems you mentioned is either all proprietary or has limited source code availability where there's no practical way to fork it or develop it further.
Because it takes away development resources from actually useful things.
And f.e. taking the examples of Signal and Keybase, both their crypto wallets/implementations are about the most useless possible. Keybase b/c I know no one who actually uses it as a messenger and it uses stellar/lumens, Signal b/c it is apparently impossible in most countries to actually get tokens to load / unload your wallet.
Is this usable for a general public? They don't seem to mention anything about encryption.
I have played with Matrix on several occasions. I think one of the big promises was E2E encryption and as those who have worked in the area know it's not an easiy problem to solve. I have accounts on more than 1 homeserver. I have various keys in my password manager which I don't necessarily understand how they are used. I have old messages that I cannot decrypt, despite being sure that I have never lost any keys.
In summary: In my experience Matrix has not been an easy experience even for a user of gpg.
Here I am not asking how is this made secure and usable. I am just asking is this usable for anybody who does not even know what a homeserver is, would never understand what a key or fingerprint is and has no account yet?
The current video rooms implementation is powered by Jitsi, which optionally exposes E2EE for clients which support it (Element Web on Chrome and possibly Safari) via insertable streams and megolm crypto from Matrix. It isn't hooked into Matrix's key identity system though.
We're also working on the Third Room project which has virtual worlds with 3D positional audio built on top of the same tech as Element Call. It's still very early, but the project is up here: https://github.com/matrix-org/thirdroom
I have one question about this. I am self hosting element and i have set up jitsi for group calls and this feature. Works great but unfortunately my kiddo instance is public.. is there any way to secure it easily or make it only available to element?
I'm guessing it's about 1-2 months away. The hard bit is that we need to effectively have Element Call share the same matrix client as Element itself does, in order to embed Call into Element effectively. We call this matryoshka embedding, and it's looking promising to get it working in the next week or two, and then will need to actually update all three Element clients (Web, Android & iOS) to support it.
Obviously folks can also just click into a standalone Element Call to make it work (plus Hydrogen is also adding native Matrix calling).
Element Call doesn't currently need any custom server - it just uses your existing homeserver; Synapse, Dendrite, Conduit etc. However, it only scales up to 7-8 users - to go beyond that we'll need to add a SFU, which we're also working on.
A MCU or a virtual apex could be better in order to ensure everyone hears the same thing. And a virtual apex combined with large events could also provide a decentralised persistence layer.
Element is still missing a way to turn off broadcasting read receipts despite being an allegedly privacy focused client as advertised on their website. It makes me think the maintainers are a little confused about privacy in some aspects.
No, it's just been a painful problem to solve. If you're interested, you can see the massive discussion around it at https://github.com/matrix-org/matrix-spec-proposals/pull/228.... The implementations have been around for a while, and as it happens we got to consensus on the spec discussion yesterday, and the PRs to enable it by default in Element Web and Synapse landed an hour ago:
Last i had checked a contributor had locked the issue discussion a year or more ago after losing an argument about an interim stopgap being useful to solve the immediate privacy issue. A story as old as the internet itself, that one. So at least that one contributor did not care about interim privacy which gives the obvious "we don't care" signal when not contradicted by anyone else.
Could we use matrix as identification for git issues, etc.? On self hosted git repos. Instead of github,gitlab,bitbucket.
Then you can communicate with all those self hosted repos without making accounts for every single one. And you could choose your software (gitea,gitlab,...)
The de facto default chat software is probably WhatsApp, or perhaps Telegram if your group of people lives in the german alternative scene (or, placed from germany, perhaps more eastern countries?).
But default group chat could well be Discord, not formerly Slack(?), any more.
I'm a little confused by this announcement; does this mean that I have to host my own Jitsi Meet server and that Element will connect to it, or does this new version of Element "bring its own" Jitsi?
I host my own instance of Matrix / Element Web, so this would be great if it's not too difficult to set up.
Yes. You can point it at your own instance of jitsi or at a public open one. I'm currently hosting jitsi as well but still trying to figure out how to make it not publicly available while still being usable in Element.
I have configured my self hosted element web to point at my instance but if a user logs into the matrix home server with e.g. the element app it will still have the public element jitsi pre configured afaik.
I assume the audio/video stack runs on a different thread so not much.
It still suffers from a terminal case of Electron, but atleast it's not worse than it's comptetitors in this regard. Both teams and discord have an absolutely laughable click to photon time on anything but high end machines.
Despite the Electronness, I think the UX of Discord is still much better than that of Element. There's just something off about the way element responds to interactions, I can't put my finger on it. I've noticed there have been some improvements made over time, but Discord is still much more fluent in the places where it matters.
Cinny, being very Discord inspired, also gets many of the Discord usability features right. With the way Cinny is developing I wouldn't be surprised if the two projects would eventually merge together. The lack of audio/video support is the most obvious flaw at the moment, but perhaps once proper Matrix voice is stable and implemented in Element we'll see some improvements in that area in Cinny as well.
Ran an instance of the reference implementation for a year or two and hadn't noticed resource consumption that much tbh. And this was for an organization with hundreds of members. Did something change in the past two years?
I think you’re confusing Element and Synapse. Synapse is the reference implementation, Element is the client. And it can definitely be a resource hog on some end systems but it seems pretty fine in general
nope, perf has improved a lot in the last 2 years (on web, at least). android and ios are still slower than they should be in accounts with large rooms, but there is a bunch of step changes on the horizon (called “sliding sync”) which should eliminate that.
I think a lot of the "element is slow" can be attributed for using the matrix homeserver. I personally notice it somewhat frequently that that one is quite slow, in comparison to a privately hosted one.
Summary: element-desktop sluggish and freezing with accounts with large amount of rooms and history on Linux (consistent across devices, dists, and DEs). This is separate from a recent freezing issue which was fixed in v1.11.0.
It was for me, too. I was subbed to dozens of rooms that I never used. I trimmed it down to about 10 rooms and it’s noticeably faster. Bulk deleting messages is still an absolute bastard (app hangs for days).
Question: in the new video Rooms of Element (Matrix), can multiple users at the same time share both their screen and their video?
This is a feature of Whereby that in my personal experience is indispensable for pair-work. Besides Teams not being GDPR compliant, Teams imho is designed with the typical US hierarchical boss presents, workers listen-model and doesn’t cater for a cooperative model of sharing screens at the same time, like Norwegian Whereby does.
I have a question since you seem to be involved with element. Is it possible to make element list all users of a home server? Or is a custom identity server required for that? I think there used to be a project called mxisd which is now unmaintained...
This feature would be great to e.g. replace slack with matrix/element.
Or if you don’t have a homeserver, invite all your users to a space so you can see them there.
Identity servers are generally just for looking up user by email or phone number (although mxisd did intercept some endpoints to add a user directory before synapse exposed the option above).
Thanks for the reply :)
I've configured that setting but it still won't outright list all the users to a new user, although it will let them search for eachother.
I guess I could do it by automatically joining all users who register to a welcome channel, i saw that there's a setting for that in synapse.
I only read about video sharing in a group, not every-user-to-every-user calls. Which easily eats up a lot of bandwith (, at least on the server if that is the place that pre-renders all video tiles together for lower network load in sum).
I'm using an alternative client, but I see that that space is nowhere near keeping up with the features Element are pushing out. Mine doesn't even support spaces yet. I'd like to use a 'native' client (Linux/KDE person here), but there's not much choice (I never got the Neochat flatpak to work reliable for instance, on a variety of distros). So, one must basically go with the Element (web) client, which is not very light.
I have nothing but good words for the project btw, thanks and keep it up :)