Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?

An update

2015-02-22: I think I found some bugs in these rules since the last time. But I don't remember exactly what they were.

Either way, most of the time you're going to see only server.example.com and nick!user@host.

The odd ones are generated by PSYC. For example>

  • psyc://psyc.wirefull.org/~fosco!fosco@psyc.wirefull.org
  • psyc://psyced.org/~rjsalts!psyc://psyced.org/~rjsalts@psyced.org
  • xmpp:grawity@nullroute.eu.org!grawity@nullroute.eu.org

Just make sure you can parse this garbage, that's all.


On parsing of the prefix

This is the correct way to parse the nick!user@host prefix:

  • Start search at the beginning of the string. This shall also be the start of the nickname.

  • Search for a ! character. If found, it shall mark the end of the nickname; the following character shall be the start of the username; and the next search shall continue at this position. If not found, return to the beginning of the string for the next search.

  • Search for a @ character. If found, it shall mark the end of the username (or nickname if the username was not present); and the following character shall be the start of the hostname field.

Examples:

  • nick!user@host shall be parsed as nick (nickname), user (username), and host (hostname).

  • foo@bar!baz shall be parsed as foo@bar (nickname), baz (username), and empty hostname.

  • foo@bar shall be parsed as foo (nickname), empty username, and bar (hostname).

  • nick@kcin!user!resu@host!tsoh@host shall be parsed as nick@kcin (nickname), user!resu (username), and host!tsoh@host (hostname). The parser shall also sigh deeply.

  • xmpp:user@host.tld!user@host.tld shall be parsed as xmpp:user@host.tld (nickname), user (username), and host.tld (hostname).

  • psyc://psyced.org/~grawity!grawity@psyced.org shall be parsed as psyc://psyced.org/~grawity (nickname), grawity (username), and psyced.org (hostname).

Rationale:

Some servers send unusual nicknames containing an @ character, despite it being disallowed by all existing IRC standards.

Almost all existing clients accept prefixes containing such nicknames, by first searching for a !, then resuming at that position to search for the @.

However, some clients just split the prefix into tokens at any occurence of ! or @ (or regex /[@!]/), then use the first three tokens as nickname, username, and hostname respectively, resulting in different values.

To deal with such weird servers, and generally to make parsing of the prefix consistent, the former behavior is declared correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment