ircdocs / modern-irc Goto Github PK

Describes colours, bold, italic, all that junk. Start off with just the basics, expand it where client support is actually available and exists.

Requested on IRC, adding the hex colour codes to the formatting doc would be good. Need to be denoted as not a lot of clients support them iirc

This is a difficult command to specify, so I'll create an issue explicitly for this. This is to specify the command itself, as well as the related numerics.

The RFCs don't have much actual real specs on it, so this will need to be almost 100% retrieved from real implementations.

please help

This is something the plain RFCs sorely lack, and would make sense to include to clarify some edge cases around message parsing and similar. Look at DanielOaks/irc-parser-tests for inspiration.

Some extra clarifications from @Jonast to look at

1. Clarification of nothing else may be sent before login sequence is completed:

"The server MUST then respond as though the client sent it the MOTD command, i.e. it must send either the successful Message of the Day numerics or the ERR_NOMOTD numeric." -> "The server MUST then respond as though the client sent it the MOTD command, i.e. it must send either the successful Message of the Day numerics or the ERR_NOMOTD numeric. The server MUST NOT send any JOIN, PRIVMSG, MODE or any other not login-related event before this entire login sequence is complete and everything up to the MOTD or ERR_NOMOTD has been sent."

2. Maybe a note should be added for future numerics (since this discussion also was about some future flexibility for new implementation additions and protocol updates), mainly as a heads up to client devs to not make things explode:

"... and at least one RPL_ISUPPORT (005) numeric to the client. The server SHOULD then respond [...]" -> "... and at least one RPL_ISUPPORT (005) numeric to the client. Now, any additional numerics for additional login and server information MAY be sent if supported by this specific server only, although it is not recommended to server authors to send any such additional non-standard numerics unless they were enabled by a related CAP request of the client. The server SHOULD then respond [...]"

This is an important part of IRC too. Take a look and see what specs (/IDs) exist for this and base ours off them, specifying what actual clients can do today.

Examples:

• http://about.psyc.eu/IRC_URI
• https://www.w3.org/Addressing/draft-mirashi-url-irc-01.txt
• https://tools.ietf.org/html/draft-butcher-irc-url-04

Current branch: url

Please fix/add:

^C,<COLOR>

This is especially useful when combined with RGB colors.

I like IRC. But I'm not sure I understand the low-level thing, so here are my two assumptions:

1. It can support web socket? (server end?)
2. It can filter content in a channel, ex.: I can set myself to a mode when in a channel, where I only accept receiving those messages @ me, or for some keywords show up. (maybe client end)

As of its future v2.3.0 version, the Help window of The Lounge will now be pointing to http://modern.ircdocs.horse/formatting.html#colors to explain/list colors to users (see thelounge/thelounge#1034).

It would be really nice if we could direct our users to an HTTPS version of this site.
I realize this website is served with GitHub Pages which supports both custom domains and HTTPS but not at the same time. I am not a sales rep or anything, but I have been using Netlify (for free) for this exact purpose and HTTPS, HSTS, HTTP/2 and GitHub integration comes for free. It's a 1-click thing like GitHub Pages, nothing to configure.

Would be good to do.

RFC1459 and 2812 both contain the following:
LIST [<channel>{,<channel>} [<server>]]

Same thing for NAMES

We don't define that <server> parameter... this is irritating. Add <server> param and go over method for determining if supplied param is <server> or elist stuff.

We don't currently define these. Probably good to.

• RPL_ENDOFWHO
• ERR_WASNOSUCHNICK
• RPL_CREATIONTIME
• RPL_TOPICTIME -> actually RPL_TOPICWHOTIME

various measures to stop clients from sending 900000 messages and spamming the ircd to death, look at them and see if we want to add a section on them (as well as recommended actions for clients). may even fit best into a totally separate document if we want to add it at all (my initial thoughts are towards not doing it)

I think I accidentally refer to LUSERS as LUSER in a few places. Investigate and fix.

Would be good to do, and perhaps even a mention of the 'flattened' architectures networks tend to push towards users these days in general.

Suggested by @sdaugherty

Simply put, clients shouldn't put prefixes on messages in general. esp. not when it's just their nickname. Just wastes space and makes things a bit more fragile. I should recommend avoiding it.

Now we have a CTCP doc. Hooray!

DCC is also fairly widely used so we should probably look at having a document that covers that in some way.

Rough initial references:

• https://web.archive.org/web/20080907101746/http://www.invlogic.com/irc/ctcp2_5.html
• http://patrick.cloke.us/posts/2011/03/08/so-called-irc-specifications/#id6
• http://www.irchelp.org/protocol/dccspec.html

Were these ever actually implemented?

• https://tools.ietf.org/html/draft-smith-irc-dcc2-negotiation-00
• https://bitbucket.org/clokep/irc-docs/raw/default/draft-smith-irc-dcc2-files-00.txt

Mentioned in #ircv3, should take a look and see what's going on maybe.

Not really related to modern-irc work but I'll throw the issue here anyway.

Unreal3.2.10.6

Example log:

    -> CAP LS
    -> CAP REQ :multi-prefix sasl
    -> CAP END
    <- :irc.adichat.dk CAP pereba_ LS :account-notify away-notify multi-prefix sasl tls userhost-in-names
    -> AUTHENTICATE PLAIN
    <- :irc.adichat.dk CAP pereba_ ACK :multi-prefix sasl
    <- :irc.adichat.dk 487 pereba_ :AUTHENTICATE is a server only command
    -> CAP :LS
    -> CAP REQ :multi-prefix sasl
    -> CAP END
    <- :irc.adichat.dk CAP pereba_ LS :account-notify away-notify multi-prefix sasl tls userhost-in-names
    -> AUTHENTICATE PLAIN
    <- :irc.adichat.dk CAP pereba_ ACK :multi-prefix sasl
    <- :irc.adichat.dk 487 pereba_ :AUTHENTICATE is a server only command

That is, the pings that happen during connection where the registration won't continue without the client responding to them.

Recommended on the channel:

Hey, I was wondering if there is any documentation on connection handshakes. Most networks do an id-ping after connecting - freenode somehow doesn't.

We should specify octets vs bytes in modern doc (i.e. 512 length for messages). Stay consistent with RFCs

Related to #41

Firstly, RPL_ENDOFINVITELIST 347 is mislabelled as 349 on modern, but perhaps we should also mention the mess of compatibility that is invite lists.

Firstly, invite lists can mean two things:

• Lists of invex masks for a channel (INVEX)
• Channels that you have been invited to (chan invites)

InspIRCd demonstrates this the best by reusing the numerics for both lists, but with different argument lists (so it is at least parseable)

# Lists masks with an invite exception (invex)
-> MODE #chan +I
   <- :irc.example.com 346 nick #chan invitee!*@* inviter 1496743061
   <- :irc.example.com 347 nick #chan :End of Channel Invite Exception List

# Lists channels you've been invited to with INVITE
-> INVITE
   <- :irc.example.com 346 nick :#chan1
   <- :irc.example.com 346 nick :#chan2
   <- :irc.example.com 347 nick :End of INVITE list

A quick review of other ircds:

• ircu2.10.12.13: Only supports 346/347 for chan invites (says IRCnet, Undernet extension), no invex support
• charybdis 3.5.3 and 4-rc3: Only supports 346/347 for invex lists, no chan invite support
• inspircd 2.0.23 + 3.0.0a1: As above, uses 346/347 for both invex (via a module) and chan invites (builtin, says stolen from ircu2)
• unreal 3.2.10.7 + 4.0.9: Uses 346/347 for invex (calls them RPL_INVEXLIST and RPL_ENDOFINVEXLIST) and uses 336/337 for chan invites. Those numerics are used for various whois extensions in other ircds

Apparently RPL_TIME can sometimes have some optional args. Find out what they are and document those as well:

Brought up by DarkMio on IRC:

time on gamesruge: * Prothid.NY.US.GameSurge.net 1470084003 0 :Monday August 1 2016 -- 16:40 -04:00
freenode: * kornbluth.freenode.net :Monday August 1 2016 -- 22:39:41 +02:00
qnet: * port80a.se.quakenet.org 1470084021 0 :Monday August 1 2016 -- 22:40 +02:00

Most servers today let you send the nick as the first argument. Keep an eye out when we actually start writing that command up and make sure we define it properly.

Go around and evaluate clients. See how many do implement support for 99 == fore/bg color, and how many do not. Put it back into the doc or don't based on that.

Makes sense to do

• It's currently listed as RPL_TOPICTIME in this document
• The name RPL_TOPICWHOTIME seems to be used by most. Notable exceptions are InspIRCd and this document. ~80 hits on google for RPL_TOPICTIME, ~2.4k for RPL_TOPICWHOTIME
• It seems it originated from ircu as RPL_TOPICWHOTIME (according to https://www.alien.net.au/irc/).

In summary, it should likely be renamed to RPL_TOPICWHOTIME in the document.

Secondly, the format for this numeric is currently documented as:

"<client> <channel> <nick> <setat>"

However, this does not seem to hold for all IRC servers: at least freenode (ircd-seven?) returns a mask (i.e. nick!user@host) rather than just a nick for the third argument.

i.e. investigate writing a cut-down CTCP document that should work in the real world.

Should we do this? Seems like CTCP is kinda in the same place that formatting is, a hundred specs of varying ages, all followed to various degrees and most all of them specifying some stuff everyone supports, some stuff some people support, and some stuff almost nobody supports.

Note how RPL_UMODEIS may be sent on connect if modes are set on the client, see also the changes I made in ergochat/ergo@b820559

We're running out of control codes. To avoid running out of control codes, let's come up with an extensible formatting scheme that doesn't run out of control codes.

I propose something like ANSI escape codes, but designed with IRC in mind. That way, we have infinite control codes and infinite formatting styles and it's trivial to add new ones.

Marquee, blink, etc could be added without conflicting with existing control codes. In addition to that, some codes are currently used for encryption and such, so they'd conflict too.

The RPL_ISUPPORT links here contain an underscore whereas the actual link does not ('#rpl_isupport-005' vs '#rplisupport-005')

@thommey brings up a good point in channel, which is that clients should act fine if they get INVEX (and default to INVEX=I, but what if they receive INVEX=... will they override the default INVEX token value with literally an empty string?

Makes sense to list defaults in a lot more of these keys than we currently do

epoch makes sense, but maybe it's something else weird? look at source code and all to see what's widely supported.

If we don't already, we need to have a good Security section, detailing like the issues I found with Ergonomadic and which other servers/clients may run into.

Write dis up. Data from stats.ircdocs.horse should help things here.

We haven't got a format written down for ERR_ALREADYREGISTERED. We should do that.

If we don't already, we should have sitemaps for Modern (and defs, and etc). Take a look and see whether it outputs them already, and if it doesn't then go through adding it.

These are commands that are generally accepted and supported on IRC daemons. So long as we have notes that these commands MAY NOT be supported by servers, should be fine to include them.

• KLINE
• UNKLINE
• DLINE
• UNDLINE
• SA* -- SAMODE, SANICK, etc etc. SA may stand for Service Admin? If so, these are probably safe to simply ignore without any issues? Eh, investigate and see what servers do, I think these may be loadable modules in most IRCds that do support them anyway, rather than built-in proper

to document this at some point. keep in mind inspircd/inspircd#1272

We can cleanup the language in there further, look at that again with the Hardy draft we have in our info/ directory.

This is still used with NICKSERC/NS/CS commands, and users can usually send PRIVMSGs to something like [email protected] or whatever.

However, if they are still processed otherwise, they may be mostly restricted to IRC Operators. Especially ones that go to multiple targets.

Thanks to @sdaugherty for pointing this out

At least EPIC supports flash/blink formatting. I'm not sure if it's enabled by default, but it at least parses it.

Seems to be \x06.

RFCs say server names and hostnames can only be a max of 63 characters, do servers actually respect that these days or do they allow longer names?

Related, is there an RPL_ISUPPORT token that specifies HOSTLEN or something (I think mammon may have proposed one, check out irc-defs lists).

Try to get clients to agree to do them consistently, or something.

Right now this warning suffices in the Reverse Color / Italics section, but it shouldn't be necessary.

Maybe we don't even need reverse colors, and we can just throw that into the list of characters at the end that we just write off as unusable / we don't recommend touching.

JOIN 0 sent by a client usually means part every channel. How widespread is this in servers, and should we be documenting it here?

This is a very annoying issue. The Table of Contents popup (button down the bottom) will not activate for Mobile Safari. I've tried several different methods of clicking the button, bubbling events and adding various attributes to get it to play nice, but it doesn't seem to want to work for me.

To investigate more. I really don't want to have to add jQuery or something for a single .bind() call.

ERR_PASSWDMISMATCH is used when password is incorrect. Investigate what IRCds do and then specify that they should do that if the p/w is bad.

There are lots of numerics we need to add.

• RFC1459 numerics (minus obsolete ones)
• RFC2812 numerics (minus obsolete ones)
• Other widely-used, non-conflicting numerics (see irc-defs)
• IRCv3 numerics

This is a tracker of commands and messages from RFCs that are missing, and should be added.

• PRIVMSG
• NOTICE
• MODE
• TRACE
• INVITE
• KICK
• LINKS
• WHO
• WHOIS
• WHOWAS
• KILL
• PING
• PONG
• ERROR
• REHASH
• RESTART
• WALLOPS
• ISON
• SQUIT command

There are some others in the RFC that exist (SUMMON, USERS), but I don't think they have much applicability to servers or networks today. Put them in that section at the end where we list things we don't like or support these days.

once ircdocs/irc-defs#18 is solved, copy explanation here for extbans