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.
Ownership is not the same as authorship. Copyright is about authors rights, not owners.
If you buy a text of me, I cannot sign away my authorship, and there’s certain limitations on what you can do with my text regardless of contract. I can only sell you usage rights - which may or may not be exclusive. If the text I wrote is trivial, neither you nor me can limit when it is reproduced. The effort of collecting data is not sufficient, if the data itself is declared trivial. See rulings about phone books.
When an AI provider produces data that is deemed not copyrightable, it cannot legally sell you exclusive usage rights. It can give it to you exclusively, but since you cannot yourself claim copyright, the moment you publish it it becomes available for others to use as well. One may argue that an LLM is similar to a phone book, with its entries being “trivial“ and its composition not artistic enough.
I think it’s dangerous to play around with this without blood tests. That said, I do use D3 and B12 supplements, since I always scored low when getting tested, and I do feel better now that I do.
Most effect on my health and diet has therapy. I do believe there is only so much you can do “by force” (willpower), and it’s much nicer to do it by tuning the underlying programming (eg. parts work/ifs and the like).
EU? There’s almost zero information on the company, no privacy policy? The only place I found any mention is the footer, “HID Global Corporation, part of ASSA ABLOY”. Assa Abloy seems Swedish but HID Global is a US company as far as a quick search goes. But without a proper company info page and privacy policy I wouldn’t consider it anywhere near a “good alternative” regardless.
Jumping in here since we’ve been seeing more mentions of ZeroSSL lately, likely related to the recent CA/B Forum discussions around 1‑year certificates and ACME automation.
- We’re based in Austria (ZeroSSL GmbH). The company was acquired by HID in 2024, which is part of Assa Abloy (Sweden).
- We’re not positioning ourselves as a purely EU-based CA substitute, and we generally don’t market it that way.
- For DV certs specifically, we act as a distributor. Under the hood these are Sectigo-issued certificates, similar to how other providers (for example Namecheap) operate.
Sectigo used to be Comodo's CA business. If memory serves, that business was purchased by a US PE firm and renamed "Sectigo". Sectigo Inc.'s corporate headquarters is now in Scottsdale, AZ.
There's no reason to believe they're any less subject to US jurisdiction than LetsEncrypt.
There were reason to believe they were less subject to US juridiction: their Subscriber Agreement is for "Sectigo Limited, a limited company formed
under the laws of England and Wales".
See https://www.sectigo.com/uploads/backgrounds/Certificate-Subs...
Sadly, their United Terms and Conditions in section 8.2 are even more restrictive than LE's.
They reject any entity
"located in, incorporated under the laws of, or owned (meaning 50% or greater ownership interest) or otherwise, directly or indirectly, controlled by, or acting on behalf of, a person located in, residing in, or organized under the laws of any country sanctioned under the laws of the U.S. or E.U."
See https://www.sectigo.com/uploads/backgrounds/United-Terms-and...
From a layman point of view, it could even mean that the ICC and the UN are prohibited from using Sectigo.
The Customer must have no "affiliates, officers, directors, or employees" that are on sanction lists, and the US have sanctioned some high-profile members of the UN and the ICC that spoke about the genocide in Gaza.
If so, we still need to follow guidelines from our parent Assa Abloy, a public company from Sweden, which has itself a list of restricted countries they are doing business in.
If they do business in the US they will be expected to comply with US law - this includes their stock being traded on US stock exchanges.
If they don’t have any business in the US and any financial ties to the US they won’t be subject to the sanctions. But I believe it will create issues if they want to enter the US market.
The privacy policy is under legal in the footer, exactly where I'd expect it to be honest. It also gives the company registration:
> 1.1. We, ZeroSSL GmbH, FN 443956b (the “Company“)
and below that the company address (registered in Austria).
Don't get me wrong, I agree that there is some lack of "who actually runs/controls this", especially on the about page where I expect such things to be.
At the very least it's not as transparent as I'd wish from a CA. E.g their Certificate Agreement is from Sectigo, so are they involved? No mention anywhere else from what I can see.
Sorry to tell you but it’s not grey area, it’s full on black. You do not have permission to share such data with a third party provider that doesn’t have strict privacy guarantees and that you have a data processing agreement with. TOS are not sufficient.
Discord could well run on top of IRC the protocol and be open to federation without any change of UX.
reply