11 ms·

Native Matrix VoIP with Element Call

502 points by Sami_Lehtinen 5y ago

robobro 5y ago
Did anyone else try to install this? It just refreshes non stop for me when I access its domain.
- Arathorn 5y ago
  works fine for me. if the app had launched i'd ask you to submit feedback (which ends up in our bugtracker). as it hasn't, can you file a bug on github.com/vector-im/element-call/issues with a copy of the javascript console so we can see what's breaking? you might also want to disable any weird browser extensions to see if that's to blame.
  - robobro 5y ago
    sure, appreciate the comment! :) The main instance @ call.element.io also doesn't seem to work for me, but I chalked that up to (assumed) heavy server load.
jpbernius 5y ago
There is some cool development going on with Matrix recently! Threaded messaging first and now group calls. I am especially excited for Safari Support as this is my personal pain-point with Jitsi Meet. Very excited to see this evolve into the Element client.
2Gkashmiri 5y ago
this does not seem to have changeable room addresses right now like jitsi. we use jitsi common url to have weekly meetings. meet.jit.si/meeting2. everyone knows the url and time. we just join and talk. this is a nice concept
- kitkat_new 5y ago
  I think it does in theory (Matrix supports changing room addresses), however what is the benefit of this as opposed to using the same address for all meetings?
  - 3np 5y ago
    The person you're replying to wants to set it to something custom, to make it memorable and meaningful.
    - Arathorn 5y ago
      We have this today. https://call.element.io/whateveryouwant https://call.element.io/whateveryouwant does what you'd expect.
  - jacobmischka 5y ago
    I think that's what they want, I believe by "changeable" they meant "customizable"?
- jeroenhd 5y ago
  That seems to be available, though? https://call.element.io/meetingwiththegang https://call.element.io/meetingwiththegang opens a meeting for a room named "meetingwiththegang". Ideally, you'd want to use such a system with accounts so you can apply some kind of ACL, but if you want to use randomly generated room names for secret links then everything you need is there already. Looks like you can't change the room name after starting the call, but you can start a new one at the new address if you want to change the name.
traspler 5y ago
Do the Homeservers act as Signaling, STUN and TURN servers or are there additional components necessary? Will the SFU part in the future also be part of Synapse or will/are these things split?
- qqcwerqwect 5y ago
  As I understand it, signalling will happen over the matrix protocol. as matrix/element already had a 1:1 voice chat, synapse integrates well with coturn, so you typically run coturn along side synapse.
- Arathorn 5y ago
  The homeservers act as signalling servers. For STUN/TURN you need to run a separate TURN server (typically coturn), as per https://matrix-org.github.io/synapse/latest/turn-howto.html https://matrix-org.github.io/synapse/latest/turn-howto.html. The future SFU will similarly be split from the homeserver, with the initial implementation based on either Signal-Calling-Service, ionsfu or mediasoup (we're evaluating all three). Of course, the point of being standards based is that you'll be able to mix & match SFUs and MCUs from other vendors. You can find out more about the architecture from my talk at Commcon (https://2021.commcon.xyz/talks/extending-matrix-s-e2ee-calls-to-multiparty https://2021.commcon.xyz/talks/extending-matrix-s-e2ee-calls...) - or Robert's talk at FOSDEM: https://fosdem.org/2022/schedule/event/matrix_metaverse/ https://fosdem.org/2022/schedule/event/matrix_metaverse/
  - traspler 5y ago
    Thanks a lot for answering in detail!
  - anticensor 5y ago
    For court admissible conferencing, routing everything through the persistent room state is almost a hard requirement.
- georgyo 5y ago
  Only signalling. Matrix users coturn for STUN and TURN.
mawise 5y ago
> Element Call is built entirely on Matrix: it doesn’t need any additional servers to get going. You can run it against your existing Matrix homeserver to provide complete self-sovereignty… > In the near future, we will support using the app with any homeserver I really hope this isn't an indicator how how Element the company will be focusing more on their paid offerings to the exclusion of supporting private homeservers. I've recently been experimenting with running a Matrix homeserver on a Raspberry PI in my basement--I'm excited about actual self-sovereignty in messaging but it isn't quite to the point where I can tell my family to rely on it instead.
- jfkimmes 5y ago
  I feel like this is a misunderstanding. You can already self host 'Element Call' and point that to your own homeserver. The passage you're referencing just refers to their hosted Element Call client. I'm pretty sure they're currently trying to move away from credentials-based login on 3rd-party clients to token-based authentication. I would guess they open up their hosted client when they finished implementing this new authentication scheme to avoid the doubled effort and to discourage using your homeserver credentials on "random" clients.
  - Arathorn 5y ago
    Yup, the grandparent post is a misunderstanding. Basically, we want Element Call to work with a single click to a URL without requiring any account - much as Jitsi and similar do. Therefore it needs to pick a default homeserver. Currently it doesn't play well with existing Matrix accounts (as it will sync in loads of chatrooms which are irrelevant when you just want to do a call), so for expedience we just create accounts on its default homeserver to get going. However, we're in the process of moving Matrix over to OIDC for auth (as per https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-special-2021#openid-connect https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-s...), at which point apps like Element Call should be able to easily hook into your existing account on your own homeserver using your existing server auth. In other words, the server will auth you, not the client. Combined with Sliding Sync (aka Sync v3) https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-special-2021#sync-v3 https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-s... this will then let you securely and efficiently use your existing Matrix account with apps like Element Call without it all getting bogged down with your existing chatrooms (or needlessly giving Element Call access to conversations it shouldn't care about). Finally, this is beta: the auth/reg stuff is very much placeholder - for instance, it doesn't even expose password reset, given the upcoming shift to OIDC.
youerbt 5y ago
> And, the big one drum roll, please... we will be integrating this into Element so you can have voice and video rooms, and hold group video calls inside the Element app natively over Matrix. I'd love to replace my teamspeak server with this. Discord is tempting, but I'd rather host it myself.
- jeroenhd 5y ago
  For what it's worth, Matrix / Element already have something like this with the built-in Jitsi integration in (some) clients. The UX isn't great right now in my opinion (which will hopefully change when this project gets merged into Element) but if all you want is rooms, text and voice, then you're already set with the current setup. You can self-host a Jitsi instance and use it in Matrix rooms as an integration. Depending on your teamspeak setup you can enable guest access to your server, enable registration for server user accounts (or manually register it for specific members), or only let people with existing accounts from other servers join in (their own, matrix.org ones, you name it). You might also need to tweak the ACLs a bit, but other than that you'll have all the core features Teamspeak and friends provide. I think the biggest difference between the existing Matrix group call system and what's been announced here today is the new UI/UX, and the fact that the native group call API and reference implementation are nearing completion. Both are great news, but don't necessarily add new user-facing features to the Matrix ecosystem.
  - GeckoEidechse 5y ago
    Yes but the current UX for that is terrible. With the proposed MSC linked in the blog post, Matrix will additionally gain Teamspeak/Discord like voice channels [1]. With this we could finally have a proper Teamspeak/Mumble bridge for voice that gets properly represented on the Matrix side which is amazing :D Also kinda funny that Teamspeak only recently started using Matrix for their global chat feature [2]. Maybe now after the gitter acquisition, Element should consider acquiring a certain voice-focused company ;) ** [1] https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/group-voip/proposals/3401-group-voip.md#mcall-state-event https://github.com/matrix-org/matrix-spec-proposals/blob/mat... [2] https://community.teamspeak.com/t/teamspeak-5-beta-bug-report-bbcode-not-working-channel-commander-not-shown/14670/4 https://community.teamspeak.com/t/teamspeak-5-beta-bug-repor...
jeroenhd 5y ago
I wonder if this setup can be leveraged to create a Twitch-like streaming solution based on Matrix. The group call setup is clearly not built for such a use case, but if you only stream to a small audience (say, people paying for a certain perk on Patreon?) you could probably use this quite easily. The client would need better support for alternative inputs, of course, such as the RTMP suggestion found on the Github issues page, but it can and should work. What I'm also curious about is how this fits in with the experiments on the peer-to-peer mesh system (running a homeserver on every client). Forwarding video across a web of clients would become bandwidth and CPU intensive real fast and the added latency would be non-negligible. I'll be watching this play out with great interest, that's for sure.
- Arathorn 5y ago
  > I wonder if this setup can be leveraged to create a Twitch-like streaming solution based on Matrix. Yes, we've built it with this in mind. There are three possible approaches: * You can broadcast a headless client via HLS or RTMP, similar to how Jibri works for Jitsi, and how we broadcast FOSDEM (https://matrix.org/blog/2021/02/15/how-we-hosted-fosdem-2021-on-matrix/ https://matrix.org/blog/2021/02/15/how-we-hosted-fosdem-2021...). Basically you run a headless Chrome against a virtual X server and pipe X's framebuffer into ffmpeg. It's a pretty blunt approach and obviously uses a lot of serverside resources, but ensures that the broadcasted stream is completely faithful given that it's literally a recording of what a client would be seeing. * Alternatively, you could do the same approach, but pipe it into a WebRTC broadcasting platform rather than HLS/RTMP/RTSP/DASH. This could give much lower latency, but more bandwidth on the server given you're effectively setting up a 1:1 VoIP call with each viewer, and you'll be unlikely to be able to use CDNs (unless we end up in some crazy world where freeform multicast on the internet finally comes to pass thanks to CDNs fanning out your RTP packets for you :P) * Finally, you could composite the streams together serverside using an MSC3401 compliant MCU and broadcast the result via one or other approach. This might not be quite as high fidelity as running a 'real' Element Call instance serverside, but could be way more efficient in terms of resources, and could prove perfectly adequate. The only catch is that we haven't bolted MSC3401 onto any MCUs yet. (Clearly we should get back in touch with our friends at FreeSWITCH / Signalwire :D) > What I'm also curious about is how this fits in with the experiments on the peer-to-peer mesh system (running a homeserver on every client). Forwarding video across a web of clients would become bandwidth and CPU intensive real fast and the added latency would be non-negligible. MSC3401 is pretty much orthogonal to P2P Matrix. The way it works is that it'll use whatever conferencing nodes ('foci') are advertised in the room to mix together the calls in a decentralised fashion. If there are none (as per today) then it just goes full mesh. If there is one, then everyone will converge on it. If there are two, then folks will pick the one with the lowest latency. But critically, it doesn't matter whether the clients are talking to a serverside homeserver or are running P2P Matrix. Finally, the foci could run either serverside or clientside (much as skype supernodes were effectively clientside foci), but we need to get serverside foci working first before we add clientside ones in for the P2P crew ;)
encryptluks2 5y ago
> We’re also working with the Tauri core team to provide cross-platform lightweight desktop apps as soon as possible! How about a lightweight cross-platform Matrix client that doesn't rely on Electron?
- Jack5500 5y ago
  Well, it doesn't use Electron, it uses tauri, which doesn't bundle chrome but uses the native browser and is therefor much smaller, faster und more lightweight.
- GeckoEidechse 5y ago
  Why not just use FluffyChat? https://fluffychat.im/ https://fluffychat.im/
  - DoItToMe81 5y ago
    I used Fluffychat for a few months. I found its performance was rather lacking. It had slowdown issues and general problems that I didn't find with other clients.
  - nani8ot 5y ago
    I personally can't stand how big the chat bubbles in FluffyChat 1.0+ are. They were always big but now they are huge. I would have preferred it if they got smaller... But with Element now shipping chat bubbles as an configurable option, I'll stay with that. For me, the new chat bubbles size is perfect. Aside of that, I'm generally really fond of FluffyChat, they are doing a great job!
- Arathorn 5y ago
  Tauri + Electron (or Hydrogen) provides a lightweight cross-platform Matrix client that doesn't rely on Electron... Meanwhile, Nheko, NeoChat, Fractal and others provide very usable lightweight native cross-platform Matrix clients too. Element is also working on its own experiments (TBA) based on matrix-rust-sdk.
  - 5y ago
encryptluks2 5y ago
I feel if XMPP just had some better tools this push for Matrix would be unnecessary.
- GeckoEidechse 5y ago
  https://matrix.org/faq/#what-is-the-difference-between-matrix-and-xmpp%3F https://matrix.org/faq/#what-is-the-difference-between-matri...
  - zaik 5y ago
    If you read https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/group-voip/proposals/3401-group-voip.md https://github.com/matrix-org/matrix-spec-proposals/blob/mat... it becomes apparent that the 'eventually consistent' part of Matrix is more of a hindrance in this case. Also 'the more federation and interoperability the better' is kind of contradictory to constantly reinventing extisting Internet Standards. I suspect VoIP over Matrix is not compatible with SIP or XMPP A/V calls and looking at current state of the matrix.org XMPP chat implementation they probably will never be.
- zaik 5y ago
  As of recently, Dino already can do video conferences based on XMPP and other clients are working on it as well. There is also a bidirectional SIP/XMPP bridge, so it integrates with other existing Internet Standards: https://sip.cheogram.com/ https://sip.cheogram.com/
- kitkat_new 5y ago
  please read the article (and linked MSC [0]) first and check out how this decentralized(!) conferencing proposal works. I don't think tools that implement this exist in the XMPP ecosystem at all. [0] https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/group-voip/proposals/3401-group-voip.md https://github.com/matrix-org/matrix-spec-proposals/blob/mat...
- pigeons 5y ago
  Yeah, I read Matrix's reasoning for not just improving XMPP and instead starting a new protocol, and I gave them a few years, and have to use matrix quite a bit and am consistently convinced it was the wrong choice and XMPP is the way to go.
Arathorn 5y ago
From my perspective, the really exciting thing about this that it works equally well in mobile web browsers as well as desktop web - clicking on a link on Mobile Safari should Do The Right Thing without having to install anything. Moreover, because it's built on Matrix, MSC3401 (https://github.com/matrix-org/matrix-doc/blob/matthew/group-voip/proposals/3401-group-voip.md https://github.com/matrix-org/matrix-doc/blob/matthew/group-...) means that we'll finally have decentralised cascading video/voice conferences once the SFU (selective forwarding unit) component is added into the mix. So, for instance, users on the same homeserver will get their video feeds relayed locally with minimal latency... and then users on another remote homeserver will also get mixed locally with minimal latency, trunking the two together. If the link dies or one homeserver dies, the conference will keep going - i.e. precisely the same semantics as normal Matrix.
- jfkimmes 5y ago
  Could you give some insights on how you estimate the amount of effort of making Element Call competitive, performance-wise, with say Discord. I heard that Discord threw a lot of time and money at optimizing voice in their product. Can you just jump in and realistically compete? There are a lot of performance/latency/sound quality comparisons online of Mumble vs TeamSpeak vs Discord and recently Jitsi vs MS Teams vs Zoom, etc. I feel like this is a problem-space that can be optimized to an arbitrarily deep extent. Just two examples that come to mind are SFU performance/efficiency and noise reduction, two things where e.g Jitsi notoriously lags behind Zoom.
  - Arathorn 5y ago
    The competitive gap with Discord in terms of media quality is probably something like: * Need a low-latency SFU. This should be very doable; not only are there a lot of good FOSS SFUs to build on top of these days, the history of the Matrix team is actually that we built VoIP stacks fulltime before we shifted focus to Matrix, and we've built MCUs and media servers of all flavours in the past. MSC3401 should also give us a competitive edge given latency will be automagically minimised by using the physically closest decentralised SFU, thus letting anyone bring their SFU to the party. * Needs a SFU with good rate control (and/or FEC). This is probably the single most important thing to get right in terms of quality. Signal wrote up a good overview of why: https://signal.org/blog/how-to-build-encrypted-group-calls/ https://signal.org/blog/how-to-build-encrypted-group-calls/ * Excellent noise cancellation (and background noise elimination, microphone scratch noise elimination etc). Ideally you need something like https://krisp.ai/ https://krisp.ai/ or https://workspaceupdates.googleblog.com/2021/06/background-noise-reduction-cancellation-update.html https://workspaceupdates.googleblog.com/2021/06/background-n... in the mix - but doing this in an E2EE-friendly and privacy preserving manner is Hard. However, just like we solved E2EE full text search by doing it clientside and making the indexes gossipable between your clients (https://github.com/matrix-org/seshat https://github.com/matrix-org/seshat), we'll have a go at doing something similar for this problem too. * Excellent automatic gain control. The importance of normalising/compressing everyone's audio so they're equivalent loudness is really important. We're also in the process of adding in spatial audio (unsure if Discord has that) which should help a tonne with distinguishing the different audio feeds. We can probably also be more bullish about supporting new audio codecs like Lyra. EDIT: oh, the other obvious thing is echo cancellation - but we're currently at the mercy of the browser's WebRTC stack for that. However, we could ship a tweaked WebRTC in Element Desktop (or other native Matrix clients) in future to do better than plain old WebRTC.
Godel_unicode 5y ago
Has anyone looked into their implementation of E2EE for calls? My naive assumption is they are brokering some kind of shared key exchange as opposed to requiring everyone to send an individually encrypted stream to everyone else.
- jfkimmes 5y ago
  The post says there is no E2EE at the moment. They're probably talking about signalling, since with the current implementation of full mesh you get E2EE 'for free' in WebRTC. Also the post mentions: https://2021.commcon.xyz/talks/extending-matrix-s-e2ee-calls-to-multiparty https://2021.commcon.xyz/talks/extending-matrix-s-e2ee-calls...
  - Arathorn 5y ago
    So in the initial beta we haven't turned on E2EE, purely because it will make it way harder to debug any problems which surface. However, at this rate, things are looking pretty stable and i'd expect us to enable it in the next few weeks. It uses normal Matrix E2EE, which means a Double Ratchet between the pairs of devices participating in a given conversation, which is then used to secure the signalling which is used to set up the calls between the devices. The call media is transport-layer encrypted via DTLS and SRTP, so as long as the signalling with the DTLS fingerprints is secured by Matrix E2EE, the whole call fabric will be E2EE. https://github.com/matrix-org/matrix-js-sdk/pull/2002 https://github.com/matrix-org/matrix-js-sdk/pull/2002 is the PR we actually need to merge in order to enable E2EE on it, ftr.
    - dodgerdan 5y ago
      Will E2EE be on by default?
      - Arathorn 5y ago
        yup
  - arianvanp 5y ago
ve5eta 5y ago
Impressive
panick21_ 5y ago
This is really cool. I really feel like this ecosystem is hitting its stride. The list of upcoming features is long and sometimes I don't understand how they can have so many things going on at once. Features tend to take a few years to mature, but that is not a bad thing. I will be setting up my own server shortly, something that I have been thinking about for a while and maybe try to develop something. Congrats to the team. Question: The OpenID part, would it not be cool if Matrx would offer something like a federated SSO experience? So that on other webpages you could use your matrix login instead of Github/Google and co. Hosting that server yourself would be fantastic. There are of course some issues with Attribute retrieval if user can host these servers themselves.
- Arathorn 5y ago
  > The OpenID part, would it not be cool if Matrix would offer something like a federated SSO experience? Yes, hopefully we'll be able to use the OIDC server bundled with your Matrix server to auth users in general if wanted (or alternatively you can of course point at an existing OIDC server).
  - bb010g 5y ago
    Has support for IndieAuth and/or FedCM (when stable enough) been considered? https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web https://github.com/fedidcg/FedCM https://github.com/fedidcg/FedCM
- ptman 5y ago
  https://gitlab.com/ptman/matrix-login https://gitlab.com/ptman/matrix-login this could ofc be modified to support oidc
jiffygist 5y ago
Just wondering, can I have fullband stereo sound to play music?
- Arathorn 5y ago
  The media quality that you hear is entirely up to the sender's WebRTC implementation. If you're calling another Element Call user, we currently use the default audio constraints when capturing audio: https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732bc3b5e748719072356d562e52097ba/src/webrtc/mediaHandler.ts#L302 https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732b... - but if you wanted stereo, you could put { channelCount: 2, sampleRate: 48000 } or whatever into that line to achieve it. I'll file a bug to make this configurable. EDIT: https://github.com/vector-im/element-call/issues/249 https://github.com/vector-im/element-call/issues/249
stevenicr 5y ago
great post, animation helps a bunch too. wondering if ip addys are exposed to the other users like with webrtc and if so, could we force conencts to be only through coturn to hide the ips? Also wonder if there will be a warning for such, especially of encryption is turned on - some may think they are truly anonymous, and where ips are exposed of course that's not true. Also wonder about moderation, hopefully this does not become a target for the sickening trolls soon - but moderation needs will be coming, so who gets the ip logs to consider blocking? homeserver runners? I expect the future will need whitelists/blocklists subscription options for clients at some point.
- Arathorn 5y ago
  Currently we don't force TURN, so in practice this means that voice packets go direct between the clients if possible, and so the IP addresses of the clients are necessarily exposed to each other. However, this is utterly trivial to fix: matrix-js-sdk already exposes https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732bc3b5e748719072356d562e52097ba/src/client.ts#L297 https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732b... and we simply haven't exposed it as a setting in Element Call yet. I've filed a bug for it at https://github.com/vector-im/element-call/issues/251 https://github.com/vector-im/element-call/issues/251 - thanks for bringing it up! In terms of moderation: this is no different to moderation in Matrix as a whole, where we're already busy working on shared greylists (MSC2313 and friends) - https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix-without-backdoors https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix... has more details at the end.
giancarlostoro 5y ago
My only concern is does this expose your IP to participants? This is one benefit of Discord Voice channels vs Discord Calls (which are end to end but expose your IP to everyone on the call, and theirs to you, so much so, you just open a console log and you can see them all...).
- Arathorn 5y ago
  Currently yes, but it's trivial to fix and we'll do so on Monday - see https://news.ycombinator.com/item?id=30570436 https://news.ycombinator.com/item?id=30570436
  - mattmerr 5y ago
    Sounds like hiding IP is going to be opt-in? I'm not sure what the implications are of TURN but what would be the downside of making IP-hiding the default?
    - Arathorn 5y ago
      it would increase latency badly (the turn server for the call.element.io instance is in the UK, so all traffic would bounce through it, often unnecessarily), and it would cost us loads on bandwidth as a result. It also means that the turn server sees all the IPs and metadata of who is calling who, which may not be an improvement if you trust your caller more than your server admins! For instance, two users on the same LAN calling each other would end up bounced via the UK, which is a bit unfortunate if they are in Australia. The solution is really to switch to using SFUs everywhere, which then solves both firewall traversal, scalability and privacy (assuming you’re happy for your SFU to know your IP - but if you’re happy for your TURN to know it, then it’s probably fine).
abnercoimbre 5y ago
I run a hybrid conference [0] with a physical track and an online track. All tracks communicate using Matrix. Element Call sounds like something I should integrate into the conference experience, but logistics and audience size is a concern. We'll be entering 1k+ territory this year. [0] https://handmade-seattle.com https://handmade-seattle.com
- Arathorn 5y ago
  please wait until we’re out of beta! :)
deleted 5y ago
[deleted]
puyoxyz 5y ago
Why is this an Element thing and not a Matrix thing?
- Arathorn 5y ago
  The protocol, spec (MSC3401) and underlying client heavy lifting (matrix-js-sdk) are all Matrix; contributed by a mix of Element employees (Robert, me, Dave) and community contribs (Simon B). The app skin itself on top is Element, given most of the work and the original idea is from Element folks - same reason that Element itself is a product from Element-the-company even though 95% of the code is underlying Matrix projects. The Matrix Foundation itself is a non-profit to look after all the Matrix protocol and reference implementations but doesn’t ship user-facing products, just as W3C and Linux Foundation don’t.
- deleted 5y ago
  [deleted]
soupbowl 5y ago
I am excited about this, I hope it is stable and secure...
lijogdfljk 5y ago
A bit off topic, but anyone know if Threads are something Matrix currently supports, or ever wants to support? My family uses Signal for _a lot_, likely way more than we should, and i feel like we'd benefit from threads immensely. Maybe i should toy with making my own Matrix client or something, heh. edit: https://github.com/vector-im/element-web/issues/2349 https://github.com/vector-im/element-web/issues/2349 looks like it might exist in some beta form. Depending on the client heh
- jeroenhd 5y ago
  Threads are supported on Matrix as of a week or two ago. They're no longer in beta as far as I can tell. I don't know for sure how well alternative clients support them, but desktop and mobile versions of Element do threads just fine. Alternatives (Fluffychat, for example) are usually a while behind Element because of manpower. For example, native polls are in Element but not in Fluffychat yet. So, if you want to risk the transition, best to recommend the official clients first. That said, I don't know how well threads will actually work in a family context. I like them as a concept, but outside Google Chat (where every message in a room is a response to or the start of a thread) I haven't seen them get picked up naturally.
- Arathorn 5y ago
  yup, it’s currently in testing on element web/ios/android and you can play with it in beta.
- kevincox 5y ago
  Threads are in beta on the Element clients. IIUC the spec isn't quite solidified (they are waiting for more clients to experiment first).
jwithington 5y ago
Big fan of matrix. Run a server on my RPi.
desertraven 5y ago
Slightly off topic: I really like the idea of Matrix/Element, but I’ve found I can’t rely on it. In three instances, I’ve had a long-running chats stop working completely and simply not load. All history/media inaccessible. Just a loading spinner. This is Element on iOS. I wish it were more dependable, because things like this would excite me much more.
- Arathorn 5y ago
  We have had some fairly nightmarish bugs on iOS thanks to how iOS changed push notifications a while back, meaning that you end up with a tiny client in the push extension trying to independently sync and decrypt e2ee traffic which was at risk of clashing with the main app and causing problems. I think I know the bug you are describing, and it was fixed several months ago - as of the current build the spinner should only show for less than a second and never get stuck on. Sorry that you got bitten by this; I’m also an iOS poweruser and the fallout from the push changes was painful. Seperately, we wre also experimenting with a full rewrite of the iOS app on top of matrix-rust-sdk called Element X, which whould provide a much better and faster codebase to try to avoid this sort of thing in future.
  - desertraven 5y ago
    Wow! Seems it was user error, since I just updated it and it’s fixed. Thanks so much. I wish I could update my parent comment. Although this interaction speaks for itself I think. Thanks for a great product!
throwaway29879 5y ago
Still waiting for an android release that doesn't use ~7G ram and crash consistently on desktop (14G ram, then dies, or most recently, instantly segfaults) As usual, delusions of grandeur and horrifically over confidence in the abilities of a 45 million dollar funded gang of "developers" that have produced basically nothing in 8 years, when unfunded students have produced a discord clone in about 6 months
deleted 5y ago
[deleted]
Apotheos 5y ago
Have always wanted to try and run a Matrix instance but the tutorials all seem just a bit out of my skill level. Would love if there was a docker container to easily spin up an instance.
- ryukafalz 5y ago
  There is: https://hub.docker.com/r/matrixdotorg/synapse/ https://hub.docker.com/r/matrixdotorg/synapse/

502 points by Sami_Lehtinen 5y ago

robobro 5y ago

Did anyone else try to install this? It just refreshes non stop for me when I access its domain.

Arathorn 5y ago
works fine for me. if the app had launched i'd ask you to submit feedback (which ends up in our bugtracker). as it hasn't, can you file a bug on github.com/vector-im/element-call/issues with a copy of the javascript console so we can see what's breaking? you might also want to disable any weird browser extensions to see if that's to blame.
- robobro 5y ago
  sure, appreciate the comment! :) The main instance @ call.element.io also doesn't seem to work for me, but I chalked that up to (assumed) heavy server load.

jpbernius 5y ago

There is some cool development going on with Matrix recently! Threaded messaging first and now group calls. I am especially excited for Safari Support as this is my personal pain-point with Jitsi Meet. Very excited to see this evolve into the Element client.

2Gkashmiri 5y ago

this does not seem to have changeable room addresses right now like jitsi. we use jitsi common url to have weekly meetings. meet.jit.si/meeting2. everyone knows the url and time. we just join and talk. this is a nice concept

kitkat_new 5y ago
I think it does in theory (Matrix supports changing room addresses), however what is the benefit of this as opposed to using the same address for all meetings?
- 3np 5y ago
  The person you're replying to wants to set it to something custom, to make it memorable and meaningful.
  - Arathorn 5y ago
    We have this today. https://call.element.io/whateveryouwant https://call.element.io/whateveryouwant does what you'd expect.
- jacobmischka 5y ago
  I think that's what they want, I believe by "changeable" they meant "customizable"?
jeroenhd 5y ago
That seems to be available, though? https://call.element.io/meetingwiththegang https://call.element.io/meetingwiththegang opens a meeting for a room named "meetingwiththegang". Ideally, you'd want to use such a system with accounts so you can apply some kind of ACL, but if you want to use randomly generated room names for secret links then everything you need is there already. Looks like you can't change the room name after starting the call, but you can start a new one at the new address if you want to change the name.

traspler 5y ago

Do the Homeservers act as Signaling, STUN and TURN servers or are there additional components necessary? Will the SFU part in the future also be part of Synapse or will/are these things split?

qqcwerqwect 5y ago
As I understand it, signalling will happen over the matrix protocol. as matrix/element already had a 1:1 voice chat, synapse integrates well with coturn, so you typically run coturn along side synapse.
Arathorn 5y ago
The homeservers act as signalling servers. For STUN/TURN you need to run a separate TURN server (typically coturn), as per https://matrix-org.github.io/synapse/latest/turn-howto.html https://matrix-org.github.io/synapse/latest/turn-howto.html. The future SFU will similarly be split from the homeserver, with the initial implementation based on either Signal-Calling-Service, ionsfu or mediasoup (we're evaluating all three). Of course, the point of being standards based is that you'll be able to mix & match SFUs and MCUs from other vendors. You can find out more about the architecture from my talk at Commcon (https://2021.commcon.xyz/talks/extending-matrix-s-e2ee-calls-to-multiparty https://2021.commcon.xyz/talks/extending-matrix-s-e2ee-calls...) - or Robert's talk at FOSDEM: https://fosdem.org/2022/schedule/event/matrix_metaverse/ https://fosdem.org/2022/schedule/event/matrix_metaverse/
- traspler 5y ago
  Thanks a lot for answering in detail!
- anticensor 5y ago
  For court admissible conferencing, routing everything through the persistent room state is almost a hard requirement.
georgyo 5y ago
Only signalling. Matrix users coturn for STUN and TURN.

mawise 5y ago

> Element Call is built entirely on Matrix: it doesn’t need any additional servers to get going. You can run it against your existing Matrix homeserver to provide complete self-sovereignty… > In the near future, we will support using the app with any homeserver I really hope this isn't an indicator how how Element the company will be focusing more on their paid offerings to the exclusion of supporting private homeservers. I've recently been experimenting with running a Matrix homeserver on a Raspberry PI in my basement--I'm excited about actual self-sovereignty in messaging but it isn't quite to the point where I can tell my family to rely on it instead.

jfkimmes 5y ago
I feel like this is a misunderstanding. You can already self host 'Element Call' and point that to your own homeserver. The passage you're referencing just refers to their hosted Element Call client. I'm pretty sure they're currently trying to move away from credentials-based login on 3rd-party clients to token-based authentication. I would guess they open up their hosted client when they finished implementing this new authentication scheme to avoid the doubled effort and to discourage using your homeserver credentials on "random" clients.
- Arathorn 5y ago
  Yup, the grandparent post is a misunderstanding. Basically, we want Element Call to work with a single click to a URL without requiring any account - much as Jitsi and similar do. Therefore it needs to pick a default homeserver. Currently it doesn't play well with existing Matrix accounts (as it will sync in loads of chatrooms which are irrelevant when you just want to do a call), so for expedience we just create accounts on its default homeserver to get going. However, we're in the process of moving Matrix over to OIDC for auth (as per https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-special-2021#openid-connect https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-s...), at which point apps like Element Call should be able to easily hook into your existing account on your own homeserver using your existing server auth. In other words, the server will auth you, not the client. Combined with Sliding Sync (aka Sync v3) https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-special-2021#sync-v3 https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-s... this will then let you securely and efficiently use your existing Matrix account with apps like Element Call without it all getting bogged down with your existing chatrooms (or needlessly giving Element Call access to conversations it shouldn't care about). Finally, this is beta: the auth/reg stuff is very much placeholder - for instance, it doesn't even expose password reset, given the upcoming shift to OIDC.

youerbt 5y ago

> And, the big one drum roll, please... we will be integrating this into Element so you can have voice and video rooms, and hold group video calls inside the Element app natively over Matrix. I'd love to replace my teamspeak server with this. Discord is tempting, but I'd rather host it myself.

jeroenhd 5y ago
For what it's worth, Matrix / Element already have something like this with the built-in Jitsi integration in (some) clients. The UX isn't great right now in my opinion (which will hopefully change when this project gets merged into Element) but if all you want is rooms, text and voice, then you're already set with the current setup. You can self-host a Jitsi instance and use it in Matrix rooms as an integration. Depending on your teamspeak setup you can enable guest access to your server, enable registration for server user accounts (or manually register it for specific members), or only let people with existing accounts from other servers join in (their own, matrix.org ones, you name it). You might also need to tweak the ACLs a bit, but other than that you'll have all the core features Teamspeak and friends provide. I think the biggest difference between the existing Matrix group call system and what's been announced here today is the new UI/UX, and the fact that the native group call API and reference implementation are nearing completion. Both are great news, but don't necessarily add new user-facing features to the Matrix ecosystem.
- GeckoEidechse 5y ago
  Yes but the current UX for that is terrible. With the proposed MSC linked in the blog post, Matrix will additionally gain Teamspeak/Discord like voice channels [1]. With this we could finally have a proper Teamspeak/Mumble bridge for voice that gets properly represented on the Matrix side which is amazing :D Also kinda funny that Teamspeak only recently started using Matrix for their global chat feature [2]. Maybe now after the gitter acquisition, Element should consider acquiring a certain voice-focused company ;) ** [1] https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/group-voip/proposals/3401-group-voip.md#mcall-state-event https://github.com/matrix-org/matrix-spec-proposals/blob/mat... [2] https://community.teamspeak.com/t/teamspeak-5-beta-bug-report-bbcode-not-working-channel-commander-not-shown/14670/4 https://community.teamspeak.com/t/teamspeak-5-beta-bug-repor...

jeroenhd 5y ago

I wonder if this setup can be leveraged to create a Twitch-like streaming solution based on Matrix. The group call setup is clearly not built for such a use case, but if you only stream to a small audience (say, people paying for a certain perk on Patreon?) you could probably use this quite easily. The client would need better support for alternative inputs, of course, such as the RTMP suggestion found on the Github issues page, but it can and should work. What I'm also curious about is how this fits in with the experiments on the peer-to-peer mesh system (running a homeserver on every client). Forwarding video across a web of clients would become bandwidth and CPU intensive real fast and the added latency would be non-negligible. I'll be watching this play out with great interest, that's for sure.

Arathorn 5y ago
> I wonder if this setup can be leveraged to create a Twitch-like streaming solution based on Matrix. Yes, we've built it with this in mind. There are three possible approaches: * You can broadcast a headless client via HLS or RTMP, similar to how Jibri works for Jitsi, and how we broadcast FOSDEM (https://matrix.org/blog/2021/02/15/how-we-hosted-fosdem-2021-on-matrix/ https://matrix.org/blog/2021/02/15/how-we-hosted-fosdem-2021...). Basically you run a headless Chrome against a virtual X server and pipe X's framebuffer into ffmpeg. It's a pretty blunt approach and obviously uses a lot of serverside resources, but ensures that the broadcasted stream is completely faithful given that it's literally a recording of what a client would be seeing. * Alternatively, you could do the same approach, but pipe it into a WebRTC broadcasting platform rather than HLS/RTMP/RTSP/DASH. This could give much lower latency, but more bandwidth on the server given you're effectively setting up a 1:1 VoIP call with each viewer, and you'll be unlikely to be able to use CDNs (unless we end up in some crazy world where freeform multicast on the internet finally comes to pass thanks to CDNs fanning out your RTP packets for you :P) * Finally, you could composite the streams together serverside using an MSC3401 compliant MCU and broadcast the result via one or other approach. This might not be quite as high fidelity as running a 'real' Element Call instance serverside, but could be way more efficient in terms of resources, and could prove perfectly adequate. The only catch is that we haven't bolted MSC3401 onto any MCUs yet. (Clearly we should get back in touch with our friends at FreeSWITCH / Signalwire :D) > What I'm also curious about is how this fits in with the experiments on the peer-to-peer mesh system (running a homeserver on every client). Forwarding video across a web of clients would become bandwidth and CPU intensive real fast and the added latency would be non-negligible. MSC3401 is pretty much orthogonal to P2P Matrix. The way it works is that it'll use whatever conferencing nodes ('foci') are advertised in the room to mix together the calls in a decentralised fashion. If there are none (as per today) then it just goes full mesh. If there is one, then everyone will converge on it. If there are two, then folks will pick the one with the lowest latency. But critically, it doesn't matter whether the clients are talking to a serverside homeserver or are running P2P Matrix. Finally, the foci could run either serverside or clientside (much as skype supernodes were effectively clientside foci), but we need to get serverside foci working first before we add clientside ones in for the P2P crew ;)

encryptluks2 5y ago

> We’re also working with the Tauri core team to provide cross-platform lightweight desktop apps as soon as possible! How about a lightweight cross-platform Matrix client that doesn't rely on Electron?

Jack5500 5y ago
Well, it doesn't use Electron, it uses tauri, which doesn't bundle chrome but uses the native browser and is therefor much smaller, faster und more lightweight.
GeckoEidechse 5y ago
Why not just use FluffyChat? https://fluffychat.im/ https://fluffychat.im/
- DoItToMe81 5y ago
  I used Fluffychat for a few months. I found its performance was rather lacking. It had slowdown issues and general problems that I didn't find with other clients.
- nani8ot 5y ago
  I personally can't stand how big the chat bubbles in FluffyChat 1.0+ are. They were always big but now they are huge. I would have preferred it if they got smaller... But with Element now shipping chat bubbles as an configurable option, I'll stay with that. For me, the new chat bubbles size is perfect. Aside of that, I'm generally really fond of FluffyChat, they are doing a great job!
Arathorn 5y ago
Tauri + Electron (or Hydrogen) provides a lightweight cross-platform Matrix client that doesn't rely on Electron... Meanwhile, Nheko, NeoChat, Fractal and others provide very usable lightweight native cross-platform Matrix clients too. Element is also working on its own experiments (TBA) based on matrix-rust-sdk.
- 5y ago

encryptluks2 5y ago

I feel if XMPP just had some better tools this push for Matrix would be unnecessary.

GeckoEidechse 5y ago
https://matrix.org/faq/#what-is-the-difference-between-matrix-and-xmpp%3F https://matrix.org/faq/#what-is-the-difference-between-matri...
- zaik 5y ago
  If you read https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/group-voip/proposals/3401-group-voip.md https://github.com/matrix-org/matrix-spec-proposals/blob/mat... it becomes apparent that the 'eventually consistent' part of Matrix is more of a hindrance in this case. Also 'the more federation and interoperability the better' is kind of contradictory to constantly reinventing extisting Internet Standards. I suspect VoIP over Matrix is not compatible with SIP or XMPP A/V calls and looking at current state of the matrix.org XMPP chat implementation they probably will never be.
zaik 5y ago
As of recently, Dino already can do video conferences based on XMPP and other clients are working on it as well. There is also a bidirectional SIP/XMPP bridge, so it integrates with other existing Internet Standards: https://sip.cheogram.com/ https://sip.cheogram.com/
kitkat_new 5y ago
please read the article (and linked MSC [0]) first and check out how this decentralized(!) conferencing proposal works. I don't think tools that implement this exist in the XMPP ecosystem at all. [0] https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/group-voip/proposals/3401-group-voip.md https://github.com/matrix-org/matrix-spec-proposals/blob/mat...
pigeons 5y ago
Yeah, I read Matrix's reasoning for not just improving XMPP and instead starting a new protocol, and I gave them a few years, and have to use matrix quite a bit and am consistently convinced it was the wrong choice and XMPP is the way to go.

Arathorn 5y ago

From my perspective, the really exciting thing about this that it works equally well in mobile web browsers as well as desktop web - clicking on a link on Mobile Safari should Do The Right Thing without having to install anything. Moreover, because it's built on Matrix, MSC3401 (https://github.com/matrix-org/matrix-doc/blob/matthew/group-voip/proposals/3401-group-voip.md https://github.com/matrix-org/matrix-doc/blob/matthew/group-...) means that we'll finally have decentralised cascading video/voice conferences once the SFU (selective forwarding unit) component is added into the mix. So, for instance, users on the same homeserver will get their video feeds relayed locally with minimal latency... and then users on another remote homeserver will also get mixed locally with minimal latency, trunking the two together. If the link dies or one homeserver dies, the conference will keep going - i.e. precisely the same semantics as normal Matrix.

jfkimmes 5y ago
Could you give some insights on how you estimate the amount of effort of making Element Call competitive, performance-wise, with say Discord. I heard that Discord threw a lot of time and money at optimizing voice in their product. Can you just jump in and realistically compete? There are a lot of performance/latency/sound quality comparisons online of Mumble vs TeamSpeak vs Discord and recently Jitsi vs MS Teams vs Zoom, etc. I feel like this is a problem-space that can be optimized to an arbitrarily deep extent. Just two examples that come to mind are SFU performance/efficiency and noise reduction, two things where e.g Jitsi notoriously lags behind Zoom.
- Arathorn 5y ago
  The competitive gap with Discord in terms of media quality is probably something like: * Need a low-latency SFU. This should be very doable; not only are there a lot of good FOSS SFUs to build on top of these days, the history of the Matrix team is actually that we built VoIP stacks fulltime before we shifted focus to Matrix, and we've built MCUs and media servers of all flavours in the past. MSC3401 should also give us a competitive edge given latency will be automagically minimised by using the physically closest decentralised SFU, thus letting anyone bring their SFU to the party. * Needs a SFU with good rate control (and/or FEC). This is probably the single most important thing to get right in terms of quality. Signal wrote up a good overview of why: https://signal.org/blog/how-to-build-encrypted-group-calls/ https://signal.org/blog/how-to-build-encrypted-group-calls/ * Excellent noise cancellation (and background noise elimination, microphone scratch noise elimination etc). Ideally you need something like https://krisp.ai/ https://krisp.ai/ or https://workspaceupdates.googleblog.com/2021/06/background-noise-reduction-cancellation-update.html https://workspaceupdates.googleblog.com/2021/06/background-n... in the mix - but doing this in an E2EE-friendly and privacy preserving manner is Hard. However, just like we solved E2EE full text search by doing it clientside and making the indexes gossipable between your clients (https://github.com/matrix-org/seshat https://github.com/matrix-org/seshat), we'll have a go at doing something similar for this problem too. * Excellent automatic gain control. The importance of normalising/compressing everyone's audio so they're equivalent loudness is really important. We're also in the process of adding in spatial audio (unsure if Discord has that) which should help a tonne with distinguishing the different audio feeds. We can probably also be more bullish about supporting new audio codecs like Lyra. EDIT: oh, the other obvious thing is echo cancellation - but we're currently at the mercy of the browser's WebRTC stack for that. However, we could ship a tweaked WebRTC in Element Desktop (or other native Matrix clients) in future to do better than plain old WebRTC.

Godel_unicode 5y ago

Has anyone looked into their implementation of E2EE for calls? My naive assumption is they are brokering some kind of shared key exchange as opposed to requiring everyone to send an individually encrypted stream to everyone else.

jfkimmes 5y ago
The post says there is no E2EE at the moment. They're probably talking about signalling, since with the current implementation of full mesh you get E2EE 'for free' in WebRTC. Also the post mentions: https://2021.commcon.xyz/talks/extending-matrix-s-e2ee-calls-to-multiparty https://2021.commcon.xyz/talks/extending-matrix-s-e2ee-calls...
- Arathorn 5y ago
  So in the initial beta we haven't turned on E2EE, purely because it will make it way harder to debug any problems which surface. However, at this rate, things are looking pretty stable and i'd expect us to enable it in the next few weeks. It uses normal Matrix E2EE, which means a Double Ratchet between the pairs of devices participating in a given conversation, which is then used to secure the signalling which is used to set up the calls between the devices. The call media is transport-layer encrypted via DTLS and SRTP, so as long as the signalling with the DTLS fingerprints is secured by Matrix E2EE, the whole call fabric will be E2EE. https://github.com/matrix-org/matrix-js-sdk/pull/2002 https://github.com/matrix-org/matrix-js-sdk/pull/2002 is the PR we actually need to merge in order to enable E2EE on it, ftr.
  - dodgerdan 5y ago
    Will E2EE be on by default?
    - Arathorn 5y ago
      yup
- arianvanp 5y ago

ve5eta 5y ago

Impressive

panick21_ 5y ago

This is really cool. I really feel like this ecosystem is hitting its stride. The list of upcoming features is long and sometimes I don't understand how they can have so many things going on at once. Features tend to take a few years to mature, but that is not a bad thing. I will be setting up my own server shortly, something that I have been thinking about for a while and maybe try to develop something. Congrats to the team. Question: The OpenID part, would it not be cool if Matrx would offer something like a federated SSO experience? So that on other webpages you could use your matrix login instead of Github/Google and co. Hosting that server yourself would be fantastic. There are of course some issues with Attribute retrieval if user can host these servers themselves.

Arathorn 5y ago
> The OpenID part, would it not be cool if Matrix would offer something like a federated SSO experience? Yes, hopefully we'll be able to use the OIDC server bundled with your Matrix server to auth users in general if wanted (or alternatively you can of course point at an existing OIDC server).
- bb010g 5y ago
  Has support for IndieAuth and/or FedCM (when stable enough) been considered? https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web https://github.com/fedidcg/FedCM https://github.com/fedidcg/FedCM
ptman 5y ago
https://gitlab.com/ptman/matrix-login https://gitlab.com/ptman/matrix-login this could ofc be modified to support oidc

jiffygist 5y ago

Just wondering, can I have fullband stereo sound to play music?

Arathorn 5y ago
The media quality that you hear is entirely up to the sender's WebRTC implementation. If you're calling another Element Call user, we currently use the default audio constraints when capturing audio: https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732bc3b5e748719072356d562e52097ba/src/webrtc/mediaHandler.ts#L302 https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732b... - but if you wanted stereo, you could put { channelCount: 2, sampleRate: 48000 } or whatever into that line to achieve it. I'll file a bug to make this configurable. EDIT: https://github.com/vector-im/element-call/issues/249 https://github.com/vector-im/element-call/issues/249

stevenicr 5y ago

great post, animation helps a bunch too. wondering if ip addys are exposed to the other users like with webrtc and if so, could we force conencts to be only through coturn to hide the ips? Also wonder if there will be a warning for such, especially of encryption is turned on - some may think they are truly anonymous, and where ips are exposed of course that's not true. Also wonder about moderation, hopefully this does not become a target for the sickening trolls soon - but moderation needs will be coming, so who gets the ip logs to consider blocking? homeserver runners? I expect the future will need whitelists/blocklists subscription options for clients at some point.

Arathorn 5y ago
Currently we don't force TURN, so in practice this means that voice packets go direct between the clients if possible, and so the IP addresses of the clients are necessarily exposed to each other. However, this is utterly trivial to fix: matrix-js-sdk already exposes https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732bc3b5e748719072356d562e52097ba/src/client.ts#L297 https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732b... and we simply haven't exposed it as a setting in Element Call yet. I've filed a bug for it at https://github.com/vector-im/element-call/issues/251 https://github.com/vector-im/element-call/issues/251 - thanks for bringing it up! In terms of moderation: this is no different to moderation in Matrix as a whole, where we're already busy working on shared greylists (MSC2313 and friends) - https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix-without-backdoors https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix... has more details at the end.

giancarlostoro 5y ago

My only concern is does this expose your IP to participants? This is one benefit of Discord Voice channels vs Discord Calls (which are end to end but expose your IP to everyone on the call, and theirs to you, so much so, you just open a console log and you can see them all...).

Arathorn 5y ago
Currently yes, but it's trivial to fix and we'll do so on Monday - see https://news.ycombinator.com/item?id=30570436 https://news.ycombinator.com/item?id=30570436
- mattmerr 5y ago
  Sounds like hiding IP is going to be opt-in? I'm not sure what the implications are of TURN but what would be the downside of making IP-hiding the default?
  - Arathorn 5y ago
    it would increase latency badly (the turn server for the call.element.io instance is in the UK, so all traffic would bounce through it, often unnecessarily), and it would cost us loads on bandwidth as a result. It also means that the turn server sees all the IPs and metadata of who is calling who, which may not be an improvement if you trust your caller more than your server admins! For instance, two users on the same LAN calling each other would end up bounced via the UK, which is a bit unfortunate if they are in Australia. The solution is really to switch to using SFUs everywhere, which then solves both firewall traversal, scalability and privacy (assuming you’re happy for your SFU to know your IP - but if you’re happy for your TURN to know it, then it’s probably fine).

abnercoimbre 5y ago

I run a hybrid conference [0] with a physical track and an online track. All tracks communicate using Matrix. Element Call sounds like something I should integrate into the conference experience, but logistics and audience size is a concern. We'll be entering 1k+ territory this year. [0] https://handmade-seattle.com https://handmade-seattle.com

Arathorn 5y ago
please wait until we’re out of beta! :)

deleted 5y ago

[deleted]

puyoxyz 5y ago

Why is this an Element thing and not a Matrix thing?

Arathorn 5y ago
The protocol, spec (MSC3401) and underlying client heavy lifting (matrix-js-sdk) are all Matrix; contributed by a mix of Element employees (Robert, me, Dave) and community contribs (Simon B). The app skin itself on top is Element, given most of the work and the original idea is from Element folks - same reason that Element itself is a product from Element-the-company even though 95% of the code is underlying Matrix projects. The Matrix Foundation itself is a non-profit to look after all the Matrix protocol and reference implementations but doesn’t ship user-facing products, just as W3C and Linux Foundation don’t.
deleted 5y ago
[deleted]

soupbowl 5y ago

I am excited about this, I hope it is stable and secure...

lijogdfljk 5y ago

A bit off topic, but anyone know if Threads are something Matrix currently supports, or ever wants to support? My family uses Signal for _a lot_, likely way more than we should, and i feel like we'd benefit from threads immensely. Maybe i should toy with making my own Matrix client or something, heh. edit: https://github.com/vector-im/element-web/issues/2349 https://github.com/vector-im/element-web/issues/2349 looks like it might exist in some beta form. Depending on the client heh

jeroenhd 5y ago
Threads are supported on Matrix as of a week or two ago. They're no longer in beta as far as I can tell. I don't know for sure how well alternative clients support them, but desktop and mobile versions of Element do threads just fine. Alternatives (Fluffychat, for example) are usually a while behind Element because of manpower. For example, native polls are in Element but not in Fluffychat yet. So, if you want to risk the transition, best to recommend the official clients first. That said, I don't know how well threads will actually work in a family context. I like them as a concept, but outside Google Chat (where every message in a room is a response to or the start of a thread) I haven't seen them get picked up naturally.
Arathorn 5y ago
yup, it’s currently in testing on element web/ios/android and you can play with it in beta.
kevincox 5y ago
Threads are in beta on the Element clients. IIUC the spec isn't quite solidified (they are waiting for more clients to experiment first).

jwithington 5y ago

Big fan of matrix. Run a server on my RPi.

desertraven 5y ago

Slightly off topic: I really like the idea of Matrix/Element, but I’ve found I can’t rely on it. In three instances, I’ve had a long-running chats stop working completely and simply not load. All history/media inaccessible. Just a loading spinner. This is Element on iOS. I wish it were more dependable, because things like this would excite me much more.

Arathorn 5y ago
We have had some fairly nightmarish bugs on iOS thanks to how iOS changed push notifications a while back, meaning that you end up with a tiny client in the push extension trying to independently sync and decrypt e2ee traffic which was at risk of clashing with the main app and causing problems. I think I know the bug you are describing, and it was fixed several months ago - as of the current build the spinner should only show for less than a second and never get stuck on. Sorry that you got bitten by this; I’m also an iOS poweruser and the fallout from the push changes was painful. Seperately, we wre also experimenting with a full rewrite of the iOS app on top of matrix-rust-sdk called Element X, which whould provide a much better and faster codebase to try to avoid this sort of thing in future.
- desertraven 5y ago
  Wow! Seems it was user error, since I just updated it and it’s fixed. Thanks so much. I wish I could update my parent comment. Although this interaction speaks for itself I think. Thanks for a great product!

throwaway29879 5y ago

Still waiting for an android release that doesn't use ~7G ram and crash consistently on desktop (14G ram, then dies, or most recently, instantly segfaults) As usual, delusions of grandeur and horrifically over confidence in the abilities of a 45 million dollar funded gang of "developers" that have produced basically nothing in 8 years, when unfunded students have produced a discord clone in about 6 months

deleted 5y ago

[deleted]

Apotheos 5y ago

Have always wanted to try and run a Matrix instance but the tutorials all seem just a bit out of my skill level. Would love if there was a docker container to easily spin up an instance.

ryukafalz 5y ago
There is: https://hub.docker.com/r/matrixdotorg/synapse/ https://hub.docker.com/r/matrixdotorg/synapse/