Document/specify irc:// URI

[Zarthus]

https://en.wikipedia.org/wiki/Internet_Relay_Chat#URI_scheme

Normalizing how this should behave would be excellent, the wiki page itself mentions some caveats right out of the box saying how messy it is.

• mIRC prepends a # regardless, good job, Khaled! (# is not the only channel prefix)
• Only some implementations support commas.

Proposed solution:

Normalize the spec, saying

• clients should assume # as default channel if it doesn't start with an alnum character
• Do not prepend a # starts with an alnum character
• Support commas.
• Explain the differences between ircs:// irc:// and irc6://

[DanielOaks]

probably related / useful: https://github.com/ircdocs/modern-irc/issues/6

[dpyro]

RFC 3986 contains what a new URI scheme should be based on..

Here is the provisional IANA irc scheme.

I think it would be desirable to include specifying user targets, not just channel targets. Also, I propose commas be used for specifying multiple targets. Often an IRC community spans across multiple related channels. New users may need to register with a nickname service or channel bot while connecting to certain channels.

Example: irc://[email protected]/#irc,#ircnews,Q Or maybe: irc://[email protected]/irc,ircnews,@Q

(The @ and #s may not work with the generic URI behavior, I have not researched this yet.)

[Zarthus]

@ might be a channel prefix (in some twisted world?), in what scenario would opening a query with an user be beneficial?

Without prefix for queries you're going to break a list of existing links, so that's a no-go.

[ghost]

I think it would be desirable to include specifying user targets, not just channel targets.

I agree. While the more common use-case is certainly for channels, I do not believe the specification should limit itself to this instance. There are cases where it may be desirable to specify a user query. Likewise, defaulting to # is not always correct, as some networks use other prefixes as their primary channel designator.

The target(s) parameter (I'm also in favor of allowing multiple targets to be specified) should be interpreted "as-is", be it a user, #channel, or <non-#>channel.

[prawnsalad]

I've been dealing with this on the new kiwiirc release recently. Currently I'm using comma delimited targets and prepending # if it doesn't already exist. eg:

• irc://irc.example.com/chan1,#chan2 = #chan1 and #chan2
• irc://irc.example.com/#chan1,##chan2 = #chan1 and ##chan2

This is purely due to how existing clients work and trying to suit the mast majority of URIs out in the wild. Based on feedback with kiwiirc for the past few years opening a target as a user query has been a frequently requested feature but there is no way to merge this in place with this.

Unfortunately with so many irc:// links in the wild this isn't something that can simply be changed with a CAP os ISUPPORT, so backwards compatibility must be thought about more harshly.

[prawnsalad]

Another thing that was very shortsighted in the wiki page is the channel key being the entire query string part of the URI. It leaves no option for anything else.

I've had to re-implement the query string as ordinary paramaters. Eg:

• irc://irc.example.net?nick=mynick
• irc://irc.example.net?nick=mynick&encoding=utf-8
• irc://irc.example.net/channel?nick=mynick&encoding=utf-8

This isn't perfect as adding #channel to the URI now should be technically after the querystring and not after the path as most would expect.

[dpyro]

We could specify user targets with an explicit @. It would also be obvious to users that it is a user-target, since the @ signum is currently used on every major social networking service (that I know) to indicate a user handle.

Channel names that begin with @ could be escaped.

[realJoshByrnes]

This is one thing that has driven me insane for years. I know IRCX isn't the most common type of IRCd, but there are a few around.

As per the most recent IRCX draft back in 1998

              #       The '#' prefix identifies a RFC1459 global channel.
          
              &       The '&' prefix identifies a RFC1459 local channel.
          
              %#      The "%#" prefix identifies an extended global channel
                      name (a modified UTF8-encoded UNICODE string).
          
              %&      The "%&" prefix identifies an extended local channel
                      name (a modified UTF8-encoded UNICODE string).

It also specifies how to interpret other prefixes.

The most common type of channel on IRCX is %#, and depending on client you may get #%#Channel, #Channel, or (rarely, but correctly) %#Channel.

[prawnsalad]

Incase anyone is still following this thread, it might be of good knowledge that kiwiirc is about to publish itself using the following format:

• irc[s]://irc.server.net:[+]6667/channel,#channel2?param=val&param2=val2

Where if channel does does not begin with a # then it will be prepended. The query string params include such as encoding or password.

This seems to be mostly backwards compatible with what's out there already as I can't find any live uses of passwords taking up the entire querystring value.

[realJoshByrnes]

@prawnsalad Could you consider also allowing % (and &) channel prefix? KiwiIRC does work fine with our current setup, except that it tries to join #%#Channel instead of %#Channel when using the autojoin methods.

Using the /join command manually works fine, which isn't really consistent.

[vanrein]

[RFC 3986 contains what a new URI scheme should be based on.] ... I think it would be desirable to include specifying user targets, not just channel targets.

This should then be done as the RFC indicates, meaning as part of the authority section. In other words, you would be switching from the host's default view to a user-specific view, which might be completely different. A bit like a namespace for IRC, one might say.

In terms of IRC, this sounds like a private chat address to me. But you could take it further, and let individual users decorate their own set of channels, local to them and/or shared with the host's view.

Note that I'm not saying anything about authentication; as I read the RFC that is an orthogonal issue that might apply to each channel independently, whether in the host's view or a user's.

[vanrein]

Now about security and privacy: IRC URIs with user names are interesting, because they express user-to-user connections, and so hint at end-to-end authentication and encryption. This is something I've been thinking about a lot, imagining instructions like /PRIVMSG STARTTLS, but it makes more sense for IRC URIs with a user name part because that way the entire connection uses one form of encryption.

End-to-end encryption can take on several forms; OpenPGP can be used in TLS, and we have a TLS-KDH ciphersuite in the making that can do it with TLS and Kerberos tickets (which, incidentally, would proof IRC against Quantum Computers).

[TingPing]

Just for documentation: HexChat's uri support

[vanrein]

I just pushed a blog article about the use of user names in URIs -- and them defining authority sections, not authorisation hanging points. And about HTTP lagging behind IRC in some ways ;-)

If so desired, I'm willing to work on a spec proposing a user@ extension to URis and incorporating client-to-client security through TLS and/or Kerberos. Ideally, this would be in collaboration with a coder who already works on IRC software. So just mail me if you need a cryptographer :)

Regarding Kerberos: KDCs can facilitate client-to-client connections, as long as there is a way to get them together. This has long awaited a suitable protocol :)

[jesopo]

Something that's not been mentioned: why would you need to denote a user target with a @ when clients already often decide if something is targeted at a channel or not by checking against CHANTYPES? Seems like we're just going to make it impossible for channels to start with @ while gaining absolutely nothing.

[DanielOaks]

When most clients handle irc: URIs, if the arg doesn't start with # they'll just prepend that (e.g. /dan -> joining the #dan channel), and it wouldn't be great to break every existing IRC URI in existence since a lot rely on this behaviour.

[jesopo]

So we either break non-prefixed-channel URLs or we break @ channels?

[DanielOaks]

if @channels were used in any way by anyone I'd be a bit more concerned. It's a bit ugly which is why I'm not a big fan. That's also just one proposal, not a set idea on how to represent it as far as I'm aware :)

[vanrein]

The URI format RFC prescribes user@ as part of the authority, just like the host name. It may therefore be used to scope what is presented, similar to "virtual hosting", and could present a limited view on the IRC resources shown (though that would be a server-specific implementation choice). It may also give rise to different access controls.

The choice to interpret the user@ part as a channel is a local choice to be made by the IRC server. It may mean anything else, including even channels specific to the user.

A concept that we're playing with is the usual IRC service without the user@ and a security-tightened access [0] when user@ is added. For now, an idea we're exploring, but not yet doing.

[0] authenticated [email protected] with communication ACLs to have secure group communication support. We do that across a variety of protocols using the same ACLs, and IRC might be nice to include.

[jesopo]

My proposal for this is:

We use @ to denote private messaging and use @@ (which will translate to @) to denote channels that start with @ - just in case this edgecase ever happens.

As far as I'm aware (haven't found a citation) @ is universally forbidden in nicknames due to

1. +o channel mode
2. @ being used as a delimiter in hostmasks (I'm sure it'd break a handful of clients)

[jesopo]

As far as I'm aware (haven't found a citation) [...]

https://tools.ietf.org/html/rfc2812#section-2.3.1

nickname = ( letter / special ) *8( letter / digit / special / "-" )

letter = %x41-5A / %x61-7A ; A-Z / a-z digit = %x30-39 ; 0-9 hexdigit = digit / "A" / "B" / "C" / "D" / "E" / "F" special = %x5B-60 / %x7B-7D ; "[", "]", "", "`", "_", "^", "{", "|", "}"

[emersion]

It would be nice to be able to refer to a specific message via an irc:// URL. e.g.

irc://irc.ircnet.net/#worldchat?msgid=asdf

[nektro]

so that links are able to survive channel-rename we should write a channel-ids spec as a parallel to message-ids

[nektro]

then the urls could be irc://irc.ircnet.net/chanid/msgid and be hydrated with the current info in a UI

[Summertime]

I feel like the best option would be to make a clean break of some form, and move to irc3:/ircs3:, and expect that the target is both complete and URL encoded, /%23channel.

I would be surprised if there were two separate clients with completely matching irc:/ircs: behaviors, so, trying to standardize that would change the meaning of those uris for all but one client, if lucky.

---

In turn, it would probably be best to find a list of in-the-wild irc:/ircs: links from something like https://commoncrawl.org/, and standardize based on what forms are most used.