[HN Gopher] Matrix 2.0: The Future of Matrix
___________________________________________________________________
Matrix 2.0: The Future of Matrix
Author : jrepinc
Score : 380 points
Date : 2023-09-21 15:53 UTC (7 hours ago)
(HTM) web link (matrix.org)
(TXT) w3m dump (matrix.org)
| wkat4242 wrote:
| There's no web version of element X though? It's what I use most
| of the time. I'll try the Android app anyway, I've been having a
| really annoying bug with the normal one anyway that hasn't been
| fixed for a year. So perhaps X doesn't have it.
| Arathorn wrote:
| Element X works pretty well on macOS as a desktop client if you
| have an Apple Silicon Mac. Otherwise, the big Element Web
| rework is yet to happen.
|
| On Android, I can almost guarantee your bug will be fixed:
| Element X Android doesn't share any code with Element Android
| at all, as far as I know (given the former is mainly written in
| Rust, and the latter is all Kotlin)
| wkat4242 wrote:
| Ah ok no I don't have a Mac, I use FreeBSD :)
|
| And thanks I'll try that out!! I really hope it fixes that
| sync bug. Thanks for all your work on it. It's a great
| platform.
| fladd wrote:
| Yes, I was also surprised that the new features are only for
| phones. I guess aiming to be "better" than other chat apps
| (with the others nowadays being Whatsapp and co) means to be
| "mobile first"... _sigh_
| abdullahkhalids wrote:
| Is Matrix simple enough now that I can invite my grandpa/grandma
| and they will be able to join?
|
| How does ease up sign up and use compare to discord?
|
| Assume that I make the choice of which client to direct them to.
| soupbowl wrote:
| It is less simple than discord and I does not have good audio
| rooms. I setup family accounts and store their security key for
| them. Then I help them setup their app in a few minutes and
| paste them their security key once they are on my matrix
| server.
|
| In the past I left sign up and setup to family and the element
| app and it has never worked smoothly. They don't understand the
| security key purpose or verifying clients.
|
| So to answer your first question, yeah you can invite grandma
| and grandpa but they probably will need some hand holding at
| the start. Once they are in, it just works(tm)**. YMMV
| masfuerte wrote:
| My octogenarian mother uses it.
| airstrike wrote:
| Did she set it up herself?
| masfuerte wrote:
| No, but that's true of all the software she uses.
| Arathorn wrote:
| Matrix itself is a protocol, so is as hard or easy to use as
| the client that you use to access it.
|
| Matrix 2.0 is all about demonstrating that a really really
| fast, mainstream-grade app can be built on Matrix, in the form
| of Element X: https://element.io/blog/element-x-ignition/.
| However, right now Element X is intended for existing Matrix
| users - so unless you have a bleeding edge homeserver, sign-up
| doesn't work yet. So it's not quite in grandma/grandpa
| territory yet... but once you're in, it most certainly is.
| eviks wrote:
| Do they also plan to ditch the desktop Electron version for the
| users to enjoy similar performance improvements?
| Arathorn wrote:
| Element X actually runs really well on macOS already on Apple
| Silicon; I regularly use it as my desktop app whenever Element
| Web is having... issues. It would be amazing to plonk matrix-
| rust-sdk into Element Web and switch Electron for Tauri or
| something... but one thing at a time.
| fabrice_d wrote:
| It would be nice to provide first class support for state of
| the art web clients (both desktop and mobile). That would fit
| your opening stance of "Matrix has been going for over 9
| years now, providing an open standard for secure,
| decentralised communication for the open Web" more than apps
| tied to the iOS/Android app ecosystems.
| chamik wrote:
| This is an amazing step in the right direction. I host a small
| conduit server for a friend group and I can't wait for the
| improvements this will bring as a whole!
|
| Good work.
| internetguy wrote:
| Awesome! I've been using matrix on and off for around 3 years and
| I absolutely love it.
| kibwen wrote:
| Techy friend group of mine migrated from Discord to a self-hosted
| private Matrix server a few months back. No complaints so far,
| although we didn't use Discord's voice/video/screen-sharing
| features (which I hear that Matrix intends to support
| eventually).
|
| UX-wise, it made me appreciate the distinction between Discord's
| "everyone is subscribed to every channel in a server by default"
| stance, and IRC/Matrix's opposite approach. The latter certainly
| scales better, but the former is so, so much better for
| discoverability, so it's probably the better default for small
| servers.
|
| And if you're looking for a Matrix client with a Discord-like UI,
| try Cinny.
| Arathorn wrote:
| The plan on Discord-style voice/video/screensharing features is
| Element Call (https://call.element.io) which is built to be
| embeddable into Matrix clients. It's already in Element X, and
| is in Element Web/Desktop behind a labs flag. Meanwhile you can
| always embed Jitsi.
| preya2k wrote:
| Once more, Kudos to Arathorn/Matthew (the head of Matrix/Element)
| taking the time to answer most Hacker News comments, as he mostly
| does for all Matrix-related HN threads.
|
| It's really nice to see him answer in a calm and mostly objective
| tone while people are blaming him for shortcomings and problems
| of all the different Matrix-related software projects. Admitting
| to failures and problems that Matrix definitely has, while still
| defending the overall project and giving insight into the status
| of MSCs/projects is admirable.
|
| Thank you Matthew. I wish you an endless amount of patience for
| the future.
| Arathorn wrote:
| thanks :) sorry for monopolising the thread, but it's too
| tempting when I have the answers to hand, for better or
| worse...
| preya2k wrote:
| Looking forward to your talk tomorrow in Berlin.
| Arathorn wrote:
| if I get there; my flight just got cancelled...
| jacooper wrote:
| Which talk? Is there a link?
| preya2k wrote:
| This one: https://summit2023.matrixmeetup.de/conference/t
| alk/AXGMEA/
|
| Don't think there's a live stream. But there might be a
| recording afterwards.
| Arathorn wrote:
| There should be a live stream. (And I might even make it
| there in time to give the talk).
| [deleted]
| noname120 wrote:
| Oh wow congrats to the entire team for this amazing achievement!
| And the cake under the cherry is... Element X is open-source as
| well[1][2]!
|
| I really can't wait for Beeper[3] to rebuild their fork on top of
| Element X (it's currently based on Element, formerly called
| Riot). When this happens it will be an absolute game-changer for
| the messaging ecosystem.
|
| --------
|
| [1] https://github.com/vector-im/element-x-ios
|
| [2] https://github.com/vector-im/element-x-android
|
| [3] https://www.beeper.com/
| Arathorn wrote:
| Beeper don't seem to like Sliding Sync, for whatever reason, so
| I wouldn't hold your breath on it ;)
| 16 wrote:
| From what I understand, the Beeper team has invested a lot of
| time and effort (and code!) into their own "make matrix go
| vroom" solution which also benefits their complex bridging
| system, and I imagine it would take some significant
| engineering time to unravel it for sliding sync.
| smashah wrote:
| Matrix is great but when is the tech industry going to deal with
| the fact that many, if not all, bridges are against the
| respective services' ToS and subsequently put the developers of
| those bridges under legal risk? Whatsapp has already sent legal
| threats to multiple bridge-component level project maintainers
| without any recourse.
| [deleted]
| progval wrote:
| The EU just designated Whatsapp as a gatekeeper under the
| Digital Markets Act:
| https://ec.europa.eu/commission/presscorner/detail/en/ip_23_...
| following the "full list of do's and don'ts" link on that page:
|
| > Gatekeeper platforms will have to:
|
| > - allow third parties to inter-operate with the gatekeeper's
| own services in certain specific situations
|
| > - allow their business users to access the data that they
| generate in their use of the gatekeeper's platform
| smashah wrote:
| I'm aware of DMAs regs but it forces Whatsapp within 6 months
| to start enabling interoperability. However it doesn't
| provide protection for these existing bridge projects.
|
| open-wa, Baileys, invidious devs are all in the dark as to
| whether or not they're Scott free from their respective C&Ds
| due to this legislation.
| unicornporn wrote:
| This is likely also the sole reason[1] that Meta is
| considering connecting Threads to the fediverse.
|
| [1] https://yiffit.net/comment/498225
| stavros wrote:
| There's a fair amount of silly legislation that gets passed
| in the EU, but forward-thinking (or maybe just here-
| thinking?) laws like these (and the GDPR!) make me glad I
| live here.
| unicornporn wrote:
| A double edged sword[1] for sure.
|
| [1] https://edri.org/our-work/why-chat-control-is-so-
| dangerous/
| stavros wrote:
| Yes, those are the silly bits, sadly.
| klabb3 wrote:
| Yeah this is exactly what's needed. At least in EU the
| driver is awake at the wheel. As the politicians slowly get
| more technically competent we're seeing more effective
| regulation. As long as EU has influence, everyone else will
| also benefit since companies often stop doing the shitty
| thing globally, not just in the EU.
|
| Lack of interop has been a huge problem that's also gotten
| worse over time. To address such a broad and complex issue
| with general legislation is not easy, we still have to wait
| and see if it works as intended.
| robert_foss wrote:
| The EU interoperability mandate for messaging services will
| surely improve this situation.
| amstan wrote:
| My Facebook bridge constantly locks up my account. [1]
|
| [1] https://github.com/mautrix/facebook/issues/236
| derin wrote:
| You should use your bridge off of a residential IP in the
| same city as your other devices, or else Facebook finds the
| activity suspicious.
| smashah wrote:
| I strongly believe users should be able to automate and
| interact with their accounts through whatever clients they
| wish however I think blocks/bans/technical countermeasures is
| fair game.
|
| Count yourself lucky for not having an undeterminable,
| unfightable legal threat over your head from a $800bn mega
| corp.
| rabbitofdeath wrote:
| I love matrix - I've been running a Synapse homeserver for over 2
| years now for friends and family. We love it. Despite minor
| problems (upgrading postgres for example) it has been smooth
| sailing. I really want to stay up to date but they don't make it
| easy! I'd love to add sliding-sync to my existing docker stack,
| but I feel like I'm in way over my head!
| geek_at wrote:
| I love the idea of matrix (synapse + element + mobile apps) and
| I have started moving my family there too but we had so many
| problems with notifications not being sent to the phone unless
| you actively open the app.
|
| There is a huge discussion about that on git and some can't
| reproduce, some can't get a single notification even though the
| apps notification checkmarks were all green.
|
| So it had a very very low WAF [1] and I scrapped it sadly. This
| was a few years ago, any signs of these problems still
| existing?
|
| [1] https://en.wikipedia.org/wiki/Wife_acceptance_factor
| soupbowl wrote:
| I had this problem 2 years ago and it ended getting fixed.
| Recently I seen it again and the problem was that my
| container running synapse did not have working DNS which
| caused all notifications to stop working. Once I fixed up
| resolv.conf all was working.
|
| I am not suggesting that was your issue but it might help
| somebody.
| Arathorn wrote:
| Hmm... we haven't had notification problems like that in many
| years, from memory. Any idea if this was trying to deliver
| push notifs to Android without using Google? (Which
| historically has been painful thanks to Android OS versions
| terminating the app in the bg).
|
| Element X has totally rewritten notification code (given it's
| moved from Kotlin to Rust) and should be much more robust for
| bugs like this.
|
| Sorry you got bitten by it.
| xorcist wrote:
| Communicating via Apple or Google is sadly required these
| days. How does that work with matrix? Does the protocol
| specify how to trigger those notifications? Do I need to
| register for a Google API key when setting up the server? I
| can't recall seeing anything about that in the
| configuration file.
| Arathorn wrote:
| https://thomask.sdf.org/blog/2016/12/11/riots-magical-
| push-n... is a great blog (back when Element was called
| Riot) explaining how it works :)
| xorcist wrote:
| The gist of it seems to be that Synapse/Dendrite calls
| home to the Matrix Company, which in turn pays Google to
| send a notification. That's awfully nice of them, but
| does not really leave any room for success. I take it
| larger clients with security requirements roll their own
| clients, and this is part of the business case?
| Arathorn wrote:
| It's more that "whoever built your client has the keys to
| send push to it, so your synapse calls home to them." And
| yes, that means that paranoid types need their own
| clients, and that is indeed a service that Element
| offers.
| btobolaski wrote:
| Doesn't the use of ntfy change this (Android only, I
| think)? Homeserver pushes to an ntfy topic, app on phone
| is listening to that topic. Of course, this just moves
| the intermediary to ntfy but you can also host a
| different ntfy server which I hope element supports.
| derin wrote:
| It does. I use ntfy with a ntfy server on one of my VPSs,
| and I use the official ntfy account on GMS as an
| intermediary.
|
| It works fine, but I'll probably switch back to Matrix's
| push server at some point.
|
| Edit: With Synapse + Element, obviously.
| xorcist wrote:
| Thanks for sharing. Are you switching back because of
| pricing, or reliability issues?
| Twirrim wrote:
| If any of those are android users, it may be down to the non-
| android standards friendly battery optimisation the
| manufacturer ship their devices with (e.g. Samsung, Huawei,
| OnePlus, Xiamoi, etc.)
|
| https://dontkillmyapp.com/
|
| I've had more issues with missing notifications on my OnePlus
| than I ever had on my Pixel (I have list of reasons why I'll
| never buy Google hardware again, mostly coming down to their
| support). Most issues get fixed by me persuading OnePlus to
| stop applying their secret sauce to power control
| amatecha wrote:
| Regular reminder Matrix/Element work closely with law-enforcement
| to provide encrypted comms for them. It's a sector Matrix/Element
| actively markets to and deals with. My personal view is I'm not
| using a chat platform designed/developed by an organization so
| eager to partner with governments and law enforcement agencies.
|
| There's Element's Chief Product Officer & Managing Director
| presenting at the European Police Congress[0]:
| https://mastodon.matrix.org/@element/110310853505977058
|
| And a quick post about their excitement at participating in this
| conference:
| https://mastodon.matrix.org/@element/110304013472307767
|
| I mean, whatever, it's just doing business, right? When someone
| criticized this, they gave a snarky, surprisingly unprofessional
| response: https://mastodon.matrix.org/@matrix/110334695988903649
|
| Dunno about anyone else but my trust in them is just gone. I'm
| not saying you have to care (and I don't care if you do). I'm
| sharing this for the people who _do_ care, and don 't want to use
| "secure messaging" made by people who actively market to and
| collaborate closely with law enforcement and governments.
|
| [0] https://www.european-police.eu/
| soupbowl wrote:
| I don't really see the problem here, I would prefer my local
| government use open standards that are secure. If they are
| weakening the crypto to help the police and government come
| after me then I would have a problem.
| nobody9999 wrote:
| >Regular reminder Matrix/Element work closely with law-
| enforcement to provide encrypted comms for them.
|
| Thank you for the reminder. Based on that, are you claiming
| that Matrix servers/clients are insecure or have government
| back doors?
|
| If so, what evidence do you have that supports such a claim?
|
| If not, why should I care? I'm not a fan of many
| organizations/individuals. Should I survey them all to create a
| database of software those folks use and refuse to use any
| software they use? What value would I derive from such actions?
|
| Unless you're claiming the former (evidence please), what
| difference does it make? I use Matrix servers/clients only on
| hardware that's under my _physical_ control. And I use free
| (libre and beer) versions of Matrix implementations, so I 'm
| not even giving the developers any money.
|
| Or are you making the argument that LEOs _shouldn 't_ have
| access to secure communications protocols?
|
| I guess I'm confused because I don't understand what the issue
| might be. If you'd elucidate, I'd much appreciate it!
| amatecha wrote:
| I didn't claim/assert anything other than what I linked to
| already in my original post.
|
| You don't have to care, and like I said, I don't care if you
| care or not. I'm just making people aware, because some
| people _do_ care.
|
| It's nice that you personally use matrix on hardware under
| your physical control. That's rare. The vast vast majority of
| matrix users have their account on matrix.org and are using
| Element. I'm glad to hear you are using alternative server
| and client software.
|
| I addressed the other questions at
| https://news.ycombinator.com/item?id=37602089
| nobody9999 wrote:
| Since you didn't actually answer the question "why should I
| care?", perhaps you might deign to answer _these_ instead:
|
| >>I'm not a fan of many organizations/individuals. Should I
| survey them all to create a database of software those
| folks use and refuse to use any software they use? What
| value would I derive from such actions?
|
| Why are those useful questions? Pick some software -- any
| software in wide use -- and you'll find that _someone_ you
| find objectionable is using such software.
|
| That includes OS's, browsers, databases, web/application
| servers, BIOS firmware, chat clients/servers, etc., etc.,
| etc.
|
| If using software that's also used by someone whose actions
| and/or rhetoric are objectionable to you is "capitulation"
| to those with whom you oppose/disagree, then you should
| power off all your electronic devices, smash them into
| little pieces and never look back.
|
| But (IMHO, at least) taking such a position takes "guilt by
| association" to ridiculous extremes, _especially_ when
| talking about open source software that can be audited and
| modified to suit your purposes.
|
| Don't want your sensitive information shared? Don't share
| it on platforms not under your control. Full stop.
|
| I'll say it again[0], "three can keep a secret. If two are
| dead." Food for thought, no?
|
| [0] https://news.ycombinator.com/item?id=37602606
| skeaker wrote:
| When someone asks "why should I care," the implication is
| that they want to know why you care. Dodging the question
| here is an interesting way to respond
| amatecha wrote:
| People who want to work closely with authorities probably
| shouldn't be trusted to provide your secure communication
| software.
| cvwright wrote:
| You are mad that they took money away from someone you don't
| like?
|
| And moreover that they used this money for something that you
| do like?
| Smaug123 wrote:
| "Taking money" is a very poor description of a trade, which
| both parties chose to enter into because they both expect to
| derive benefit from it. What the parent objects to is
| presumably the "government/police/military expects to derive
| benefit" part, not the "taking money" part per se.
| kevincox wrote:
| I find no issue that the company is working with law-
| enforcement to provide secure communications. In fact this
| makes me feel better about the security of those communications
| as they are trusted by these governments (not that this is a
| huge mark of quality, but I would consider it positive).
|
| I your distrust of law-enforcement so strong that any company
| that they purchase from must be untrustworthy? Or is there
| another reason that this bothers you?
| amatecha wrote:
| My concern is in the opposite direction of what everyone
| appears to be interpreting, despite what I thought was clear
| wording in my initial post.
|
| It's not that govt/LE uses Matrix. It's that Matrix/Element
| _actively seeks out partnership with govt /LE_ (to the extent
| of presenting on stage at a police conference), suggesting
| they are particularly interested in a relationship with
| authorities and personally sympathetic to these authorities,
| at the management/director level.
|
| This is not a position I expect from an organization that is
| determined to build secure communications potentially used by
| activists, people living in oppressive/authoritarian regimes,
| etc... If I was a member of such a high-risk group, I don't
| think I would be putting my faith in this org to produce
| something I can actually consider truly secure.
| arkaniad wrote:
| From a personal perspective, I do share some of your
| misgivings about the appearance of sympathies with LE /
| authorities. It doesn't -feel- all that great to see. But
| at the end of the day to me it boils down to what another
| commenter said. If it's good enough for them, it is
| probably good enough for me. Someone has to pay the bills
| so the show can go on.
|
| If the problem is that we're not trusting $LE_GOV_AGENCY to
| use the technology because it may hide abuses of authority,
| the root problem is that we can't trust $LE_GOV_AGENCY for
| reasons external to their choice of communication tooling.
| And that's not a problem I think we can solve with
| technology alone.
|
| Plus, 'We can't allow X/Y/Z to use encrypted chat because
| they could do awful things' is a bit of a double-edged
| sword I personally don't feel comfortable wielding lest it
| be wielded against my own 'high-risk group'.
|
| Disclaimer: SRE at Element, but I've been running a Matrix
| homeserver of my own since before I joined the company
| Arathorn wrote:
| The reason we "actively seek out partnership with govt/LE"
| is simply because they are by far the primary customer
| segment who actually have an clear need for self-hosted
| interoperable end-to-end encrypted communication and are
| willing to pay for it. If we don't find organisations who
| are willing to pay Element for services, then quite simply
| we can't pay people to work on Matrix and Element as their
| dayjob, and the whole thing would switch into best-effort
| volunteer run activity (although I'd presume most of the
| team would feel pretty burnt if that happened and go spend
| their freetime on something else). About 80% of Element's
| revenue comes from public sector, and without it the
| project simply wouldn't exist.
|
| Hopefully, eventually, the rest of the world will wake up
| to the fact that sleepwalking into using Teams and Slack
| (or WhatsApp) is a catastrophe in the making. It's only a
| matter of time before someone publishes a torrent of every
| line of Teams scrollback or Slack scrollback for some high-
| profile organisation; the breach has probably already
| happened; the breacher is just waiting for the best
| strategic moment to drop the information bomb.
|
| But until then, Element makes payroll by selling to folks
| like the French and German Governments, the United Nations,
| etc. They pick Element _because_ it is high trust, and they
| can audit it and run it themselves. And there is
| categorically no way that I or other senior management at
| Element would destroy the company (let alone Matrix) by
| breaking that trust by letting someone undermine its
| privacy.
|
| Which is why we're in the surreal situation of on one hand
| selling to the UK Government, while also frantically
| criticising them for the catastrophic idiocy of the Online
| Safety Bill: https://element.io/blog/the-online-safety-
| bill-an-attack-on-....
|
| Separately: I'm literally years overdue in publishing
| Element's internal ethics guidelines publicly, which spells
| out precisely who we do and don't do business with. For
| what it's worth, the high level summary is:
| * We don't sell to criminals (under UK/US/EU law)
| * We don't sell to sanctioned (by UK/US/EU) or abusive
| govts or organisations * We don't sell to orgs
| who explicitly encourage use which goes against our terms
| of service.
|
| Our definition of abusive governments/orgs are those who
| commit human rights abuses or, who commit international
| atrocities (as defined by the UN), or contracts which
| primarily support the above.
|
| Most western governments (including their police forces) do
| not fall into this bracket.
| skeaker wrote:
| I would guess the reason for that would be that those
| platforms are willing to pony up real cash and the actual
| communication protocol itself is no less secure when they
| use it. See also: Tor, famously developed/funded by the
| government
| nobody9999 wrote:
| >If I was a member of such a high-risk group, I don't think
| I would be putting my faith in this org to produce
| something I can actually consider truly secure.
|
| If I were in such a high-risk group, I wouldn't be putting
| my "faith" in anyone. Rather, I'd personally make damn sure
| my sensitive communications couldn't be spied upon.
|
| I'd also point out that repressive/authoritarian regimes
| don't care about the rule of law and/or personal privacy,
| so they can just come to your house and take you away
| without any proof that you're working against the state.
|
| What's more, they can also confiscate any systems/devices
| you (or others) may have in an attempt to discover the
| identities of your "co-conspirators." And they can torture
| you to give up those names, even if the names you give up
| aren't actually involved at all.
|
| You seem to believe that there's some sort of magical
| software that can keep someone safe if a government or
| well-funded private actor wants to get you. News flash:
| there is no such animal.
| panick21_ wrote:
| Really strange Point of View. Governments adopting open
| standards rather then paying money to US tech companies is a
| good thing.
| __s wrote:
| What's the problem with e2e encryption for those organizations?
|
| The problem is if they give those orgs a backdoor
| amatecha wrote:
| Oh yeah, I actually asked them about that. They said there
| aren't any backdoors[0]. We're all good, no worries! :) :)
|
| [0] https://mastodon.matrix.org/@element/110340953550548309
| panick21_ wrote:
| Its open source and the crypto library is also 3rd party
| verified. I don't get your problem.
| thomastjeffery wrote:
| It's one of the most significant _open source_ messaging
| systems that exist today. Anyone can audit it at any time.
|
| What more do you want?
| amatecha wrote:
| How do you know the matrix.org server or the element.io
| web client is running the same code as the source posted
| publicly? How exactly do you, personally, audit a hosted
| service? The answer to both questions is: you don't.
| nobody9999 wrote:
| >How do you know the matrix.org server or the element.io
| web client is running the same code as the source posted
| publicly? How exactly do you, personally, audit a hosted
| service? The answer to both questions is: you don't.
|
| And I don't use them. I grab the posted sources and use
| them on hardware I _physically_ control. If (I 'm not,
| but I do care about my privacy) I was someone that was
| being pursued by one or more governments/well-funded
| private actors, I wouldn't use any communication
| platforms hosted by others.
|
| As the old saw goes: "Three can keep a secret. If two are
| dead."
| infogulch wrote:
| So host it yourself. It's literally _designed_ to do
| that.
| amatecha wrote:
| Yeah, that's great for me, but doesn't help me when
| everyone else is using the hosted stuff :)
| beepbooptheory wrote:
| Ok, I'll bite, what even could be the alternative here
| then? You want something without big funders, totally
| OSS, _and_ extremely friendly for grandmas? Feels like
| one of those "you can only pick two" type things to me,
| but would love to learn that's not the case.
| itsanaccount wrote:
| Its fashionable in the leftist world to compete to take
| the most radical position you can.
|
| You described the goal, yeah, that would be pretty
| wonderful, like unicorns, flying pixie dust and other
| things that don't seem to exist as of yet.
| [deleted]
| beepbooptheory wrote:
| I really don't think that is fashionable. Why would
| people want to do that?
| infogulch wrote:
| Also: 1. Mainstream enough for grandma. 2. No public
| hosts, you are _required_ to self host it. Totally
| reasonable I don 't see why this is so hard. /s
| EGreg wrote:
| But that doesn't mean Matrix makes backdoors. So you can use it
| too.
|
| What's wrong with helping organizations including law
| enforcement encrypt their communications?
|
| Because they are public servants and We the Public should have
| ways to be able to decrypt those communications.
|
| Secret meetings and intelligence agencies are what leads to
| totally avoidable wars.
|
| https://community.qbix.com/t/transparency-in-government/234/...
| jazzyjackson wrote:
| Fair enough to share the information but I take the opposite
| tack: if it's good enough for LEOs, good enough for me.
|
| I would also be excited to find paying customers when trying to
| build free software.
|
| In any case I get the feeling if I were to avoid technology
| built by companies with government contracts I would be left
| with my retro 8bit machines. Lets be pragmatic.
| lousken wrote:
| > Rather than exposing a kitchen sink of features and settings,
| we're keeping Element X truly focused: doing one job and
| absolutely nailing it - all while harnessing the power of Matrix
| for secure, interoperable, open-standard communication.
|
| does this mean the Element X is more for the mainstream user and
| regular Element is better suited for power users?
| Arathorn wrote:
| Element X also is geared up for powerusers (e.g. as project
| lead, I consider myself a poweruser) and i've been absolutely
| loving it as my daily driver for the last few months on mobile.
| For instance, my account is in around 4,000 chatrooms, and
| Element iOS was taking ~10s to launch and sync, and could
| easily take minutes to sync in the morning (heaven forbid the
| app was offline for more than overnight). Meanwhile, Element X
| launches in around 100ms, no matter how long it's been offline,
| and syncs in around a second.
|
| The model that we're going for is similar to iOS or macOS:
| something which is incredibly simple for normal users, but can
| also scale up seamlessly for crazy powerusers.
|
| In terms of specific poweruser features: I suspect the strategy
| will be to see if we can provide the same end result without
| actually adding the feature - and failing that, add the feature
| very strategically via progressive disclosure... or perhaps not
| at all, and rely on other Matrix apps to pick it up.
|
| The intention is to fairly rapidly replace regular Element on
| mobile with Element X, eitherway.
| lousken wrote:
| Ok, I understand... one last thing I ask every year - custom
| emojis when? :)
|
| And thank you for your the hard work!
| Arathorn wrote:
| But we just entirely rewrote both mobile clients to get out
| of having to implement custom emojis! :D Joking aside, it's
| easily one of the biggest features missing from
| Element/Element X, and I for one can't wait for it to land.
| Unfortunately we also don't have any paying Element
| customers asking for it, though, which is why it keeps
| getting deprioritised in favour of other stuff.
| dmix wrote:
| Does anyone use Matrix/Element for a serious workplace, instead
| of something like Slack?
| [deleted]
| monlockandkey wrote:
| Does anyone know how to integrate chats into a web app using
| Matrix. Rather than writing a messaging web app from scratch, can
| I hook into matrix?
| [deleted]
| iptq wrote:
| exciting to hear! I only wish i had more time to contribute.
|
| Has there been any movement on migrating away from long polling
| (#475)? I didn't see anything about it in the announcements or
| comments despite such a big milestone
| Arathorn wrote:
| Low Bandwidth Matrix is the answer to that, and it's currently
| on hold unless it gets funded:
| https://matrix.org/blog/2021/06/10/low-bandwidth-matrix-an-i...
|
| It might also get changed as part of Sliding Sync refinement.
| neilv wrote:
| Thoughts on how this will get us towards when libre software
| privacy&security type people are ready to advise friends to move
| to Matrix for personal communication?
|
| (To be clear, the platform has to be all open source and open
| standards, actually decentralized, guided by those principles --
| not an effectively proprietary play even if nominally open. For
| example, you should be able to get all the same functionality
| with Element, Fluffychat, Thunderbird, and other user agents, and
| with any home server, both now and on an ongoing basis. And the
| user agent implementation difficulty should become tractable
| enough, in terms of size&complexity and specification, that one
| person could write a new one -- not like Web browsers have
| become, where there's mainly only one, that company has been
| funding the runner-up, and that company can pretty much dictate
| 'standards'.)
| [deleted]
| Arathorn wrote:
| Matrix 2.0 is a major step towards getting friends & family on
| Matrix.
|
| Firstly, it's not introducing new features - it's just making
| the current featureset work super-efficiently (while retaining
| compatibility with today's Matrix). So there should be no
| fragmentation between Element/Fluffychat/Thunderbird, with the
| possible exception of the new scalable encrypted VoIP
| conferencing (but then very few Matrix clients implemented the
| old VoIP conferencing, plus you can always just embed an
| Element Call instance to get at it now - as Element X does
| today).
|
| Secondly, we're explicitly working to protect Matrix from the
| commercial interests from Element (the company set up by the
| team who created Matrix, of which I'm ceo/cto as well as Matrix
| project lead). We already have The Matrix.org Foundation
| (https://matrix.org/foundation) as an independent non-profit to
| hold the Matrix IP and maintain its neutrality - but we also
| just hired Josh Simmons (former President of the OSI) as its
| independent Managing Director
| (https://matrix.org/blog/2023/09/introducing-josh-simmons-
| man...).
|
| So: going forwards, the Foundation increasingly does not have
| to depend on Element not being evil, but instead has its own
| independent management to ensure the protocol exists to support
| everyone in the ecosystem, without fragmentation, as per the
| guiding principles at https://matrix.org/foundation - under its
| own autonomy.
|
| I'd say this is is good news for libre software privacy &
| security type people, but then again I'm biased. Practically,
| the only thing getting in the way of getting friends & family
| on Matrix is that Element X requires fancy OIDC-native
| homeservers for registration, so newbies won't be able to use
| Element X to join Matrix yet. But the app itself should be an
| excellent way to get folks on board in the very near future.
| em-bee wrote:
| element still has serious usability issues that need to be
| fixed before i can get friends or family on board.
|
| the way threads are displayed in the browser versions makes
| them hard to follow. in our hackerspace, where many are tech
| minded people, i see regular complaints about that.
|
| scrollback to unread messages often fails. i have never had
| another chat application where that was a problem. this
| should just work.
|
| the handling of encryption keys is very confusing. there are
| to many moving parts, it's not clear what i must save so that
| i can restore the keys in a new client.
|
| private rooms are also confusing. i want to have a private
| room be the name of my chat partner, and they want it to
| carry my name. being able to do that would be very helpful.
|
| i am also missing the ability to use a different nickname in
| every room. different groups know me under different
| nicknames. discord and wechat can do it. it would be great if
| matrix/element could do that too.
| Arathorn wrote:
| Sounds like you're talking about Element Web or Desktop
| here. On Mobile, we just rewrote the app as Element X and
| it addresses almost all your concerns (other than per-room
| nicks, although ironically Element Web _does_ have that
| today - try the /roomname command).
|
| Having got Element X out the door, my attention at least is
| going to swing back to Element Web. In terms of encryption
| disasters, we are about to switch Element Web's crypto to
| the same rust implementation as Element X, hopefully next
| week - you can track the progress at
| https://github.com/vector-im/element-
| web/issues/21972#issuec.... Hopefully this will make a
| much-needed massive improvement on encryption, while also
| speeding it up 5x or so. On Element X, encryption failures
| are almost unheard of (other than when talking to Element
| Web).
| _rs wrote:
| Element X is great except for the lack of history, once
| that's added it'll change to my daily driver. I very
| often search my chat history and reference things going
| back months
| mike-cardwell wrote:
| Encryption in Matrix is a nightmare. I set up Synapse and
| pulled half a dozen or so people onto it. We have a few
| chat rooms. Randomly different users clients are unable to
| decrypt the messages of other users clients. You click some
| button about syncing encryption keys, and nothing happens.
| Then randomly a week later you can start reading each
| others messages again. _shrug_ This has been going on for
| years now.
|
| This alone makes Matrix the worse chat platform out there
| from a users perspective IMO. I invested too much effort in
| getting things up and running and using it now though, so
| I'm just hoping that this gets fixed one day, or something
| better comes along that I can migrate to.
| Arathorn wrote:
| Sorry. As per the sibling comment to yours, we made a
| decision on Element Web/Desktop to rip out the old
| encryption implementation and replace it with matrix-
| rust-sdk's crypto implementation about a year ago, and
| while it's due to land next week, it means that some
| folks have had a miserable time in the interim.
| dingnuts wrote:
| I'm curious and extremely skeptical as to how the UX is
| going to be made better regarding the terrible UX
| surrounding encryption. I used Matrix with a non-
| technical family member for about six months before
| giving up and going back to SMS because she frequently
| got messages about encryption that she was in no way
| equipped to deal with, and did not even begin to
| understand (yes, the "user-friendly" key fingerprint
| screen is one of those pain points) and I had to handhold
| her through the process, every time she got a new device
| or similar.
|
| One time I had to manually export and import my own keys
| to be able to read old messages, which was a task that
| would have been too technical for most of the people I'd
| like to chat with, and was supremely annoying for me.
|
| It's just a non-starter. I have a community I've been
| considering moving to Matrix for literal _years_ now and
| there are just so many sharp edges.
|
| I've been confused about Matrix's priorities for a long,
| long time. I am not getting any less confused, to be
| honest.
| Arathorn wrote:
| Well, just as folks might be skeptical about Matrix
| clients ever being as performant as
| WhatsApp/iMessage/Telegram, and yet we eventually got
| there with Element X... I'm expecting a similar outcome
| with E2EE UX.
|
| The high level plan is:
|
| * Fix all the bugs which cause random undecryptable
| messages, which was the main thing causing frustration.
| This is (hopefully) done now by converging on the new
| Rust implementation.
|
| * Generate a recovery key, rather than confuse the user
| by asking them to pick two passwords (one for their
| account, one for their encryption). Impress on the user
| that if they ever want to recover their history, they'll
| need it. Expect that most users will lose it.
|
| * When logging in on a new device, scan a QR code on an
| existing device to transfer over the keys (and thus
| history). Users are used to this now thanks to WhatsApp
| and Discord, and empirically they can do it fine. The
| recovery key is used only as a worst-case scenario if the
| user has no other devices. The act of logging in (either
| via scanning another device, or via recovery key) signs
| that device as owned by you.
|
| * Only accept messages from devices that a given user has
| signed (i.e. trust on first use for users). If you want
| to verify that user out of band, they get an green tick
| too, purely to help you keep track of which users you're
| sure are legit and which users you've assumed are legit.
|
| * At any given point, encryption is either enabled on
| your device (i.e. you've signed that device; it can
| access your encrypted message history; it can store keys
| for your encrypted message history) or it's not (and you
| can't do any E2EE). There are no halfway states.
|
| This may sound simple and obvious when written out like
| this, but each point is a major change from the supremely
| confusing system we have today. The thing stopping us
| from having implemented it sooner is the huge amount of
| effort which went into reimplementing the engine in Rust.
| But having now (almost) finished that project, next thing
| up is fixing the UX, at last. The rough timeline is
| hopefully end-of-year, but, again, timings are contingent
| on funding pressure.
| beanjuiceII wrote:
| so one hand says they are making things better for
| friends and family, and the other is ripping out things
| to make peoples lives miserable? and then letting them
| float in that misery for some period of time?
| dkasak wrote:
| A lot of the problems were caused by the legacy crypto
| implementations. The misery is not caused by ripping them
| out and replacing them with matrix-rust-sdk crypto, but
| by it (unavoidably) taking a while.
| neilv wrote:
| Thank you for the comments. I'll keep my fingers crossed that
| this plays out well.
|
| > _plus you can always just embed an Element Call instance_
|
| That sounds like potentially a commercial
| embrace&extend&extinguish situation, which we need to avoid.
| Arathorn wrote:
| Yup, good call point, which is why we deliberately
| implemented two different independent group VoIP
| implementations - the one in Element Call (based on matrix-
| js-sdk) and the one in Hydrogen (based on hydrogen-web-
| sdk).
|
| Admittedly the new livekit-based implementation takes us
| back down to a single implementation for now, but in its
| defense it's only a few weeks old (with e2ee). Hopefully
| others will spin up independent implementations rapidly -
| although right now it does introduce a potential commercial
| EEE situation... but from on LiveKit rather than Element.
|
| Eitherway, it's something we're painfully aware of... while
| also trying to ensure we find enough $ to pay for dev on
| Matrix (and Element) otherwise the whole thing collapses.
| sneak wrote:
| One of the big problems as I see it is that all notifications
| on iOS must be proxied via APNS and those can only be sent by
| the app publisher, so all home servers must send their iOS
| notifications to Vector (the Element publishers) to be sent to
| APNS and on to an iPhone or iPad.
|
| This is a centralized point for surveillance of metadata. I
| also do not know how much information is actually contained in
| the notification itself. In any case Vector has knowledge of
| every home server with an iOS client, and their approximate
| traffic levels.
| Aerbil313 wrote:
| Then everyone should just roll out their own app... this
| seems like an EU-regulation-needed situation.
| sneak wrote:
| This requires paying about $10/month to Apple and doxxing
| yourself with a lot of PII.
|
| It also requires that you as a homeserver sysadmin a) have
| a Mac, b) install Xcode, c) know how to modify and compile
| iOS applications, d) want to deal with rebuilding and
| reuploading and re-seeking app approval on major API
| changes because long-un-updated apps are not allowed in the
| App Store, etc...
| kevincox wrote:
| FWIW my partner and mother are using it. We have had the
| occasional key synchronization issue with Element but has been
| mostly smooth sailing. I did walk them both through the setup
| but they probably could have managed. However they have some
| basic tech skills. I suspect that others in my family with
| little tech literacy would need to have it set up for them but
| would probably be fine after that.
| brunoqc wrote:
| Rip matrix p2p.
|
| I wonder if they were serious about it, or if it was just
| vaporware (a la Musk) to get more funding. It has been announced
| years ago, they raised millions and they have big governments
| contracts. WTF is going on?
| Arathorn wrote:
| wtf is going on is that:
|
| a) p2p matrix works pretty well as a proof of concept - you can
| try it from https://arewep2pyet.com; it's not remotely
| vapourware.
|
| b) funding has been spent on core Matrix dev and making Element
| kick ass (cf Element X)
|
| c) an awful lot of very large Matrix + Element deployments (eg
| LuxChat in Luxembourg, Merkury 2.0 in the Polish MOD, many
| German local authorities) decide to run Matrix deployments
| without routing a single $ to support development at either the
| Matrix Foundation or Element, such are the joys of the Apache
| license.
|
| As a result, we've had to pause some of the longer-term R&D. I
| very much hope that P2P will resume (especially if someone
| explicitly funds it) and the team is still at Element (but
| working on sliding sync and account portability). But right now
| we're focusing exclusively on fixing the core problems in both
| Matrix and Element which others in this thread are complaining
| about. Hence Matrix 2.0, and Element X.
| brunoqc wrote:
| Thanks Matthew, I always appreciate your comments.
|
| I also do appreciate the Apache license.
|
| Sorry for the vapourware comment. It's hard to tell these
| days. Was the Google self-driving car thing vapourware? It
| never went anywhere.
|
| I know that pinecone worked as a PoC. I ran a node for years,
| for fun. It's just that it always felt like the progress was
| crazy slow. The yggdrasil demo was what, 4 years ago? How
| fucked up will the world be in 4 years? Not that it's your
| fault.
|
| And I care about matrix. I was the one who suggested
| arewep2pyet.com, I made 1-2 friends use it (matrix), I made
| 1-2 coworkers use it.
|
| Also, zulip threads now or I riot.
| Signez wrote:
| > Was the Google self-driving car thing vapourware? It
| never went anywhere.
|
| Well, it goes somewhere: people are actually being driven
| around Pheonix, Arizona [0] using those cars. It's just
| that it is not named "Google self-driving cars" any more:
| it was spun into its own company, Waymo [1].
|
| [0]: https://waymo.com/waymo-one-phoenix/
|
| [1]: https://waymo.com/
| Arathorn wrote:
| The best way to get P2P Matrix back on track is to find
| someone to fund it, and point them at funding@matrix.org.
| Unfortunately it's as simple as that.
| gwd wrote:
| Just poking around matrix.org, it's not clear exactly how one
| would "route [some] $[s] to support development" other than
| paying someone else for a hosted server. Our open-source
| project just switched to using Matrix from IRC; we're not
| really big enough to warrant hosting our own Matrix server,
| so most of us are just using matrix.org. We have some
| industry funding, and try to support other open source
| projects when we can; but not on the order of $250/mo (which
| if I'm reading it right, looks like the cheapest product on
| element.io -- $5/user/mo, min 50 users). If matrix.org
| accepts donations, it's not at all clear from your website.
| Arathorn wrote:
| Well, we need to fix that then.
| https://matrix.org/membership/ and
| https://matrix.org/blog/2023/06/membership-program/ is the
| way to donate.
| panick21_ wrote:
| Its probably the right choice if yo don't have the funds. But
| it s great that that team is working on account portability.
| That would be useful in a p2p world anyway.
|
| Really hoping Full Matrix p2p will happen. Its would be such
| a cool capability.
|
| Governments wasting so much time and money on so much
| nonsense software but we can't support and open communication
| tool.
| beardog wrote:
| Makes me sad that billions got poured into cryptocurrency-
| sphere projects but classic p2p barely scrapes by.
|
| (I mean by society not new vector)
| jazzyjackson wrote:
| money flows to where it can be multiplied, not where it can
| be sunk into some social good
| [deleted]
| contact9879 wrote:
| It's still in development[1]. Seems like p2p will depend on
| dendrite so until dendrite is stable, p2p will not be
| available.
|
| [1]: https://arewep2pyet.com/
| notsahil wrote:
| Synapse already eats up lots of space, adding sliding sync will
| boost it up and will be difficult to self-host it.
| Arathorn wrote:
| Yup, it's true that sliding sync proxy increases disk space
| further, although it's not so bad. A big advantage once it's
| stable and merged into a native homeserver will be reducing the
| storage duplication between the proxy and the HS.
|
| Meanwhile, we _really_ need to get https://github.com/matrix-
| org/rust-synapse-compress-state/pu... hooked up in Synapse so
| that it automatically compresses state; I don't know why this
| never landed when it was written in in 2021 :(
| infogulch wrote:
| I wrote a summary of the post:
| https://twitter.com/infogulch/status/1704933396508553385
| whiterock wrote:
| my biggest struggle with matrix, is that, at least in element-
| ios, messages keep transpositioning, i.e. at some random time a
| message that is 2 days old is pushed all the way down to the new
| messages. also the aop frequently crashes with some media.
|
| but apart from that I of course love the idea of an ,,SMTP
| approach" to instant messaging :)
| Arathorn wrote:
| this is literally why we rewrote element-ios in rust, in the
| form of Element X iOS :) https://element.io/labs/element-x
| whiterock wrote:
| oh that's so cool. will give it a try now! :) really looking
| forward to the search feature btw hehe.
| tptacek wrote:
| Just a question, I haven't been paying attention, but where is
| Matrix on resolving the Nebuchadnezzar vulnerabilities, and is
| the project still tracking towards switching to MLS instead of
| Olm/Megolm?
| Arathorn wrote:
| The main remaining Nebuchadnezzar issue is mitigating server-
| controlled group membership. The first step has been to kill
| off the 1st gen E2EE implementations, which were responsible
| for the implementation vulns found by RHUL - and we should
| hopefully conclude that next week by moving everything into the
| matrix-rust-sdk crypto crate implmentation:
| https://github.com/vector-im/element-web/issues/21972#issuec...
| is the tracker.
|
| Then, we can address the harder server-controlled group
| membership issue in one place. First step will be to improve
| device verification & trust so that trust is the default, not
| the exception, to make it easier to spot and warn about
| unexpected devices in the room. The full solution is then
| either MSC3917 (https://github.com/matrix-org/matrix-spec-
| proposals/blob/fay...) - or potentially to switch everything to
| MLS.
|
| We're working on MLS anyway in parallel to RHUL mitigation
| work; you can see the progress at https://arewemlsyet.com, and
| it's looking good.
|
| I'm guessing you're not interested in doing a podcast on "yay
| we converged our crypto implementations on a single robust Rust
| implementation so we can fix the remaining bugs in one place",
| but as soon as the server-controlled group membership thing is
| solved we'll be in touch. Work has also gone much slower than
| hoped on this, thanks to the joys of funding open source.
| tptacek wrote:
| INCORRECT. The messier your situation is, the better the
| podcast will be. You're still in my top 3 subjects for us to
| do an episode on. I'm rooting for you! But also for sound
| messaging cryptography. So I'm one of your most complicated
| supporters. :)
| contact9879 wrote:
| > Outside of Matrix 2.0 work, other big items on the horizon
| include:
|
| - Adding Rust matrix-sdk-crypto to matrix-js-sdk, at which
| point all the official Matrix.org client SDKs will (at last!)
| be using the same stable performant E2EE implementation
|
| - Continuing to contribute Matrix input to the MIMI working
| group in IETF for > Digital Markets Act interoperability
|
| - Working on MLS for next-generation E2EE
|
| IIRC, the rust matrix-sdk-crypto was their intended fix for the
| vulnerabilities.
| rebolek wrote:
| The future of Matrix is robots and people as batteries.
| orblivion wrote:
| > The European Union's Digital Markets Act (DMA) is a huge step
| in that direction - regulation that mandates that if the large
| centralised messaging providers are to operate in the EU, they
| must interoperate.
|
| Wow. Not interested in winning the war this way.
| Lacusch wrote:
| Maybe you're not but I know a few people (myself included) who
| will take any win on the privacy front we can get.
| kibwen wrote:
| Requiring protocols for interoperation results in more
| competition in implementations, which is often the better
| scenario as far as users are concerned.
| UltimateEdge wrote:
| > Therefore to use Element X, you need to be running a homeserver
| with Sliding Sync support, which (for now) means running a
| sliding-sync proxy which bolts Sliding Sync support on to
| existing homeservers.
|
| I am excited to try out Element X, but I do not want to
| administer yet another service, namely the Sliding Sync proxy.
| From a practical perspective, Sliding Sync (MSC3575) is still on
| the level of a proposal/experiment and I wish that we would be
| having this conversation about Element X _after_ it becomes
| usable with any spec-compliant server.
| the_gipsy wrote:
| Well you can just wait. But the proxy is really lightweight and
| doesn't require maintenance.
| rovr138 wrote:
| Until there's an incompatibility, upgrade, exposure, memory
| overflow, or some other security issue/exploit. Unless you're
| saying that it's immune to everything and will never
| experience a change or issue.
| Arathorn wrote:
| I'm pretty sure that all those issues will affect sliding
| sync whether or not it's integrated in Synapse. In fact,
| some people might actually prefer the fact they can operate
| it separately and restart/maintain it separately from their
| homeserver :)
| Arathorn wrote:
| Matrix evolves as a protocol by folks proposing new APIs (e.g.
| MSC3575), implementing them, showing that they work, and making
| the case that they should be merged into the main spec.
|
| Sliding Sync is an interesting case in that it clearly does
| work, and it kicks ass - but it turns out to be unnecessarily
| complicated for the subset of features that you actually need
| when implementing something like Element X (which is my fault
| entirely, fwiw). However, should we hold off on putting it in
| people's hands while we sort that? Nope. Is it a pain to
| temporarily run a proxy shim service while the protocol
| stabilises? Yes. It's like running a SPDY or QUIC-aware reverse
| proxy in front of a webapp that only speaks HTTP/1.1 while
| waiting for SPDY to be ratified as HTTP/2. Sure, it's another
| moving part to look after, but the spectacular improvement is
| likely worth the pain. YMMV though :)
| UltimateEdge wrote:
| > Matrix evolves as a protocol by folks proposing new APIs
| (e.g. MSC3575), implementing them, showing that they work,
| and making the case that they should be merged into the main
| spec.
|
| Yes, it is just unfortunate that it is not clear enough to
| more people (such as the_common_man below) that Sliding Sync
| is only at the MSC stage at the moment and not part of the
| Matrix spec.
|
| I am glad that at least Element X allows this MSC to improve
| and for those nits you have mentioned to be resolved.
| the_common_man wrote:
| Why is sliding sync a separate service and not just part of
| synapse itself?
| infinitezest wrote:
| I would guess it's so the same functionality can be used with
| other Matrix servers without having to rewrite the whole
| thing
| UltimateEdge wrote:
| It's currently still a proposal to the spec, and it is not
| yet part of the Matrix protocol.
| Arathorn wrote:
| Because the API is still evolving, and it's also useful that
| it supports other homeservers than Synapse. It's also written
| by an entirely different bunch of people (it's effectively
| written by the Dendrite team rather than the Synapse team).
|
| Once the API is stable I'm sure all the homeservers will
| implement it natively. Until then, think of it like a
| reverse-proxy that lets an HTTP/1 webapp talk HTTP/2 to the
| outside world.
| acheong08 wrote:
| > it's effectively written by the Dendrite team rather than
| the Synapse team
|
| I would then ask why it isn't integrated into Dendrite
| Arathorn wrote:
| ...because then Synapse wouldn't be able to use it?
| mike-cardwell wrote:
| I just set it up. Wasn't that difficult:
|
| 1. Added a new postgres db and user 2. Added a new dns name 3.
| Added a new cert for the new dns name 4. Added a new vhost to
| nginx to proxy to a new port using the new dns name and cert 5.
| Added a simple docker-compose to my config 6. Added a snippet
| to my .well-known/matrix/client
|
| Don't imagine it will take much maintenance. Container will be
| updated along with the rest of my containers, and the existence
| of the service doesn't change anything for any existing clients
| that don't support sliding sync.
| Arathorn wrote:
| The most important thing is to keep it updated, as we're
| fairly rapidly iterating on it, and most of the Element X
| bugs we've seen have actually turned out to be a stale
| Sliding Sync proxy deployment. Glad it was fairly
| straightforward.
| benatkin wrote:
| Looks like there's an open protocol and an open source client
| implementation for video calls. https://github.com/vector-
| im/element-call
|
| This is great! Jitsi has never clicked for me. I tried it a few
| times, and read about it, and was never excited about it. I just
| tried Element Call, albeit an empty room, and the UI feels right.
| [deleted]
| leshokunin wrote:
| I always get so confused by the naming between Matrix and
| Element. I get that Element is the client, but I honestly thought
| that the name Matrix for the server (or is it just the standard
| for the protocol?) was sunset.
|
| Great service though and hope if gets UX improvements too, as
| Discord and Slack keep getting more clutter.
| CameronNemo wrote:
| Maybe you are confused because the old client name, Riot, was
| sunset in favor of Element?
|
| AIUI the protocol was and is called Matrix. There seems to be
| no intention to depart from that name.
| hparadiz wrote:
| They renamed Riot to Element in the wake of the George Floyd
| protests in the United States. It's the same code base.
|
| Matrix is a protocol. Synapse is the primary server
| implementation of Matrix written in Python.
| Macha wrote:
| Here's their blog post at a time:
| https://element.io/blog/the-world-is-
| changing/?ref=itsfoss.c...
|
| It's worth nothing that the conflict with Riot Games over
| trademark rights was also a motivating factor.
| Arathorn wrote:
| (We actually renamed Riot to Element because the nice
| people at Riot Games sent us a cease & desist :)
| infinitezest wrote:
| As much as I love the fact that I have my choice of server and
| client I have to say that it does make me wonder if it affects
| adoption. When the Mastodon growth spikes happened the
| complaint that I heard most often was from people that couldn't
| figure out which client to use or which instance to use. Too
| much choice tends to paralyze people and they default to
| proprietary services because they don't know what choices to
| make.
| SushiHippie wrote:
| Element is to matrix what chrome is to http. The most used
| client for that protocol.
| progval wrote:
| Element is the trading name of a company, of three clients
| with mostly-independent codebases written by that company
| (web, android, iOS; not counting the two Element X rewrites),
| and of a hosting service (EMS).
| SushiHippie wrote:
| Yes New Vector Ltd
| cvwright wrote:
| Yeah. I still think that the Matrix.org Foundation should have
| a branded client, simply called "Matrix", available in all the
| major app stores.
|
| Lock it to the matrix.org server and offer membership in the
| foundation as an in-app purchase. Could help with some of their
| recent funding issues.
| amstan wrote:
| It's quite disappointing that there's huge ongoing work around
| reinventing clients from scratch where the basic functionality of
| not ringing all my devices while I'm using only one of them [1]
| is still not there (bug open for years), despite it being a
| pretty simple fix.
|
| [1] https://github.com/vector-im/element-meta/issues/360
| Arathorn wrote:
| The team rewriting Element as Element X is completely different
| to the folks who would need to make the change in Synapse to
| not send push to devices who are currently syncing. Agreed we
| should have fixed this years ago, especially as it's actually a
| feature in our pre-Matrix system back in 2012. There's
| basically a blindspot on long-lived missing serverside features
| like this; i've added it to a new hitlist we're experimenting
| with for trying to clear these up.
| amstan wrote:
| I offered a simple fix: delay notifications on all except the
| active client for 30 seconds, if a read reciept gets
| triggered from the active client then cancel the timer. I
| couldn't even get anyone in the team to even look at my
| solution 3 years ago.
|
| Not sure why this feature keeps getting defered for "just
| about to land and things might be better after" server-side
| features (see how it has 7 out of 9 "dependencies" resolved)
| when none are needed.
|
| I've had a couple of friend actually give up on matrix due to
| this. I also have to keep my phone on silent or else I can't
| be chatting on matrix without the constant bzzzing.
|
| I'm also amused about the ever growing (currently at $760)
| bounty on this feature.
| Arcuru wrote:
| There are quite a few issues that they've stopped fixing in the
| Element app in favor of doing it in Element X, the one I've
| been following is where the iOS app causes a breakage in E2EE
| when you use the share extension, so they just disabled the
| share extension entirely and said they'd fix in X -
| https://github.com/vector-im/element-ios/issues/7618
|
| But X requires Sliding Sync on the server, which is still a
| separate service to run alongside the homeserver and doesn't
| have a stable API. I am increasingly disappointed with how
| centralized Matrix is becoming, since AFAIK there isn't really
| an alternate client close to the same level of quality as
| Element.
|
| I probably would've made all of the same decisions myself
| though, so I don't blame them I'm just a bit disappointed in
| how it's shaking out.
| panick21_ wrote:
| You just can't have the newest fancy client without also
| having the new fancy server. That seem to make sense to me.
| xorcist wrote:
| Is it really that simple though? Jabber tried to be smart about
| which device to ring, and sometimes someone ended up with a
| missed notification. I always felt gutting that complexity and
| ring all instead would have been the more robust way.
| amstan wrote:
| So you consider your phone vibrating loudly on your desk for
| every recieved message while you're actively chatting and
| reading the same message on your desktop a correct
| implementation?
| xorcist wrote:
| Well, it's not great, but could be a viable solution until
| a scheme is devised that is guaranteed not to lose any
| notifications, which would be worse.
| teawrecks wrote:
| I'm curious if someone could build a discord replacement on top
| of matrix, most importantly with voice chat and video streaming
| functionality. Discord is clearly focused on monetization at this
| point, the only changes happening now are ones that make your
| experience objectively worse. I've also been on Linux for a few
| years now and discord still doesn't support streaming game audio.
|
| And before someone suggests it, I tried Revolt, and it's not
| there yet. The latest client (as of a few months ago) couldn't
| find my audio devices at all, and came with a big warning about
| how their audio backend was being completely rewritten, and what
| I was using was now legacy.
| Arathorn wrote:
| Absolutely. Element is already quite close to that, and once
| Element Call and native Matrix group VoIP matures more,
| hopefully it'll be even easier to converge on Discord's
| featureset.
| self_awareness wrote:
| How Matrix decentralisation is an improvement over Jabber's
| decentralisation?
|
| (disclaimer: I have no knowledge about neither spec, I'm not
| suggesting Jabber was better)
| kevincox wrote:
| IIUC Jabber never really had decentralized group chats? It had
| MUC but these were federated, so if the server hosting the room
| went down the chat also died.
|
| Matrix rooms are fully decentralized and can survive any
| servers failing.
|
| (Although note that not much else in the protocol is
| decentralized, much of it is only federated.)
| Arathorn wrote:
| It's more that Matrix is different to Jabber/XMPP.
|
| In Matrix, your chatrooms synchronise chat history between
| servers (rather than passing messages around), and that history
| is replicated equally over the participating servers, a bit
| like Git.
|
| In XMPP, you pass messages between clients on different servers
| using a given server as a hub, and clients can choose to back
| up their message history on their local server.
|
| Which architecture you prefer probably depends on whether you
| think instant messaging should be about passing messages or
| archiving chat history.
| cyberax wrote:
| Jabber core protocol (XMPP) is kinda like SMTP. It deals with
| transmission of messages between two peers. Just like with
| SMTP, you can federate servers, so they can exchange messages
| between each other.
|
| And the similarities don't end here. XMPP doesn't have built-in
| support for encryption (apart from the basic TLS encryption for
| the transport layer), it doesn't have support for message
| archiving and chat history syncing, there is no support for
| group chats, and so on.
|
| A lot of this functionality is added as extensions (e.g. group
| chats are XEP-045), but this simply caused a lot of
| fragmentation in the ecosystem. So you could never rely on your
| client (or server) interoperating with other clients properly.
|
| Audio calls and video also never really worked well. Google
| tried to push them by releasing libjingle in 2006 (!!!) but it
| was kinda ignored by everyone.
| vilunov wrote:
| Most of criticism of XMPP with regards to fragmentation and
| extensions can be applied to Matrix as well. In fact, the
| sliding sync itself already fragments the ecosystem by not
| being supported out of the box by many server implementations
| and therefore homeservers. Encryption often has to be enabled
| with some machinations as well if we're talking about clients
| other than Element (and electron-based).
|
| On the other hand, XMPP desktop clients certainly work better
| and faster than Element, although some of them look quite
| old, which doesn't take away from their functionality.
|
| IMO it's being heavily overstated how Matrix is better than
| XMPP.
|
| Also a nice read: https://telegra.ph/why-not-matrix-08-07
|
| And the answer
| https://lobste.rs/s/wvi9xw/why_not_matrix#c_erbsnb
| cyberax wrote:
| This criticism kinda misses the point. E2EE, especially for
| group chats, is _the_ reason to use Matrix. It's an
| extremely hard problem, and you'll basically need to
| replicate what Matrix does if you want to solve it.
|
| Doubly so when you add federation.
|
| It required more than one iteration of Matrix to get it
| right, which I (personally) totally expected to happen. I
| don't think XMPP will _ever_ get it right.
|
| Regarding clients, I don't think Element is worse than most
| (all?) XMPP clients when you look at the functionality past
| simple 1-to-1 messaging. And forget about mobile apps, XMPP
| just sucks on mobile.
___________________________________________________________________
(page generated 2023-09-21 23:00 UTC)