7 ms·
Modern IRC Client Protocol
- mikece 5y agoI love IRC: it's the protocol that will NEVER die!
- GoatHerders2 5y agoNerrrrd!
- bovermyer 5y agoEh, I think an asteroid cracking the planet in half would probably kill IRC too.
- kook_throwaway 5y agoJust a netsplit.
- marcodiego 5y agoObligatory xkcd: https://xkcd.com/1782/ https://xkcd.com/1782/
- jbverschoor 5y agoThe net used to be a good place with open protocols.
- harryvederci 5y agoQuestion about the ascii diagrams: did you create them manually, or with a tool? I'm curious because I'm creating a tool that does this as well :)
- mmh0000 5y agoThere are several commonly used tools to create ASCII diagrams, one of them, asciiflow [0], was featured recently on HN. [0] https://asciiflow.com/legacy/ https://asciiflow.com/legacy/
- Macha 5y agoGiven the age of this particular ASCII diagram (28 years), it was likely hand written, however.
- rdpintqogeogsaa 5y agoThese diagrams were taken out of RFC 1459 sections 1.1 and 3.
- dragontamer 5y agoIRC's operator model is pretty awful though. In the 80s when IRC was designed, they didn't foresee the importance of channel #names. Today, we know that names are incredibly important (paying big bucks to keep your domain name in your control, as well as enforcing your names with trademark law where appropriate). The fact that you can lose "control" of a #channel if you simply log off is a fundamental problem of IRC. Its a known problem: you have bouncers and services (ex: NameServ or ChanServ) to solve this problem. --------- So "raw" public IRC doesn't work. At a minimum, we need NameServ and ChanServ (and probably a few other bots) before we can make a competent, modern IRC service. I realize that's where IRC v3 was going (standardizing which bots were enabled). But it should also be noted that xmpp avoids the issue all together with a different channel security model. ------- Hmmm, maybe there should be an IRC service with a policy to automate #op control to DNS lookups or something. That way, #channels can be connected to DNS lookups and unambiguous? I'm thinking something similar to email / DNSsec style lookups that proves ownership of a name.
- toast0 5y agoFirst to join gets ops is just a convention. You could certainly write a IRC server that requires strong authentication (client certificate maybe?) and enforces whatever policy you like. Maybe #dragontamer isn't joinable unless you are in it, and of course you would get ops when you join.
- dragontamer 5y agoIts not #dragontamer that people are worried about in practice. It'd be #ubuntu, or #linux. Who is the operator of the channel? The names don't really collide on Discord. Everyone gets their own private "server" instance.
- toast0 5y agoWhoever the server/network blesses. Typically, networks tend to bless whoever got there first, and with ChanServ services, whoever got there first and comes by once in a while. But if you control a server/network, you can do what you like. This isn't really a protocol problem though. You could certainly run a small IRC server for you and whoemever you could convince to connect, and there's room for some sort of virtual private IRC where anyone can have their own server instance and do whatever. Technically, it wouldn't be too hard; servers and networks are way better than around 2000, and user counts are way down from the peak; dealing with abuse might be a big issue though... IRC servers tend to be DDoS magnets, and botnets and whatever other unsavory stuff.
- nicolaslem 5y agoI used this documentation to go from zero knowledge of IRC to writing my own client. I have been hanging on IRC using it ever since, it's pretty satisfying!
- lazyfanatic 5y agoWhat did you write it in?
- nicolaslem 5y agoPython with asyncio. I don't think it will be useful to anyone else but here is the source https://github.com/NicolasLM/eternal https://github.com/NicolasLM/eternal