It wasn’t because Mozilla stopped using GP’s favorite chat software. It’s because GP was a believer in the mission and the principles. Switching from an open system to a corny corporate one made the whole illusion fall apart. Mozilla was a corp all along and they took their volunteers for a ride.
Who else would be likely to look at what a web page is trying to get the browser to do, e.g., trigger requests for ads using Javascript. There are a variety of places to look, it is not like this is seriously hidden from those with even the slightest curiousity
That a former MDN volunteer is apparently disappointed by ads on MDN yet satisfied with MDN anyway because of a community-sourced browser add-on. An add-on that can be rendered useless at any time by the browser vendor, including the one that puts ads on MDN
It is not unimaginable that one day uBlock Origin may cease to work on Firefox when Mozilla sells search data to Google as its primary source of income and is actively working on such things as "making ads more private"
I thank the volunteer for their past work on MDN, I'm not singling him out, nor am I holding it against anyone for thinking this way, but I wonder how many uBlock Origin users believe themselves to possess some "specialised knowledge",^1 for lack of a better term, but would be all but helpless against advertising without a solution provided by someone else, e.g., a browser extension
The point I'm making is that today it seems like "knowing which app to install and how to install it" is considered specialised knowledge instead of actually knowing how to avoid ads to an extent where if the app stopped working they could devise another solution
There are definitely some HN users who can do it, and you, dear reader may be amongst them, but it seems, based on the comments I have seen over the years, there are many, many more who cannot. In that sense the situation is a bit like the IRC comment
The more one understands about online ads, the more clear it should be that so-called "ad blockers" is only a temporary solution at best, and these only work with web browsers
IMHO it is important that more people who wish to avoid ads become more curious about how they work instead of only installing a browser extension and concluding the problem is solved for the long-term
1. Many calling themselves "engineers" for example
Speaking as someone who hasn't run their own bouncer in 10+ years.
So far, I've only found clients with different bugs. Calling them good would be a stretch. Passable, perhaps. But the scene as a whole is more of a choose-the-bugs-to-live-with situation than choose-a-good-client.
Welcome to Matrix. It's the best option there is, and it's not very good.
I've never thought of matrix as a mature technology ever since.
even mastodon figured out federation.
It sounds like you were trying to login to Mozilla's Element web client and it was only set up to authenticate against the Mozilla homeserver but A) that's a client setting unrelated to federation or really the protocol in general and B) not what you were supposed to be doing to begin with.
And IRCv3 has chat history to provide that. But https://snikket.org/ (XMPP) is more likely aligned with what you are looking for
[1] - https://thelounge.chat/
[2] - https://convos.chat/
It just works.
No wonder people don't want to join it.
(Saying that as someome who has his own bouncer.)
Email really could have been great, but html and bad actors have made it so much worse than it needs to be.
Literally every single modern chat platform has support for stuff like that, and for a reason. Discord became popular because it combined those modern chat features with the ability for every community to create its own private little "server" - while at the same time making it trivial to participate in multiple "servers" at once.
IRC servers do also support profiles.
I think the real “issue” with IRC is that its users generally prefer the minimal UI. So there isn’t an high enough demand to make prettier UIs. But there are web clients that are a little less basic.
For what it’s worth, I’m in that minimal camp too. I wish I could still connect Slack to IRC.
I consider it a feature that acts as a filter.
So in many cases, you don't need a VPN to prevent revealing your actual geographic location.
Discord could well run on top of IRC the protocol and be open to federation without any change of UX.
It's not inherent to the protocol. https://ergo.chat/ does not have netsplits (from having a single server) and https://github.com/Libera-Chat/sable replaces the server-to-server protocol to eliminate netsplits as well.
And even when not eliminated entirely, they are infrequent and barely visible on well-managed networks like Libera.Chat. Many chat platforms have more (and longer) outages than Libera has netsplits.
> missed messages
Solved by most server implementations using https://ircv3.net/specs/extensions/chathistory
> bot wars over channel and nick ownership
Solved decades ago thanks to NickServ and ChanServ (though I'll admit they are ad-hoc additions on top of the protocol). And ~15 years ago we got native support for authentication (https://ircv3.net/specs/extensions/sasl-3.1)
IRCv3 missed the boat by years. By 2016, when the working group was formed, IRC was already well past its glory years. Even then, it took til the 2020s before any major network fully adopted it. Because - and I say this as a nerd who held an O line on two of those major networks at one point in my life - a bunch of nerds got hung up on arguing about implementation specs rather than looking at features and functionality organically. Ironically, in the quest to avoid becoming a closed Discord/Slack/what-have-you ecosystem product, they needed a product manager to remind them that what they needed to build in that working group was an evolution to IRCv2, not endless arguments over the format of configuration files for server daemons, for but one example.
> And ~15 years ago we got native support for authentication (https://ircv3.net/specs/extensions/sasl-3.1)
The IRCv3 WG was convened near the end of 2016, so 9 or so.
Because people invested/wasted their energy into building proprietary silos instead.
Just looked it up and there is IRCv3 to fix this, but idk what the state of that is.
IRCv3 was already late to the party and when I saw that the Working Group's mailing list was composed of lots of debates on formats for server daemon configuration files, it was clear many couldn't see the forest for the trees.
Sure it does, when all browsers have more or less the same, and the context makes clear we're not talking about the mere programmatic consumption of HTTP (like through some REST api).
"But it's a protocol and not a client" is pedantically irrelevant, given that the clients for that protocol all follow the same conventions. The parent already said they meant the UX of it "which is arguably similar between implementations".
Besides, protocols impose some concepts and models of interaction and consumption, which informs any UX created on top of them. So it's not like that client sameness is merely accidental and unrelated to the protocol either.