[HN Gopher] Modern IRC Client Protocol
___________________________________________________________________
Modern IRC Client Protocol
Author : rdpintqogeogsaa
Score : 72 points
Date : 2021-08-23 17:29 UTC (5 hours ago)
(HTM) web link (modern.ircdocs.horse)
(TXT) w3m dump (modern.ircdocs.horse)
| mikece wrote:
| I love IRC: it's the protocol that will NEVER die!
| GoatHerders2 wrote:
| Nerrrrd!
| bovermyer wrote:
| Eh, I think an asteroid cracking the planet in half would
| probably kill IRC too.
| kook_throwaway wrote:
| Just a netsplit.
| nicolaslem wrote:
| I 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 wrote:
| What did you write it in?
| dragontamer wrote:
| IRC'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.
| r3dk1ng wrote:
| an IRC service kind of like how this was?
| https://news.ycombinator.com/item?id=12490685
| orthoxerox wrote:
| That's not the only problem with IRC. There's no channel
| history, no multi-device support, no replies or mentions, no
| media sharing, it lacks many things we take for granted these
| days.
|
| I spent a lot of happy hours on IRC 20 years ago, but I
| wouldn't want to go to a barebones protocol like IRC in 2021.
| toast0 wrote:
| First 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.
| Lammy wrote:
| > In the 80s when IRC was designed, they didn't foresee the
| importance of channel #names.
|
| The network itself used to provide the namespace. What we
| didn't foresee were all the economic/political pressures that
| would eventually lead us to Centralize All The Things.
| marcodiego wrote:
| Obligatory xkcd: https://xkcd.com/1782/
| jbverschoor wrote:
| The net used to be a good place with open protocols.
| harryvederci wrote:
| Question 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 wrote:
| There are several commonly used tools to create ASCII diagrams,
| one of them, asciiflow [0], was featured recently on HN.
|
| [0] https://asciiflow.com/legacy/
| Macha wrote:
| Given the age of this particular ASCII diagram (28 years), it
| was likely hand written, however.
| rdpintqogeogsaa wrote:
| These diagrams were taken out of RFC 1459 sections 1.1 and 3.
___________________________________________________________________
(page generated 2021-08-23 23:02 UTC)