[HN Gopher] Matrix 2.0: How we're making Matrix go voom
___________________________________________________________________
Matrix 2.0: How we're making Matrix go voom
Author : raybb
Score : 189 points
Date : 2023-02-13 16:55 UTC (6 hours ago)
(HTM) web link (fosdem.org)
(TXT) w3m dump (fosdem.org)
| ridiculous_fish wrote:
| Are there any guides or examples of chat rooms for open source
| projects using Matrix?
|
| We would like GitHub integration, strong spam/moderation
| features, and avoid the hassle of self-hosting. gitter.im used to
| provide those, but they were lost in the Matrix switch.
| Arathorn wrote:
| Matrix's moderation should be at least as good as Gitter. The
| GitHub integration is okay (it lets you create/comment/resolve
| issues using your GitHub identity from Matrix, and also can
| expose GitHub issues as Matrix rooms using
| https://github.com/matrix-org/matrix-hookshot). It's not quite
| as tightly integrated as GitHub was to Gitter though, but we're
| working on putting it in the Right Panel.
|
| Some example Matrix communities which seem to work well include
| Mozilla (chat.mozilla.org), GNOME
| (https://matrix.to/#/#community:gnome.org) and KDE
| (https://webchat.kde.org/). Smaller ones include folks like
| Helix editor: https://matrix.to/#/#helix-community:matrix.org.
| I don't think anyone's written a guide for getting up and
| running though, which in retrospect is a crying shame; we'll
| get it on the todo list.
|
| (p.s. thanks for Hex Fiend! :D)
| faho wrote:
| >Matrix's moderation should be at least as good as Gitter
|
| Well, yes and no. The moderation features might be the same,
| but:
|
| 1. It's a lot easier to make matrix accounts, especially if
| you run your own server.
|
| 2. The user interface for blocking an entire server is
| basically missing? The only thing I can find has you run a
| bot to do it?
|
| So if someone with their own homeserver wants to troll you,
| you end up playing wack-a-mole unless you self-host a bot. At
| least that's the best I can find so far.
| IceWreck wrote:
| OSS projects that use matrix for official comms (of the top of
| my head) - Fedora, Ansible, sonixd, binrw, gotosocial, helix
| and ofc matrix & associated project.
| jeroenhd wrote:
| Gnome, KDE, and Mozilla seem to use Matrix (with bridges where
| necessary). Those are quite big players in the open source
| space.
|
| I don't know how well the public Github bots will work for your
| use case. The moderation tools are also relatively crude in my
| experience; at the protocol level reports/ACLs/reporting is
| quite easy to use, but there's no easy Matrix moderator
| frontend that I know of. There's a bot (mjolnir) but not a
| separate UI.
|
| You can pay people to host your Matrix server or you can use
| the public home servers to set up your community/spaces. Self
| hosting usually isn't necessary.
| kgodey wrote:
| We use Matrix for our open source project:
| https://wiki.mathesar.org/en/community/matrix. We self-host a
| Synapse homeserver, but there's no reason why you can't set up
| a community on one of the big existing servers (e.g.
| matrix.org). Their Spaces feature allows you to package groups
| of channels together.
|
| I set up Maubot for GitHub integration:
| https://github.com/maubot/github. There are moderation
| features, but we haven't had to use them.
| tonyoconnell wrote:
| The Matrix is my last hope for a free internet.
| once_inc wrote:
| 'The' Matrix, or 'Matrix'?
|
| I've been slowly getting wow'ed by the current developments in
| Nostr, which could be a great, new open protocol for social
| media. The native implementation of lightning network payments,
| and the ability to follow paid relays without needing to be
| bound to them is pretty cool.
| superkuh wrote:
| Really? Not IRC? Matrix is so heavy in terms of the protocol.
| It has almost all the state stored on the server instead of the
| client. That directly leads to legal/societal issues and now
| the server has to deal with. Unlike IRC which is basically just
| a bunch of sockets and IPs passing data without storing state.
|
| And that's not even getting into the computational and network
| problems moving and saving all that state causes as addressed
| in this very update about how they're trying to mitigate the
| architectural problems I just mentioned. But they'll only be
| mitigations. And the legal/social problems will still exist and
| since everyone (ie, 99%) of people use the Riot.im/Element.io
| matrix.org homeserver that means social/legal pressures can be
| easily applied.
|
| I like Matrix. I even use it for video chat because of the
| sars-cov-2 pandemic. But it is no hope for freedom.
| jazzyjackson wrote:
| The server/client dichotomy doesn't have to work in the
| typical "log into someone else's computer" way, you can run a
| homeserver locally and federate messages between servers.
| superkuh wrote:
| You can. Just like you can run an email mailserver. About
| about the same proportion of people do.
| Arathorn wrote:
| If you watch the video, you'll see that we're making the
| client-server protocol crazy lightweight
| (https://youtu.be/eUPJ9zFV5IE?t=566) and that we're adding
| the ability to remove servers entirely and go full P2P:
| (https://youtu.be/eUPJ9zFV5IE?t=2155). So you're working on
| stale data here.
|
| (Also, only about 35% of users we're aware of are on the
| matrix.org server, not 99%...)
| mixedCase wrote:
| IRC is not a protocol that as it stands can meet modern user
| expectations of usability and functionality. If I can't use
| it to communicate with people at large, it is not a lot of
| freedom that is gained.
|
| Most of what you complain about societal pressures either
| apply to IRC (access to specific servers) or outright fail
| IRC by default by not providing the feature (state).
| neoromantique wrote:
| IRC is nice, but it is very bare. I would somewhat understand
| if you mentioned Jabber, but even then Matrix is a superior
| choice these days.
| superkuh wrote:
| IRC isn't bare. You're just looking at it wrong. IRC is the
| text communication layer of the _internet which is the
| platform_. Centralizing all functions into one protocol is
| not a great idea.
| Gigachad wrote:
| Why is it not a great idea? It's what every other
| platform has done for over a decade now and it's working
| great. It's absurd that I shouldn't be able to send
| someone an image inline or make a call in a group chat.
| neoromantique wrote:
| The world has moved beyond where just text is sufficient,
| IRC as a protocol is no longer relevant, sad but true.
|
| And I say that as a regular on multiple IRC networks,
| some through Matrix bridge.
| LinuxBender wrote:
| For the other layers one can front-end IRC with TheLounge
| [1][2] or Convos [3][4]. TheLounge only persists history
| in private mode meaning that users are created in that
| front-end and chat messages are in Redis. For small
| networks or groups of friends this is probably fine.
|
| Notably missing is voice chat. I use the Mumble client
| [5] with the Murmur or uMurmur [6] server which is light-
| weight enough to run on ones home router. I use it on
| Alpine Linux, works great. It's not a shiny and attention
| grabbing as Discord but probably fine for everyone else.
| For people to create their own voice channels would
| require the full-blown Murmur server.
|
| [1] - https://github.com/thelounge
|
| [2] - https://thelounge.chat/
|
| [3] - https://github.com/convos-chat/convos/
|
| [4] - https://convos.chat/
|
| [5] - https://www.mumble.info/
|
| [6] -
| https://github.com/umurmur/umurmur/wiki/Configuration
| lmm wrote:
| > For the other layers one can front-end IRC with
| TheLounge [1][2] or Convos [3][4]. TheLounge only
| persists history in private mode meaning that users are
| created in that front-end and chat messages are in Redis.
| For small networks or groups of friends this is probably
| fine.
|
| At that point you've just reimplemented a less-standard
| version of matrix with extra steps though. Your protocol
| has become heavyweight and non-standard (you could argue
| it degrades gracefully to IRC, but in practice using your
| enhanced server from an unenhanced client will always be
| painful), you're holding state on the server in the same
| way you were worried about (and without the mitigation of
| E2EE)...
| neoromantique wrote:
| Thank you for the links, I prefer to use Matrix(Element
| on mobile and gomuks in cli on workstations), I also use
| weechat for certain networks that don't allow bridging
| with matrix, I also bridge slack into same weechat.
|
| But this doesn't change the fact that irc is obscure
| minority now, no matter how many shiny web interfaces we
| put on top of it, so embracing the actually open platform
| that has a chance of gaining any traction is a no-
| brainer.
| donio wrote:
| The world has also moved beyond just text 20 years ago
| and we were all supposed to switch to Jabber/XMPP. And
| yet here I am using IRC as much as ever. If I end up
| using Matrix it will probably be from my favorite IRC
| client through some kind of gateway, just like all the IM
| protocols that have come and gone over the decades.
| neoromantique wrote:
| Nothing wrong with that, hooray for open standards that
| welcome bridging and interconnectivity (I'm looking at
| you, Discord).
|
| But you have to admit, irc is a tiny tiny part of IM
| usage popularity wise, and it's not for no reason.
| woile wrote:
| Has anyone taken a look at https://keet.io/?
| ripdog wrote:
| I inherently distrust anything with crypto bullshit built
| in.
| nabla9 wrote:
| You can use Matrix IRC Bridge.
| superkuh wrote:
| In pratice there is only the Riot.im/Element.io Matrix.org
| homeserver to Libera.chat IRC server bridge. And that
| bridge regularly disconnects people for being idle because
| storing and transferring state is so heavy.
| neoromantique wrote:
| What stops you from running your own bridge?
| anoa_ wrote:
| The reason for this limitation is actually on the IRC
| side - we can only have so many users connected via
| Matrix, so we need to time out stale ones.
| superkuh wrote:
| I asked around and it seems like you're right about it
| not being a resource issue (network or computational).
| The issue is that the bridge is unstable and having tens
| of thousands of matrix.org users join/parting every now
| and then disrupts the IRC channels.
| 2Gkashmiri wrote:
| Any word on EU DMA and other messaging interoperability? .... .
|
| Is there some github repo or some other place where orgs are
| discussing this?
| Arathorn wrote:
| There's https://datatracker.ietf.org/doc/draft-ralston-mimi-
| matrix-t... and https://datatracker.ietf.org/doc/draft-ralston-
| mimi-matrix-m... and associated work around the IETF MIMI
| group, where we're proposing Matrix as a solution to DMA
| interop.
| nehal3m wrote:
| I've been happily running a Synapse homeserver with Matrix on
| top. It has a couple of bridges (Discord/Telegram/Signal) so the
| people I invite through those platforms can use my server to get
| to those services, optionally. Slowly but surely my friends have
| been migrating.
|
| In my experience Element for Android starts off pretty fast, but
| as the weeks progress it gets slower and slower to load chats.
| Element on Linux does not have that problem, and neither does
| Schildichat for Android. It is my client of choice, anyone
| frustrated by a slow client should try that one on for size.
|
| That said I'm excited for the new version. I used this
| Ansible/Docker setup, easy as pie:
|
| https://github.com/spantaleev/matrix-docker-ansible-deploy
| raybb wrote:
| In the talk they explain why the app gets slow now and how the
| app they plan to release by the end of 2023 fixes it with
| sliding sync.
|
| Hopefully that improves your situation
| raybb wrote:
| Link to YouTube video since FOSDEM video isn't loading.
|
| https://www.youtube.com/watch?v=eUPJ9zFV5IE
| heybrendan wrote:
| Thanks for providing. Both the .webm and .mp4:
|
| "No video with supported format and MIME type found."
|
| Not a great UX, but certainly not worth anyone getting upset
| about, given FOSDEM is seemingly volunteer driven.
| Femtiono wrote:
| Shouldn't it be vroom?
| Arathorn wrote:
| Matrix 2.0 will run so smoothly there won't be any nasty
| rattling r's in the onomatopoeic voom :P
| snvzz wrote:
| Once this is deployed, Matrix will finally be providing the bare
| minimum to be actually workable. About time.
|
| Then we can finally try and bring in everybody who's currently
| trapped in proprietary IM.
| kadoban wrote:
| You're not exactly wrong, but you could have worded that a lot
| more kindly.
|
| I'd say that this will remove my last hesitation I've had in
| recommending Matrix to people.
| snvzz wrote:
| I tried (being kind).
|
| What Matrix 2.0 fixes were true pain points which didn't keep
| me from using Matrix with my closest friends, but kept me
| from pushing Matrix to most people.
|
| For a complete example, not that long ago (couple months), I
| had to wait over 10 minutes to send a message to somebody on
| Element on Android (on the street, trying to meet with them),
| because I turned connectivity on at that moment for the first
| time that day, and syncing took that long.
|
| Now, this is instant, so is joining new rooms; This meets
| most people's expectation.
|
| Having native videoconference is also very welcome, but the
| old hack was not a deal-breaker.
| dmix wrote:
| > because I turned connectivity on at that moment for the
| first time that day, and syncing took that long.
|
| So you had to sync all of the messages on the server first
| before sending a message?
| jeroenhd wrote:
| That definitely used to be the case with Matrix. Sync has
| been improving gradually over the last year to alleviate
| that issue, though, assuming your server regularly gets
| updated and you keep your clients up to date.
|
| Sync still takes a second in large rooms, but you no
| longer need to download a thousand messages just to see
| the three latest ones.
| jacooper wrote:
| Most of the problems lie in the clients though. Which should
| improve with element X.
| snvzz wrote:
| AIUI Element X is just an element build with these "Matrix
| 2.0" features. It is not a new client.
|
| Both the servers and the clients will have to be updated to
| leverage them.
| Arathorn wrote:
| Element X is an entirely new client written in Rust + Swift
| UI/Jetpack Compose (https://github.com/vector-im/element-x-
| ios and https://github.com/vector-im/element-x-android)
| which will eventually replace the legacy Element apps
| (https://github.com/vector-im/element-ios and
| https://github.com/vector-im/element-android).
|
| The features already exist serverside; we're just working
| on getting them out of beta.
| snvzz wrote:
| Thanks for the pointers, had no idea.
|
| I am hopeful it also improves resource usage, bringing it
| closer to hydrogen.
|
| Is this also for the desktop/browser version?
| DoItToMe81 wrote:
| Also curious to know if it has web clients and desktop
| clients.
| Arathorn wrote:
| We're not planning to rewrite Element Web/Desktop in Rust
| (yet), so the current app will remain there - although
| we're going to give it a fairly major UI refresh to match
| the new mobile apps.
| ehPReth wrote:
| ooh awesome. I'm just starting the video but I'm really
| hoping sharing is improved on iOS. Like full quality
| video sharing from the share sheets, or seeing my matrix
| rooms/contacts in the top row of contact suggestions, but
| most importantly the ability to add 'comments' to
| photos/links I share with people
|
| e.g. share a link to a GitHub repo or a photo and be able
| to quickly say something in the same sheet without having
| to switch to the app and say the thing and the back to my
| browser
|
| edit: had to use YouTube in the end:
| https://www.youtube.com/watch?v=eUPJ9zFV5IE
| moffkalast wrote:
| Unfortunately, no one can be told what the Matrix is. You have to
| see it for yourself.
| jimlongton wrote:
| I hope their security is better than in 2019 when the French
| Tchap service based on Matrix was immediately compromised by a
| trivial attack [1].
|
| Matrix.org has also been breached in the past [2].
|
| That's ignoring the fact their project was born out of a company
| that operates front offices for one of the world's most
| aggressive spy agencies...
|
| [1] https://medium.com/@fs0c131y/tchap-the-super-not-secure-
| app-...
|
| [2] https://matrix.org/blog/2019/04/11/we-have-discovered-and-
| ad...
| Arathorn wrote:
| 1. The Tchap issue was specific to the French deployment,
| rather than being a bug in Synapse or anything Matrix specific.
| (It was actually a bug in python, fwiw:
| https://bugs.python.org/issue34155. Agreed that it should have
| been caught internally though)
|
| 2. Yup, unfortunately matrix.org got pwned 4 years ago.
| (Thankfully E2EE means that encrypted conversations weren't
| compromised). This was a (bad) sysadmin fail; again, nothing to
| do with Matrix, the protocol, or the implementations (and the
| rest of the network was of course unaffected).
|
| 3. I've never seen any evidence of Amdocs being involved in
| spying, and many of the accusations there seem to be rooted in
| antisemitism. They acquired the two companies (one UK, one
| French) which turned into Matrix in 2010; we span out and set
| up Element in 2017.
| preya2k wrote:
| Got a source for that third claim of yours?
| jimlongton wrote:
| https://en.wikipedia.org/wiki/Matrix_(protocol)#Funding_Cris.
| ..
|
| AMDOCS has been accused multiple times of being an extension
| of Mossad, including in the US where the investigations got
| quietly ended. Leaked cables from 2009 showed they were also
| on the radar of South Africa's intelligence agency [1].
|
| [1] https://www.news24.com/news24/spy-cables-were-israeli-
| spies-...
| preya2k wrote:
| Thanks for the links! It is very interesting, but I', not
| sure how/if what kind of influence this has on Matrix. Just
| because they were born out of a shady company, doesn't
| invalidate the project. Heck, we're using software
| (Disassemblers) that are maintained by the NSA (Ghidra)
| these days. Since they are open source (just like Matrix
| and Element) we can still be pretty sure that they're not
| doing anything shady.
| kitkat_new wrote:
| > Just because they were born out of a shady company
|
| shady because of accusations?
| jszymborski wrote:
| I think that last claim deserves a citation.
| [deleted]
| Loic wrote:
| For my company, we are using an hosted offer from Element.io[0].
|
| It works wonderfully, it became a really nice hub of
| communication, information sharing with dedicated rooms for
| different stuff (CI/CD, link sharing, planing, etc.) and the
| service has no downtime I can remember in the past year.
|
| Highly recommended and this funds indirectly the development of
| Matrix.
|
| [0]: https://element.io/pricing
| benatkin wrote:
| That seems like a pretty good open-core project with the core
| under the Apache 2.0 license. Still, unlike GitLab, I haven't
| heard of many running their own custom Element and until I do
| I'm a bit wary of lock-in.
| IceWreck wrote:
| Really ? I have been self hosting for atleast three years.
|
| Dendrite, conduit and synapse - matrix homeserver software
| (you have to use one of them) have thousands of stars.
|
| I'm pretty sure atleast 10k+ matrix homeserver deployments
| exist - maybe someone from matrix.org can give a better
| number because each homeserver is probably federating with
| theirs.
|
| And thats to say nothing of unfederated servers i.e. orgs
| hosting matrix for internal use.
| kosciak9 wrote:
| [dead]
| Arathorn wrote:
| How can you get locked into an open protocol?
| benatkin wrote:
| By getting locked into tools on top of it.
| camgunz wrote:
| I think generally the point here is: if you're worried
| about getting locked into a totally open ecosystem,
| there's nowhere for you to go.
| benatkin wrote:
| I specifically mentioned something that I was more
| comfortable with: GitLab
|
| So I don't know where you got "there's nowhere for you to
| go" from.
|
| Element has open source apps and that's great. It just
| seems to not have a very strong culture of people self-
| hosting it. Though one comment did provide me a place to
| look and I found this and am now more comfortable with
| it. https://schildi.chat/ Still it would be great to see
| it have some big instances like GitLab does with Debian,
| Freedesktop, and others. Then I wouldn't feel I was going
| it alone if I self-hosted it.
| camgunz wrote:
| Oh! Well, a couple things:
|
| - Matrix is the protocol, Element is confusingly both the
| hosting service and the mobile app, and Synapse is the
| server -- just to get terminology right
|
| - Matrix actually does the "multiple clients" thing
| really right [0]
|
| - I think a lot of people self-host; I did and there are
| a few others in this thread. It's easy if you've any
| experience hosting web API servers. A core Matrix goal is
| to be decentralized, so self-hosting is thus also a core
| goal. You can see docs here [1], or docs for Docker here
| [2] if that's your thing.
|
| [0]: https://matrix.org/clients/
|
| [1]: https://matrix-org.github.io/synapse/latest/
|
| [2]: https://github.com/matrix-
| org/synapse/tree/master/docker
| Arathorn wrote:
| Like https://element.debian.social for instance? ;)
| benatkin wrote:
| Yeah that's pretty good. Not quite to where GitLab is,
| but in the right direction. GitLab is really helpful with
| self-hosting.
| andrewshadura wrote:
| What do you mean not quite? There are much more options
| than with GitLab, and a lot of people are self-hosting it
| actually.
| benatkin wrote:
| I mean Element's website says very little about
| installing it and encourages using mobile apps which
| require going through the app store, while GitLab has all
| kinds of resources for self-hosting. They do try to steer
| you to self-hosting the ee version though.
|
| Element: landing page https://element.io/solutions/self-
| hosted-or-cloud-collaborat...
|
| GitLab: all the things https://about.gitlab.com/install/
| at the bottom is the Debian package, but if you go to the
| Docker Page and click the username you can see gitlab-ce
| there as well.
| derin wrote:
| Gitlab and Element's website structure is different.
| element.io is the site for the managed product, so even
| their "on-premise" installer is meant to be used in a
| commercial relationship. For install docs you'd probably
| have to purchase their product (which isn't available
| freely).
|
| You probably want to read the open-source software's
| installation instructions at: https://github.com/vector-
| im/element-web
|
| TLDR, check out the project, run `yarn install`, then
| edit the config file, then `yarn build`.
|
| And, yes, that is all there is to it. It's
| _significantly_ simpler to deploy than GitLab.
|
| Finally, you keep mentioning self-hosting; you _can_ just
| use a non-self hosted application like the downloadable
| version of Element, SchildiChat, Fluffychat, or any other
| client.
|
| No reason to bring hosting into the mix for the client,
| if that's causing concern.
| benatkin wrote:
| Using an official build of element makes it feel less
| open, unless the builds are reproducible. Are they?
|
| To me it looks like they come with proprietary stuff:
| https://element.io/pricing
|
| Especially Group Sync seems like something to drive you
| into their paid offerings, I assume by keeping the code
| close to the vest.
| Ambroisie wrote:
| I run my own self-hosted synapse (backend) and element
| (front-end).
|
| It's been working flawlessly since I deployed it (about 2
| years ago now).
| fiddlerwoaroof wrote:
| There's lots of element instances out there and alternative
| clients like Cinny. What's harder to duplicate is the
| homeserver, Synapse. But even there there's also Dendrite
| benatkin wrote:
| Well, I haven't heard of any and your comment doesn't help
| me to find any. I had heard of Cinny but currently I am
| assessing Element.
| ripdog wrote:
| matrix.org has a listing of clients. There are plenty if
| you only need basic features, but Element is the only
| feature-mostly-complete client.
| benatkin wrote:
| I had to look up each of them. This looks to be the only
| one that is based on Element:
|
| https://schildi.chat/
| ripdog wrote:
| Is it a requirement that you use an Element-based client?
| benatkin wrote:
| No, but since Element led by some of the same people as
| Matrix, I want to observe the type of open core project
| it is. Is it more like GitLab or more like Supabase?
| GitLab has a lot of help for self-hosting, while with
| Supabase if you want to run its components on your own
| it's up to you.
| andrewshadura wrote:
| Unlike GitLab, Matrix is not open core, and so isn't
| Element or Synapse, they properly and fully open source.
|
| Also, Element is just some JavaScript in your browser or
| electron shell, there's no need to self-host it really,
| although you can (just put some HTML+CSS+JS up on a
| webserver) -- you want to self-host Synapse, and that's
| trivial to do (there's a Debian package, a Docker image
| and so on).
| benatkin wrote:
| > Matrix is not open core
|
| I'm comparing Element.
|
| > and so isn't Element
|
| It sure seems to be. Look at the red X's and green
| checkmarks in the comparison: https://element.io/pricing
| There are different opinions on what Open Core means
| though.
| fiddlerwoaroof wrote:
| The whole point of matrix, though, is that it's an open
| protocol. If Element were proprietary, that wouldn't be
| the same sort of problem as we have with discord/slack
| because anyone could just implement the protocol
| according to the specs and be an equal participant at the
| table.
| riedel wrote:
| This is a list of public home server instances:
| https://joinmatrix.org/servers/
| benatkin wrote:
| Great, thanks. I didn't think to look there since a
| Matrix homeserver is a different thing, but that shows a
| bunch of self-hosted Element instances!
| mcronce wrote:
| Conduit as well, although AFAIK it's not an "official"
| homeserver, while Dendrite is
| zamalek wrote:
| Conduit was pretty straightforward to set up, I just have it
| running with podman+systemd. It also works great with
| heisenbridge, which is an IRC gateway.
| snerbles wrote:
| I've been self-hosting a federated Matrix homeserver since
| 2018. It's small (about 20 active users), but it was enough
| like Discord and Slack that the less technically-inclined in
| the group have had little trouble adjusting to it. The main
| friction points have been the UI changes in Riot/Element over
| time ("where do I put the homeserver URL thingy again?"), and
| the fact that my friends seem to constantly forget their
| passwords and (this is really a separate issue from Synapse
| itself) setting up an account for transactional emails is a
| pain in the ass.
|
| Amusingly, two of my co-workers from a previous job also run
| their own homeservers, one a smaller private instance similar
| to mine and the other a single-user node that bridges many
| different chat systems together for personal use. The two of
| them also interact with the users on my homeserver on a
| regular basis in various public and private channels.
|
| I should note that only one of the active users in the
| channels on my server is from matrix.org - everyone else is
| from the same server or federated instances run by other
| people. Matrix.org could go down tomorrow and things for us
| would mostly keep running just fine.
|
| I do wish Synapse had a proper account invite system for
| private servers, and not the "spin up a matrix.org account
| and chuck the hapless fool in the hopefully-federated room"
| method that was there the last time I tried.
| dmix wrote:
| How are voice calls?
|
| Edit: looks like there's a 50 user minimum for business plans?
| nehal3m wrote:
| If you host a server yourself you can hook in coturn (it's
| enabled by the linked playbook by default):
|
| https://github.com/spantaleev/matrix-docker-ansible-
| deploy/b...
|
| https://github.com/coturn/coturn
| fenesiistvan wrote:
| How Matrix is better then SIP?
| Arathorn wrote:
| The Matrix team spent 15 years building SIP stacks before we
| gave up and created Matrix, so I can answer this with some
| confidence:
|
| Superficially, Matrix looks a bit like SIP: for 1:1 calls, you
| send an m.call.invite (like a SIP INVITE) to someone; they
| answer with an m.call.answer (like a SIP 200 OK); eventually
| someone hangs up with an m.call.hangup (like a SIP BYE).
| However, the differences are:
|
| * As a transport, everything goes over normal Matrix signalling
| (by default HTTPS+JSON) rather than SIP's mix of UDP and TLS
| sockets. As a result, no need for SIP's three-way handshakes
| inherited from its UDP transport
|
| * As a result, you inherit Matrix's end-to-end-encryption and
| decentralisation for free (so no special Routes, Vias, Record-
| Routes, branch parameters etc from SIP - it uses the Matrix
| client-server and server-server APIs over HTTPS instead)
|
| * Everything is trickle ICE by default for rapid call setup, no
| need to wait until you have all the ICE candidates to proceed
| with the call
|
| * No offerful/offerless invites: everything is offerful.
|
| * Matrix piggybacks on WebRTC for its media protocol, so you
| don't have the fragmentation of different media transports that
| SIP has inherited
|
| * Matrix (as of https://github.com/matrix-org/matrix-spec-
| proposals/blob/mat...) now supports multiparty native VoIP
| calls in the same conversation: effectively letting you signal
| full-mesh, SFU and MCU style multiway video/voip using the
| _same_ mechanism as you 'd use for a 1:1 call. This is probably
| the biggest difference in the end: with Matrix's VoIP you can
| jump straight in and have interoperable Zoom/Teams/Jitsi style
| conferences (as shown in the OP at
| https://youtu.be/eUPJ9zFV5IE?t=1513) - Matrix isn't just for
| boring old PSTN/PBX-style 1:1 calls, but for the conferences
| folks actually expect to use today.
|
| You can play with it at https://call.element.io, and if you
| _really_ want to compare with SIP, go to the developer tools in
| options and turn on callflow mode, which will draw little
| mermaid sequence diagrams of the call signalling for the calls,
| so you can see precisely what 's going on :)
| chagaif wrote:
| I'd be curious to hear what would be something that SIP is
| actually better than Matrix at, any ideas? :)
| the_duke wrote:
| Video not available yet?
| neilv wrote:
| What are the implications of these changes for someone else
| wanting to make an interoperable Matrix server or client from
| scratch?
|
| Will it be easier than before?
|
| (I've written several IRC clients, and a simple one could be done
| in an afternoon with only a sockets/TLS library. But when I
| looked at Matrix briefly, implementation seemed very big-moat.
| And now it's a rapidly moving target.)
| Arathorn wrote:
| Matrix clients should be _super_ easy to write - e.g.
| https://news.ycombinator.com/item?id=20948530
|
| Servers are definitely harder - it's probably similar
| complexity to writing a git implementation (given it's
| basically doing the same operation: synchronising DAGs of
| commits between replicas of a chat room).
|
| In terms of it being a rapidly moving target: from memory we've
| never broken backwards compatibility on Matrix since day 1 back
| in 2014. "Matrix 2.0" is not a breaking change; it's just
| adding some new APIs to change performance to be O(1) rather
| than O(N) (and switching to OIDC for auth and native VoIP for
| multiparty).
|
| So, overall, I'd say it makes things easier: both Matrix client
| & server authors will no longer have to mess around
| implementing custom auth (which was a _huge_ burden to get
| right), but be able to use existing mature OIDC
| implementations. Meanwhile, the new sync API should be as easy
| as the old one (although we haven 't really done a like for
| like comparison yet, given we've been obsessing about driving
| the new sync API as efficiently as possible)
| UltimateEdge wrote:
| > "Matrix 2.0" is not a breaking change Was there really no
| better name for the talk?
| abnercoimbre wrote:
| I must acknowledge I was very spooked by the 2.0 in there
| justeleblanc wrote:
| Semver does not apply to everything, and definitely not to
| end products aimed at consumers.
| palata wrote:
| Except that Matrix is a protocol, and the end products
| using it may like to know that v2.0 (which says "I'm
| breaking backward compatibility") is actually not
| breaking backward compatibility.
| neilv wrote:
| I don't see the end-to-end encryption there. Nor any of the
| other tablestakes features.
| Arathorn wrote:
| Well, if you want end-to-end encryption, then obviously
| that's going to be hard to write from scratch(!) -
| especially if you want it to be secure. However, we make it
| trivial to get up and running by piping your client through
| a proxy like Pantalaimon (https://github.com/matrix-
| org/pantalaimon/) which takes your normal traffic and makes
| it E2EE.
|
| Not sure which "any of the other tablestakes features" you
| have in mind... obviously if you want loads of features,
| then you're going to have to write a whole bunch of code to
| implement them in your client, or build on an existing SDK
| like matrix-bot-sdk, matrix-rust-sdk, matrix-js-sdk etc.
| Not sure that's a disadvantage of Matrix though(!)
| neilv wrote:
| I recall the selling point of Matrix being security.
| (Otherwise, we could just use IRC.)
|
| The conventional IETF-ish Internet ideal of open
| standards is to have a specification that is
| implementable.
|
| When the selling point is security, insecure
| implementations don't help us.
|
| Suggesting an off-the-shelf proxy kludge doesn't clearly
| answer how implementable it is.
|
| Sounds like you're saying that the protocol (with
| necessary security) is hard to implement. Do the new
| changes affect that one way or the other?
| lxkdldls wrote:
| Modern XMPP+OMEMO has a stronger security story and isn't
| controlled by a single corporation with a CEO who can't
| help but get involved in every HN thread about his
| product, and there are multiple working clients for every
| platform, which is something Matrix can barely claim
|
| Of course "Arathorn" would say it's easy to implement a
| client for the protocol he controls unilaterally, it's in
| his interest to get you locked in!
|
| There is one cross platform client for matrix and it
| drives the features: element
|
| I say this from a place of current experience, as I run a
| server and use element and fluffy chat, each of which has
| its own issues. If it's so easy, where are the others?
| Why is there only one third party home server available
| that is only partially implemented? XMPP offers at least
| three to choose from. Now /that/ is a real protocol
|
| There is zero benefit for choosing matrix over XMPP
| bobthebuilders wrote:
| [flagged]
| camgunz wrote:
| NB: I can't seem to watch or download the videos
| ehPReth wrote:
| here's a YouTube alternative; the files on the ftp.* host seem
| to be 0 bytes: https://www.youtube.com/watch?v=eUPJ9zFV5IE
| camgunz wrote:
| Fab, thank you!
___________________________________________________________________
(page generated 2023-02-13 23:00 UTC)