Email is still (and IMO always will be) the defacto method of communication for anything professional, regardless of whether it's 1994, 2026 or 2095. I'm not even totally convinced that something else could come along and usurp it; it would have to be something so easy, so ubiquitous, fully-supported across every piece of software and internet that you encounter, while serving as a form of identity and "fixed geography" (think about how email addresses serve similar purposes as postal addresses), trustable, comprehensive, and completely open and free (not as in beer, but as in protocol-level free) ... and even then, the value prop would have to be cheaper, seamless to migrate all existing email-related stuff to, and backwards compatible with / significantly more compelling than email itself, to convince the world to adopt it.
I'd love to see it though, because email really is long in the tooth at this point.
IM is fine for quick, ephemeral communications ("I just arrived at the restaurant") or automated processes ("Your authentication code for $BANK is 9975"), but for meaningful, thoughtful communication between human beings, email works better for me. The main advantages:
- I use my own domain, so I'm not tied to any single provider
- I can keep a copy of everything (I still have some emails from 30 years ago)
In practice "better UI" would mean things like being able to trivially share files and images, or quote/link a specific message, or even making it easier to distinguish between users with similar nicks via their profile pictures. And those UI improvements are actually features which are integral to its protocol, so they can't easily be bolted on by a custom IRC client in a backwards-compatible way.
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.
Quoting/linking is a client feature, not a server one.
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'd guess the important feature for Discord is it is easier for the administrators to get hosted and online, but "you could create a client with a better UI than discord" is a terrible line of argument. People could do lots of things in the OSS world and they don't. I can't recall any IRC client that I have found as easy to use as the Discord client except - ironically given the topic - ChatZilla which died off years ago because Mozilla decided that extensions were more of a 2000s technology than something they wanted to support.
Email is OK. The point is that most conversations moved to other media (mainly chats) and so 90% of my mail is notifications, 9% is newsletters, 1% are real messages. They used to be 99%.
>It's not like you couldn't create an IRC-client with better UI than discord
No, you cannot. You cannot, because you need a team for this, and they need salaries, and unless you push ads into people's throats, there won't be any.
It's been a while since I last used IRC, but afaik one of the issues with it was that servers revealed the IP address of users to every other user by default. Since the IP is geographic that's one piece of information you could use to doxx someone.
IP addresses aren't linked to a complete street address, and many times don't even show the right town, especially those on CG-NAT or a plain ol' direct public dynamic address. I have seen some IPs, like on AT&T and Comcast home Internet, showing a different state.
So in many cases, you don't need a VPN to prevent revealing your actual geographic location.
The fact that this is needed at all is a serious problem. Making people who aren't aware of some obscure details accidentally doxx themselves is incredibly user-hostile.
The entire reason Mozilla came into being is to do things like improve the user experience for IRC so we can keep the internet open. There has never been any other reason for Mozilla as an organization to exist.
Netsplits, missed messages and bot wars over channel and nick ownership were an integral part of IRC UX, and they were direct consequences the IRC protocol. If Discord was run on top of IRC protocol, it would have the same. Discord would probably be its own network and the people who prefer IRCnet, EFnet or QuakeNet would never touch it.
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.
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)
So... Usually it's claimed that one of the advantages of IRC is that it doesn't depend on a single server, so using a single server feels a bit like cheating. Replacing the server-to-server protocol sounds a lot like it's not really IRC protocol any more. The chathistory link says "This specification may change at any time and we do not recommend implementing it in a production environment." right on top. And yes, NickServ and ChanServ exist on some networks and IIRC they were one of the major points in debates over which network is the best and which ones to not touch with a ten feet pole. A hypothetical IRC-based Discord-like service could have it.
> Replacing the server-to-server protocol sounds a lot like it's not really IRC protocol any more
There hasn't been a standard server-to-server protocol in like three decades. Even RFC 2813 only specifies one of the protocols in use at the time (IRCnet's). Each implementation has its own (some of them forked from the original)
> The chathistory link says "This specification may change at any time and we do not recommend implementing it in a production environment."
True. Ratification of the final spec is stuck on some details, unfortunately.
I mean the word "Relay" in Internet Relay Chat was meant to refer to relaying between servers. Larger networks even had some hub servers that didn't allow users to connect at all, and existed to be server interchanges.
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.
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.
>Like “the UX of HTTP is horrible”? Still doesn’t make any sense
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.
It's gatekeeping. Don't be surprised when your pet project slowly dies because potential new contributors choose to join less hostile communities instead.
Great idea, but requires learning a new UI, doesn't fetch "streams"...
In any case, it's great to see the family of FBPurity and Antigram being joined by a new tool.
>I would love genuine feedback. Thank you very much for your attention on this matter
Maybe a harsh thing to say, but I'd say that the approach is wrong. I think that the approach by FBPurity and Antigram is more practical. Just hook into the website itself, hide the dopamine-production inducing elements, such as "shorts", hide recommendations, but keep the UI the same.
Fair critique. The browser extension approach works well on desktop but does not work on mobile at all, which is exactly where the algorithm does the most damage. That's the gap NoSuggest is filling.
Sorry about that. I have some stuff set up to wane off AI and bots, I was getting hit with a lot of recursive traffic from Perplexity and OAI-SearchBot.
Author of Symbolica here! If these packages work well for you, then just use them :) I don't have a lot of experience with using these tools, but the last time I tried the user experience isn't so great, because of lack of LSP support (no typing, autocomplete etc). It could have improved in the mean time. I believe the tools are also more oriented to polynomial algebra and no so much for manipulating general expressions.
Everybody I know uses IM systems like Wechat, WhatsApp, Telegram, Signal.
reply