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.
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.
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.
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.
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.
I assume this is https://github.com/element-hq/element-x-android/issues/4880. Obviously push should be reliable on Android; on Element X iOS it’s rock solid these days. I’ve escalated the issue internally (it wasn’t on my radar, irritatingly).
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.
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.
> 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?
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.
>...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...
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.
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...
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.
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.
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.
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.
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.
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.
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].)
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.
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.
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!!
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.
room versions are just a much-needed way of versioning the protocol, so we can make breaking changes without being trapped with backwards compatibility problems - no different to a fileformat including a version number. it’s one of the best bits of Matrix, imo, albeit sorely misunderstood (it seems).
IRC doesn't have this because it doesn't try to make rooms into long-running distributed state machines.
Although it is possible for two room operators to kick each other on different servers at the same moment, which probably does lead to state desync. They'd have to do it at the same moment. In Matrix, it tries to still sync things that happened 6 months ago...
On second thought, I think it would lead to both operators being kicked - a nonserializable ordering. Each server would independently check the action was authorized based on the prior state, and would then broadcast into the network, not "op1 wants to kick op2", but rather "op1 did kick op2". Users on op2's server would see that op2 kicked op1, and then op1 kicked op2, despite no longer being in the channel or being a channel operator. This seems acceptable, although counter-intuitive.
All I did was to DM you to ask you to not post screenshots of the CSAM spammer’s activity, as it amplifies their spam and gives them a platform which further encourages them by giving them attention and a reaction.
This should not be remotely controversial.
Obviously the Matrix team is very aware of the very real legitimate problem of the CSAM spammer, and all the very real legitimate complaints about it, and we have tackled it as transparently as we can, with very limited resources.
I am incredibly disappointed that someone I previously respected and considered a constructive member of the open source community reacted like this to a simple request to not feed the trolls.
I’m pretty used to dropping into an HN thread about Matrix and thinking “what FUD is Arathorn going to need to debunk this time”.
Sucks tech communities are so toxic, thanks for working hard making Matrix in this environment.
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).
This has been due to a very persistent spammer attacking the public network. Since adding policy servers (https://matrix.org/blog/2025/04/introducing-policy-servers/) as a way to preemptively block content and other measures (https://matrix.org/blog/2025/02/building-a-safer-matrix/) things have improved at least in public rooms - assuming the admins enable policy servers. We sincerely apologise to everyone who has got exposed to this, and are continuing to improve the trust & safety apparatus in Matrix (although could really do with funding for the Foundation to help folks work on this as their day job).
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.
> 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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
I think this is the number one reason more people don't end up using IRC nowadays. The flow for newer, younger users is:
- Use some software project, want to ask a question, see they have an "IRC channel"
- Hopefully it's a hyperlink to an IRC web chat, or else they'll have to do a lot of research to find out what IRC is
- Join the web chat link, see a room with a list of names
- See no messages
- Ask a question
- Wait ten minutes, get no reply
- Assume it's just dead and leave
The ability to see older messages would be a huge boon, and to see messages between connections as well. I've seen it happen that a user joins a channel, they leave because nobody talked to them, somebody answers their question after they leave, they rejoin, they ask the question again, then disconnect.
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.
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...
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.
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.
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.
> 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.
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."
> 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.
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.
"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.
from memory andrew & uhoreg all joined the team before later applying for jobs at Element - the fact being that if you wanted to be paid to work on Matrix back then, Element was pretty much the only place to do so (being the company formed by the team who created Matrix). I’m not going to fire people from Element or kick them off the SCT and lose their braintrust though.
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.
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.
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.
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.
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.
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.
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.
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.
Dev on EXI has been focused on:
* event cache, to speed up room load and provide offline support. this was a huge amount of “invisible” work.
* media browsing - swiping between images, using the event cache
* fixing voip integration
* loads of trust & safety features
* threads (now in labs)
* spaces (in active dev)
* search (in active dev)
I agree that it feels like dev has slowed since the initial sprint to launch, but there’s another wave of features landing in the coming months.
Sweet. Many, many thanks.
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.
I use Firebase (GCM) and it also doesn't work. But I'll try using ntfy next.
I assume this is https://github.com/element-hq/element-x-android/issues/4880. Obviously push should be reliable on Android; on Element X iOS it’s rock solid these days. I’ve escalated the issue internally (it wasn’t on my radar, irritatingly).
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.
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.
> 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?
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.
XMPP is still there and going strong :)
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.
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.
>...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...
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.
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...
Doesn’t TCP/IP fingerprinting only reach your first hop node though?
I was looking more for a whitepaper or blog post, a random youtube video is not an acceptable source for debating the integrity of a browser.
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.
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.
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.
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.
The Conduit server is very lightweight. I run a private server on a 128MB VPS!
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.
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.
It's dead https://matrix.org/blog/2023/11/06/future-of-synapse-dendrit...
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
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.
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.
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.
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!!
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.
room versions are just a much-needed way of versioning the protocol, so we can make breaking changes without being trapped with backwards compatibility problems - no different to a fileformat including a version number. it’s one of the best bits of Matrix, imo, albeit sorely misunderstood (it seems).
IRC doesn't have this because it doesn't try to make rooms into long-running distributed state machines.
Although it is possible for two room operators to kick each other on different servers at the same moment, which probably does lead to state desync. They'd have to do it at the same moment. In Matrix, it tries to still sync things that happened 6 months ago...
On second thought, I think it would lead to both operators being kicked - a nonserializable ordering. Each server would independently check the action was authorized based on the prior state, and would then broadcast into the network, not "op1 wants to kick op2", but rather "op1 did kick op2". Users on op2's server would see that op2 kicked op1, and then op1 kicked op2, despite no longer being in the channel or being a channel operator. This seems acceptable, although counter-intuitive.
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.
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.
All I did was to DM you to ask you to not post screenshots of the CSAM spammer’s activity, as it amplifies their spam and gives them a platform which further encourages them by giving them attention and a reaction.
This should not be remotely controversial.
Obviously the Matrix team is very aware of the very real legitimate problem of the CSAM spammer, and all the very real legitimate complaints about it, and we have tackled it as transparently as we can, with very limited resources.
I am incredibly disappointed that someone I previously respected and considered a constructive member of the open source community reacted like this to a simple request to not feed the trolls.
https://mastodon.matrix.org/@matrix/114540986615467818
I’m pretty used to dropping into an HN thread about Matrix and thinking “what FUD is Arathorn going to need to debunk this time”. Sucks tech communities are so toxic, thanks for working hard making Matrix in this environment.
> 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).
This has been due to a very persistent spammer attacking the public network. Since adding policy servers (https://matrix.org/blog/2025/04/introducing-policy-servers/) as a way to preemptively block content and other measures (https://matrix.org/blog/2025/02/building-a-safer-matrix/) things have improved at least in public rooms - assuming the admins enable policy servers. We sincerely apologise to everyone who has got exposed to this, and are continuing to improve the trust & safety apparatus in Matrix (although could really do with funding for the Foundation to help folks work on this as their day job).
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.
> 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.
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.
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.
Is the CSAM spam a way to harass the admins/users or some kind of trading via broadcast in public forums?
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%202024-09...
[2]: https://matrix.org/blog/2025/02/building-a-safer-matrix/
[3]: https://matrix.org/blog/2024/06/20/matrix-v1.11-release/
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.
Also not unheard of less ethical competitors to engage in such campaigns.
Aren't matrix user IDs global? Wouldn't it be possible to ban messages from a given user regardless of server?
Wouldn't registering a new user in a different instance give you a new ID?
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.
Make server with images banned.
Only text.
Profit?
Possessing the BASE64-encoding of such an image is still a felony. Text only doesn't solve the problem.
Matrix messages/events are limited to 64kB if you disallow attachments
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.
Also ban anything that looks Base/binary-to-text encoded.
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
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.
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....
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.
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?
Main app, Element, is a website.
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.
IRC is and was the answer.
IRC doesn't have chat history and a bunch of other features.
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.
> 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.
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.
> 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.
I think this is the number one reason more people don't end up using IRC nowadays. The flow for newer, younger users is:
- Use some software project, want to ask a question, see they have an "IRC channel" - Hopefully it's a hyperlink to an IRC web chat, or else they'll have to do a lot of research to find out what IRC is - Join the web chat link, see a room with a list of names - See no messages - Ask a question - Wait ten minutes, get no reply - Assume it's just dead and leave
The ability to see older messages would be a huge boon, and to see messages between connections as well. I've seen it happen that a user joins a channel, they leave because nobody talked to them, somebody answers their question after they leave, they rejoin, they ask the question again, then disconnect.
I can see that in a lot of use cases, yeah. And yes I meant receiving old messages once you reconnect.
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.
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...
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.
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.
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.
> 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.
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."
> 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.
> 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.
In fact the matrix specification is owned by the foundation, not the company.
"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/
the spec core team’s employers are:
* alexey (red hat)
* clokep (simplisafe)
* tulir (beeper)
* travis (funded by fdn)
* uhoreg (element)
* richvdh (element)
* dbkr (element)
* andrew (element)
* erik (element)
and me
from memory andrew & uhoreg all joined the team before later applying for jobs at Element - the fact being that if you wanted to be paid to work on Matrix back then, Element was pretty much the only place to do so (being the company formed by the team who created Matrix). I’m not going to fire people from Element or kick them off the SCT and lose their braintrust though.
Chat history is a place were knowledge dies. That said my bouncer keeps the history for me.
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.
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.
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.
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.
Depends on what the question is.