[HN Gopher] Upcoming coordinated security fix for all Matrix ser...
___________________________________________________________________
Upcoming coordinated security fix for all Matrix server
implementations
Author : notpushkin
Score : 162 points
Date : 2025-07-17 10:49 UTC (12 hours ago)
(HTM) web link (matrix.org)
(TXT) w3m dump (matrix.org)
| mystraline wrote:
| Just a heads up, that I mostly quit using Matrix except for a few
| topic-specific and heavily moderated servers.
|
| Why? The main chat server matrix.org has a child porn/CSAM
| 'problem'. Due to lack of moderation in many of those rooms,
| along with protocol problems, these sorts of CSAM spammers can do
| an hours long image campaign of stuff that's illegal to even
| have. Theres nothing quite like waking up to a post every 10
| seconds of felonies in a cybersecurity or Linux chat, and the
| summary clean and get the hell out of those rooms.
|
| Banning also doesn't work, due to distributed nature of rooms.
| You can be banned from matrix.org room but connect through a
| different server, and they can still spam users.
|
| If you do want to be on Matrix, I would recommend a few changes.
|
| 1. Don't stay on matrix.org chatrooms. They are the worst hit and
| slow to resolve
|
| 2. Disable image preloading and downloading.
|
| 3. If you have private servers and rooms for friends, its the
| best.
| AAAAaccountAAAA wrote:
| They recently adopted this thing, though:
| https://matrix.org/blog/2025/04/introducing-policy-servers/
|
| I haven't encountered any of that kind of abuse in Matrix after
| it has been implemented. It partially nullifies the point of
| the room decentralization, though.
|
| Some of the biggest public rooms like "Matrix HQ" are almost
| unusably slow, though, since they have tens of thousands zombie
| users.
|
| Matrix performance feels now more or less adequate for all
| realistic use cases, as long as long-term idle users are pruned
| out every now and then from public rooms.
| ezst wrote:
| > It partially nullifies the point of the room
| decentralization, though.
|
| And that's the ONE thing giving Matrix bragging rights over
| any other chat protocol. Their whole crusade against XMPP in
| Matrix early days was based on this distinction and
| overstating the importance and relevance of it. So I guess we
| are left with an absurdly complex protocol and single-source
| implementation for... nothing then?
| Ajedi32 wrote:
| It looks like the policy servers are themselves federated,
| so it's not really as big a concession as you're making it
| out to be.
| edhelas wrote:
| XMPP is still there and going strong :)
| edent wrote:
| Any when you complain about it, Matrix accuses you of acting in
| the interests of the attackers.
|
| I've quit it entirely. They have a real victim complex and
| don't understand that people have legitimate complaints about
| them.
| mystraline wrote:
| I've never engaged the project admins. But if they're like
| Tor and their responses to deanonymizing OS reporting
| (basically hostile and attacking), it wouldn't surprise me.
|
| My issue with possession of CSAM is that its statutory
| without mens rea. That means if my client gets an image
| without my knowledge or approval, I'm still blamed for it.
| And blame is a bloody felony. Some jurisdictions call for
| absurd punishments of 10y prison per image.
|
| There are a few rooms I'm in. They are heavily moderated and
| narrow discussion. One is an speech-to-text from OpenMHZ
| police scanner for my area. But I also discourage usage - I'm
| highly technical, and I fear average users would get in over
| their heads and have a very bad time.
| firefax wrote:
| >...if they're like Tor and their responses to
| deanonymizing OS reporting (basically hostile and
| attacking), it wouldn't surprise me.
|
| Can you be more specific about this? I've met several of
| the devs and they seem open to bug reports, and the Tor
| blog is always being updated with notes about various fixes
| that have been implemented...
| mystraline wrote:
| Tor silently, last October, quit spoofing OS and now
| reports over browser headers what OS you are.
|
| Previously, every Tor Browser was "windows".
|
| The claim I've heard was that there were JavaScript
| attacks that could uncover what OS you were using.
| Patching those would be 'too hard'. So now TBB just gives
| up OS. Seems not very good to voluntarily give up bits of
| PII.
|
| https://m.youtube.com/watch?v=3wlNemFwbwE is where I was
| made aware of this problem. I verified it on my
| infrastructure too.
| lcampbell wrote:
| Without knowing anything about Tor, I'd guess you've got
| it backwards. I imagine Tor leaks your OS through TCP/IP
| fingerprinting, and whether that fingerprint matches your
| `navigator.platform` is probably a factor into whether
| e.g. Cloudflare hellbans you.
|
| Then again, I'd also assume Cloudflare just de facto
| hellbans all Tor exit node IPs, so...
| immibis wrote:
| Time to debunk this again.
|
| Tor had a thin layer of user-agent spoofing: it would
| always claim to be Windows (I presume) in the User-Agent
| header. But the real user-agent (which is still spoofed,
| but platform-specifically) was easily accessible from
| Javascript without even fingerprinting, since they never
| spoofed the navigator.userAgent variable in the same way.
| It could also be detected from other fingerprints such as
| TLS.
|
| They removed the header-only user-agent spoofing so that
| the User-Agent header now reports the same value as
| navigator.userAgent, which is one of three distinct values
| based on your OS type. The rationale is simple: having
| these different didn't work. It was a failure. It didn't
| hide any information. And it tripped fingerprint checks on
| some websites. So they stopped doing that.
|
| Certain people are trying to make this into a huge uproar
| for some reason. As far as I'm concerned, it's a
| coordinated disinformation campaign to discourage the use
| of Tor. The developers probably get spammed about this
| particular change a lot, because of the disinformation
| campaign, which explains the hostile response.
| mystraline wrote:
| Nowhere on Tor's blogs or social media posts mentioned
| any of these changes, and why. The 'debunking' is
| required because of media silence, and people online
| finding out about this.
|
| Nor were there any developer statements about this
| change. From an outsider (user) perspective, this smells
| like a coverup or an insider threat ala XZ situation.
|
| And for software that people sometimes rely on
| safeguarding their lives with, well, yeah, addressing
| these significant changes in the open is how you avoid
| due scrutiny. And I think scrutinizing the lack of
| communication is a rather damning problem, especially
| here.
| majorchord wrote:
| The real crime to me is tor browser not spoofing
| navigator.platform. Regardless of the user agent, if this
| variable can be used to find something that doesn't say
| Windows, then I think that already greatly hurts your
| fingerprint as the number of non-Windows installs pales
| in comparison.
| AAAAaccountAAAA wrote:
| They definitely have a victim complex. Few years back, when I
| complained of the then-insanely poor performance and
| scalability of the Synapse server, they told me to spend a
| few thousands of bucks on a high-performance personal server,
| and to educate myself to set up and maintain a Synapse
| instance, which was then and is still much harder to do than
| running most other server software.
|
| Hell, I was told I was a some sort of bad person for being
| unhappy with room joins taking hours or even days.
|
| After exhausting all other options, they have improved their
| software a lot (it's still not perfect, but definitely
| usable), but their poor attitude has soured their reputation,
| and made it really difficult to be enthusiastic about Matrix.
| masfuerte wrote:
| The Conduit server is very lightweight. I run a private
| server on a 128MB VPS!
| AAAAaccountAAAA wrote:
| I have heard so, too. Maybe I'll give it or some of its
| derivatives a try some time.
|
| I think there is a some sort of catch-22 going on. Matrix
| Foundation can't fund the replacement of Synapse with a
| better-designed server, because hosting matrix.org
| consumes all the money. And it consumes so much money
| because it runs Synapse, which uses computing resources
| in a very inefficient manner.
|
| And the Foundation might have a some sort of conflict-of-
| interest, since it is closely interwoven with the New
| Vector company, which business case is being able to make
| Synapse work despite its flaws.
| DuncanCoffee wrote:
| There's an official Golang rewrite called dendrite:
| https://github.com/element-hq/dendrite it has few start
| because they recentyl migrated it from the original repo
| (https://github.com/matrix-org/dendrite) Development is
| not fast but it's going on, and it's currently on beta. I
| haven't tried it, I selfhost a synapse server which I
| used with friends, and with docker it wasn't hard to set
| up/maintain after the initial effort.
| ezst wrote:
| It's dead https://matrix.org/blog/2023/11/06/future-of-
| synapse-dendrit...
| mananaysiempre wrote:
| Only the Apache-licensed version is dead. The commercial
| arm (Element) forked it and relicensed it under the AGPL
| to make sure nobody but them can use their post-fork
| changes commercially. (Element demands you sign a CLA to
| contribute. Don't[1].)
|
| [1] https://drewdevault.com/2023/07/04/Dont-sign-a-
| CLA-2.html
| ezst wrote:
| I mean, for years Dendrite was positioned, by the
| developers of Synapse themselves, to become Synapse's
| successor, and Dendrite was getting a ton of funding and
| attention to make sure it happens.
|
| It didn't then, and now that the situation is dire for
| Dendrite (with no funding and no official effort being
| put into it), I have little hope things are going to
| improve.
| xorcist wrote:
| Very easy to set up (without the Docker nonsense, it's
| just a binary that is trivial to build), but the real
| work was in maintaining it. After the third case of
| database table inconsistencies from joining large public
| rooms (or perhaps from upgrading it, or a combination) I
| regretfully had to give up on it. It was time consuming
| to find out the table structure being used and how to
| manually correct the data so that it would start again.
| People were generally helpful on irc but it's just not
| fun work and feels a bit unnecessary.
| immibis wrote:
| I thought it was just because they make their income by
| selling faster server software. The free one can't be
| fast, in that case.
| lowwave wrote:
| Thank you for bring this (conduit) up!!! Nothing beats a
| binary and toml/json/yml file deployment!!!
|
| And it is what great about the matrix.org vs other open
| source app such as Telegram/Signal/Wire.... The protocol
| was designed to be open. If you don't like the client,
| write one, if you don't like the server, write another.
| Just follow the API specification. Being it is REST it is
| much easier to decipher than IMAP/SMTP. And port 443
| works every where! Even on proxied Internet!!
| immibis wrote:
| The specification is so complex that keeping up with it
| is a full-time job - which benefits the Element
| Corporation, which profits from selling their complex
| server and client and also makes the specification. Just
| have a glance at the concept of room versions.
| Klonoar wrote:
| Conduit is a bit slow to update over the years, and a few
| forks have improved on it quite a bit; continuwuity being
| chief among them at the moment.
|
| Yeah I hate the name too.
| NetOpWibby wrote:
| Conduit is great, I migrated my private friends server to
| it a few months ago.
|
| Made a lil' tutorial as well:
| https://blog.webb.page/2025-04-25-enter-the-matrix.txt
|
| Now if I could get Element X working that'd be awesome
| but I've settled for regular Element for now.
| ezst wrote:
| > a real victim complex
|
| that, a thousand times. Combined with a severe lack of
| objectivity. If you can't see the flaws and can't be critical
| of your own product, what room/hope is there for improvement?
| Matrix is a never ending story of over-promises under-
| delivered, taking feedback in bad faith, and, yeah, playing
| the victim.
|
| I'm amazed that Matrix did manage to capture so much
| attention for so long while at it. There were there at the
| right time but with the wrong
| tech/product/abstraction/competences, sucked all the air out
| of the "federated personal instant messaging that you can
| host yourself"-room, and I am still sour that they possibly
| contributed to the current sad sate of affairs and worst case
| of consolidation there has ever been in this space (there was
| a time when WhatsApp wasn't so ubiquitous, facebook
| messenger, skype, ... sucked, GTalk had some amount of
| interop, and we had a shot at not having our instant
| messaging in walled gardens).
| orbisvicis wrote:
| Aren't matrix user IDs global? Wouldn't it be possible to ban
| messages from a given user regardless of server?
| joseda-hg wrote:
| Wouldn't registering a new user in a different instance give
| you a new ID?
| meepmorp wrote:
| Is the CSAM spam a way to harass the admins/users or some kind
| of trading via broadcast in public forums?
| AAAAaccountAAAA wrote:
| Former, I think. It involved highlighting all users of the
| room, and sometimes verbal abuse against Matrix and/or the
| projects which the rooms in question belogned to. Now that
| sort of abuse is much harder, since they have improved spam
| filtering.
| mossTechnician wrote:
| Some of it was the latter. Matrix servers could be used in
| the past to store and serve unauthenticated media to
| anyone[0], which was described by the team as "not great"[1]
| and "abuse of Matrix as a content distribution network" [2].
|
| I believe the team was prudent in being reserved about
| describing the issue (and the abuse it could entail) until
| after these changes rolled out in 2024[1], especially due to
| the unique challenges they required (including putting a
| freeze on unauthenticated media as part of the upgrade
| process).
|
| [0]: https://matrix.org/blog/2024/06/26/sunsetting-
| unauthenticate...
|
| [1]: https://2024.matrix.org/documents/talk_slides/LAB4%20202
| 4-09...
|
| [2]: https://matrix.org/blog/2025/02/building-a-safer-matrix/
|
| [3]: https://matrix.org/blog/2024/06/20/matrix-v1.11-release/
| diggan wrote:
| Also not unheard of less ethical competitors to engage in
| such campaigns.
| rglullis wrote:
| You can configure synapse to not cache remote images. Yes,
| these spammers are obnoxious but most homeservers should be
| safe if the moderation is prompt.
| Fokamul wrote:
| Make server with images banned.
|
| Only text.
|
| Profit?
| SAI_Peregrinus wrote:
| Possessing the BASE64-encoding of such an image is still a
| felony. Text only doesn't solve the problem.
| ptman wrote:
| Matrix messages/events are limited to 64kB if you disallow
| attachments
| zamadatix wrote:
| 62k of base64 of a random stock image from Pexel
| https://pastebin.com/raw/tU5D1kuT, you can try it here
| https://base64.guru/tools/data-url-to-image
|
| Proper SPAM and user/content management is an inevitable
| need for public chat. E.g. what makes HN chat readable
| and full of legal content is not comment length limit but
| all of the other more complex systems enabling efficient
| moderation.
| diggan wrote:
| Also ban anything that looks Base/binary-to-text encoded.
| phyzome wrote:
| I have a private server (running Dendrite) but it doesn't even
| work well for that purpose -- so many bugs, many preventing me
| from reading messages due to encryption state fuckups.
| asimops wrote:
| There is a blog post that captures this feelings very well in
| my opinion: Not being federated and E2E as an advantage
| https://blog.koehntopp.info/2025/06/17/no-federation-no-e2e....
| lowwave wrote:
| To be fair on matrix.org they recommend that you host your own
| server. Main selling point of matrix.org is there is NO
| centralized server!!! That is whole point of using matrix
| instead of Telegram, Signal, Wire.
|
| Element for smart phone, please make it very easy to change
| custom server instead of the default "matrix.org" ( Schildi
| Chat did a good job in their UI) I would recommend matrix
| client over Element TBH.
| xinayder wrote:
| I've been using it for over 2 years now and I agree there's a
| spam problem on public chatrooms.
|
| However, what's making me want to quit is that for more than 3
| months now, message notifications have been completely broken
| on Android (Element X and its forks), and there's no fix for
| it. I completely miss out on important things and now have to
| build the habit of opening Element X once or twice every 15
| minutes, so that it loads the messages from the server, and
| shows what people have been messaging me lately.
|
| I no longer get message notification details on my phone,
| instead a generic "you have new messages" pop-up. There are at
| least 6 issues on GitHub detailing the same issue, but there
| isn't a fix and it looks like this is not a priority for the
| development team right now, even though it makes Element X
| practically unusable.
| komali2 wrote:
| In my experience, Element X was released long before it was
| ready, and I still think it's far from ready. I've been using
| Element on android and it's been wonderful. Can't speak for
| iOS.
| realityfactchex wrote:
| Element X is fine on iOS, but I wish it had regular
| updates. It feels like it has stagnated. There is still a
| feature gap for it to catch up with regular Element on iOS.
| blahaj wrote:
| You might want to look into Unified Push. Although you need
| to use a Unified Push server that supports the differing
| Matrix endpoints because for some reason the Matrix devs
| decided to do their own thing. I wouldn't call using Unfied
| push with Matrix reliable, just like nothing with Matrix is
| ever truly reliable, but it works much better than native
| notifications for me.
| TheCraiggers wrote:
| I agree this has been a problem for years and it's very
| frustrating.
|
| The fix I found that works for me (at least if you're using
| Unified Push like ntfy) is to go into ntfy and delete all the
| Element subscriptions in there. Force close and reopen
| Element, which will automatically remake them.
|
| That fixes the issue, at least for a long time. About once a
| year I need to redo the ritual.
|
| Hopefully this helps you.
| xinayder wrote:
| I use Firebase (GCM) and it also doesn't work. But I'll try
| using ntfy next.
| ProofHouse wrote:
| I am curious if there are any anyways that you would suggest
| this issue best be handled outside of putting the onus on user,
| as per your bullet points
| cjbgkagh wrote:
| One of the reasons we cant have nice things.
|
| CSAM spam filtering is a bit of a moat for larger companies
| able to manage the costs of moderating it.
|
| I would like to see AI moderating of CSAM, perhaps an open
| weights model that is provided by a nation state. With
| confidential computing such models can be run on local hardware
| as a pre-filtering step without undermining anonymity.
| diggan wrote:
| > I would like to see AI moderating of CSAM, perhaps an open
| weights model that is provided by a nation state.
|
| I don't envy the people who would have to trauma their way
| through creating such dataset. Yet, it would be useful yes.
|
| > With confidential computing such models can be run on local
| hardware as a pre-filtering step without undermining
| anonymity.
|
| I'm not sure it'd make sense to run locally. Many clients
| aren't powerful enough to run it on the receiving end (+
| every client would need to run it, instead of fewer
| entities), and for obvious reasons it doesn't make sense to
| run on the senders end.
| cjbgkagh wrote:
| I guess I meant locally to the server not the client
| (edge). But also perhaps a very light model could be run on
| the edge.
|
| I built a porn detection filtering algorithm back in the
| Random Forest days, it worked well except for the French
| and their overly flexible definition of 'art'. The 'hot-
| dog/not-hot-dog' from SV HBO is pretty accurate on what
| that was like. I've thought about what it would take to
| make a CSAM filter and if it could be trained entirely
| within a trusted enclave without external access to the
| underlying data and I do believe it is possible.
| 42lux wrote:
| IRC is and was the answer.
| ClueslessTech99 wrote:
| IRC doesn't have chat history and a bunch of other features.
| AAAAaccountAAAA wrote:
| IRCv3 has "chathistory" extension. It basically involves
| combining an IRC network and a bouncer. There are at least
| two server implementations using it: ergo, which is more or
| less production ready, but does not have support for multi-
| server networks, and Libera's sable, which is under (very
| slow) development.
|
| I wonder why such thing wasn't done 15...20 years ago. Now it
| seems to be too little too late, with Matrix more or less
| having been taken the place of IRC.
| darkwater wrote:
| I guess that because of the "we don't need that here"
| attitude that ran a lot through the first generation(s) of
| Internet population. And it's a shame because with a more
| dynamic IRC development we wouldn't be in the Slack/Discord
| silos situation.
|
| Or maybe we would have been anyway because adding more and
| more complex features to federated, open-protocol systems
| with many actors involved with different, maybe even
| competing interests is not easy at all.
|
| But also if I think back at late '90s, IRC had almost the
| needed critical mass and non-tech users to become something
| more mainstream...
| scblock wrote:
| Our small group uses The Lounge web client for IRC which is a
| very good PWA, acts as a bouncer, has history search (not
| unlimited, but pretty long), supports image upload, and
| basically builds a modern group chat on top of IRC as a
| backend. We have a few folks who still use traditional IRC
| clients, but almost everyone just uses the web app. It's not
| a bad middle ground.
| diggan wrote:
| > IRC doesn't have chat history
|
| Personally I see that as a feature. Chat is ephemeral,
| discussions/texts that aren't should be saved elsewhere
| anyways, otherwise it gets lost with all the other ephemeral
| stuff.
| barbazoo wrote:
| That's what I thought until I learned that history really
| seems to refer to persistence. So if you're not connected,
| you won't get messages, even after you reconnect? For many
| that's not very useful.
| diggan wrote:
| > So if you're not connected, you won't get messages
|
| That's true, if you're not connected, you don't receive
| messages.
|
| > even after you reconnect?
|
| That's not true, once you're connected, you start
| receiving messages again.
|
| > For many that's not very useful.
|
| Yeah, I understand it isn't useful if your perspective is
| that you should be able to read what happened when you
| were away. But I guess my previous point is that people
| shouldn't have to do that, there should be another
| resource for catching up what happened when you were
| away, and instead it should be OK to return without
| having to read through all the messages.
| barbazoo wrote:
| I can see that in a lot of use cases, yeah. And yes I
| meant receiving old messages once you reconnect.
| perching_aix wrote:
| Never used it, what's so great about IRC? All I know is that's
| it's self hosted chat with no history retention, which doesn't
| sound like a solution to anything fancy in particular. The
| latter bit strikes me as an anti-feature even, if anything.
| 42lux wrote:
| Chat history is a place were knowledge dies. That said my
| bouncer keeps the history for me.
| perching_aix wrote:
| Why? With chat history present, reasonable people can
| search for previously answered questions. Without it, if
| somebody joins afresh, even if their question was answered
| just before them, they could have no idea.
| m-p-3 wrote:
| IMO it's partly because it's an inefficient platform for
| storing knowledge, its purpose is instant communication.
|
| If that knowledge is actually valuable, it should be
| stored elsewhere, in a structured manner. But I get your
| point, it's better than not having any answer at all.
| AAAAaccountAAAA wrote:
| While long-term chat histories aren't maybe that useful,
| the problem with IRC is that if your connection dies, you
| miss all the messages until the connection resumes. That is
| a big deal on mobile.
|
| Bouncers are an option, but the need to use that sort of
| extra services will make non-technical users turn away.
| cbm-vic-20 wrote:
| > what's so great about IRC?
|
| It's got a simple protocol that's easy to implement.
|
| There's no company who "owns" IRC, as there is with Matrix,
| and no "reference implementation". Extensions and
| enhancements are done by consensus of the people writing the
| clients and servers, there's no central agency that maintains
| extendion proposals like Python's PEP or Java's JEP. As a
| result, to be as interoperable as possible, most
| implementations stick to supporting the existing status quo.
| If you want to add something new to a client or a server, you
| run the risk of having that feature only work for a small
| fraction of users. If it's popular enough, other impementors
| may choose to make their clients and servers support it.
|
| IRCv3 is an attempt to make collaboration a little more
| formal, but it's a slow process.
| ptman wrote:
| In fact the matrix specification is owned by the
| foundation, not the company.
| cbm-vic-20 wrote:
| "In fact", yes. But does Element still have an outsized
| influence over the foundation? Just last month the
| foundation posted a bit of a defensive blog about how
| "open source" they are to clear the air, but as far as I
| can tell, it appears that a majority of the foundation
| "Spec Core Team" are Element employees. I can't strongly
| back that up since the page that lists the members
| doesn't say who they're employed by, so I'm guessing
| based on what their linked GitHub profiles show.
|
| https://matrix.org/blog/2025/06/dispelling-myths/
| rcxdude wrote:
| There isn't much. It's an old protocol, and very simple. But
| it's simple to the point of naivete and networks only really
| function with a bunch of ad-hoc extensions on top of it, but
| there's very little standardisation of those, and that's
| basically to get things like the concept of having a
| persistent identity that can't just be hijacked by anyone
| else on the server, let alone something like persistent
| message history, media sharing, or end-to-end encryption.
| immibis wrote:
| Well, all the stuff you listed is pretty much why it's great.
| It's almost the simplest thing that could possibly work, and
| so, it does work, pretty reliably and without fuckups. If you
| try to turn IRC into Matrix, it just becomes Matrix and you
| should use Matrix instead - it exists. IRC occupies a
| particular niche of being simple, but not so simple it
| doesn't work.
|
| The lack of server-side history is a severely underrated
| feature, actually. Lack of history means you aren't legally
| obligated to moderate history (because there is no history)
| and you aren't legally obligated to have someone on-call to
| moderate the history. Spam has a lower impact because the
| spam is not saved.
|
| IRC's severe flaw is not the lack of server-side history, or
| images or emoji reactions - it's the reliance on constant
| connection between the client and server. This makes a very
| bad experience on mobile devices. It works badly on the other
| side of the equation, too - the online/away/offline social
| protocol is designed for an era where you log into your
| computer at the start of the day and shut it down at the end.
| And in general, the social protocol is from the era where you
| messages targeted at you are few and mostly interesting, and
| you may also subscribe to a small number of small social
| groups or topic subscriptions - none of that is true in the
| modern social era.
|
| If you want to solve at least the non-social part of that,
| you end up designing servers that buffer messages on behalf
| of clients, which is the same as server-side history and
| creates a legal obligation to moderate it. Bouncers don't
| have this problem because the bouncer is under the control of
| the end user, so they can do what they like with it. But
| bouncers have to run on devices with stable power and
| internet access.
| perching_aix wrote:
| > Well, all the stuff you listed is pretty much why it's
| great. It's almost the simplest thing that could possibly
| work
|
| And that's all well and good, did recognize that, but then
| isn't it a bit disingenuous to present it as some sort of
| "real" solution in a thread about a communications
| technology that aims to cover much more? It's like arguing
| that Prometheus is the be-all end-all of monitoring, even
| though the remaining concerns still remain, and are just
| shoved aside to be some adjacent solution's problem.
|
| > Lack of history means you aren't legally obligated to
| moderate history (because there is no history)
|
| Is that actually right? Feels pretty suspect to me, you
| have to hold onto the data at least a little bit to
| transmit it to all connected clients, being a client-server
| protocol. I don't think this passes by the courts, not any
| more than holding onto a few dozen or a few minutes of logs
| in a non-persistent fashion (i.e. in-memory only) would.
| ranger_danger wrote:
| It's not right, there's so many legal contradictions in
| their statement it's hilarious. And the cherry on the top
| is that they were recently banned from libera IRC.
|
| "As a rule, strong feelings about issues do not emerge
| from deep understanding."
| AAAAaccountAAAA wrote:
| > Is that actually right? Feels pretty suspect to me, you
| have to hold onto the data at least a little bit to
| transmit it to all connected clients, being a client-
| server protocol. I don't think this passes by the courts,
| not any more than holding onto a few dozen or a few
| minutes of logs in a non-persistent fashion (i.e. in-
| memory only) would.
|
| It doesn't excuse failure to moderate the service at all,
| but if there is no chat history, you cannot be excepted
| to moderate it specifically. Basically, in any even
| remotely fair legal system, one cannot be excepted to
| delete something that doesn't exist in the first place.
| komali2 wrote:
| We ran our co-op on matrix for a while. We switched to discord
| because onboarding to matrix and making people use this "weird
| app" was a burden. I would have loved to use IRC, or xmpp, but
| the way we use these "chat apps" is as the cornerstone of our
| entire organization, and I couldn't find a good way to get IRC
| or xmpp to work that way.
|
| For example, we have the "gigs" channel where gigs that are
| hiring are posted as threads, and people interested reply in
| that thread asking questions about the gig, putting their names
| in the hat, getting communicated with about client questions
| etc. A lot of the information is "duplicated" to our CRM and
| even our wiki in a little table, but at the end of the day the
| "chat room" is the hub.
|
| Same for events (which are duplicated to wiki and calendar),
| announcements (wiki, monthly email newsletter), and long
| running threads in "general" planning FOSS projects or whatever
| that people that only check in a couple times a week will pick
| up again after a gap.
| regularjack wrote:
| Depends on what the question is.
| willvarfar wrote:
| I guess many of us are like me - have only a fuzzy idea of what
| Matrix is and what its like.
|
| Are there any normal web viewers to show what's in the public
| chatrooms without needing to join matrix and use the app etc?
| prmoustache wrote:
| Main app, Element, is a website.
| realityfactchex wrote:
| As other commentary here says, there is a real and alarming
| problem with spam in public rooms on the public server. On the
| other hand, a private server with just people who trust each
| other is fairly phenomenal.
|
| However, TFA seems to be in general about an upgrade to fix the
| following: ""state resets": scenarios where Matrix's state
| resolution algorithm can give unexpected results".
|
| If room states become more stable, that is great.
|
| Thanks to the Matrix team for all their efforts. Much gratitude.
| baby wrote:
| I feel like what's missing is not decentralization, but an open
| source offering to have large servers with e2e encryption. The
| cost of running a server doesn't have to be high.
___________________________________________________________________
(page generated 2025-07-17 23:01 UTC)