ircv3 / ircv3-ideas Goto Github PK

Hi,

As discussed in #ircv3, it would be nice to have a feature which permit to jump to a message of the backlog instead of having to say "Can you please take a look at the message at 17:42 on this channel?".
A simple way will be to have a standard parsing rule/format which parse every timestamps and by default, jump to this timestamp of the actual channel (it needs to be discussed how we can do the same if we make reference to another channel).
As suggested on #ircv3, it can also be a metadata like @link={msgid}.

Regards,

Every time a new client feature comes up that involves automatically loading images/URLs supplied by other clients, we get into this discussion about privacy/security vs convenience. As a result of that, whatever spec it is has to go through lots of back-and-forth that gets repeated for every similar sort of spec that gets suggested.

Maybe having a short considerations document we can link to that goes over some of the privacy/security/convenience arguments and some options for client authors on how to handle it would be useful in preventing those arguments going forward? Things like, if you're implementing a feature that automatically loads image URLs supplied by other clients, you may wish to provide the ability to enable/disable this feature, or only loading the given URL when users <click on it, do something else to trigger the loading of it, etc>.

This might, strictly speaking, be a bit outside the scope of the WG but it relates pretty directly to us actually getting specs written. If there was some document like that we could point to as basically implementation/security considerations concerning loading client-provided URLs then I'd feel more okay about going forward with those specs that involve them.

IRCv3 is rather vague on how create new subcommand responses and add new numerics, guidelines and/or style guides on how to handle this would help ending up with inconsistencies in the future

Small sample:

A command /TEST returns the subcommand response.

TEST ERR SOME_ERROR

Guidelines could exist for "the error should always be ERR, not ERROR", "SOME_ERROR" has to be in all caps, and "on success just return the result."

In a similar vein, we don't know whether we're supposed to pull numerics out of our arse either.

Networks often provide services alongside the network such as wikis, pastebins, polls, etc. In the cases where a service is tied to a channel there could be a function for the IRCd to provide a JWT token that the service can verify the user with, without needing to resort to more complicated bots/xmlrpc/etc.

In my test case I'm using the JWT token in a web client to send to a audio/video call service which verifies then uses the modes from the token to apply permissions and grant access. Currently this works great and is very simple to make use of.

Example:
C -> S BUFFERTOKEN #testchannel
S -> C BUFFERTOKEN #testchannel eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjaGFubmVsIjoiI3Rlc3RjaGFubmVsIiwiZXhwIjoxNTI5OTE3NTEzLCJqb2luZWQiOnRydWUsIm5pY2siOiJ0ZXN0bmljayIsInNlcnZlciI6ImlyYy5leGFtcGxlLm9yZyIsInRpbWVfam9pbmVkIjoxNTI5OTE3NTAxLCJtb2RlcyI6WyJvIl19.WjiZOggLDmF80TbkCcSY5pXnYsnKVj8qnvnpBpDrVZ0

Where that token includes the payload:

{
  "channel": "#testchannel",
  "exp": 1529917513,
  "joined": true,
  "nick": "testnick",
  "server": "irc.example.org",
  "time_joined": 1529917501,
  "modes": ["o"]
}

We could also pass * instead of a buffer name to get a token relevant to the connection in general. Could this be improved or to include other bits of data in the payload that would benefit external services?

Channel owners might want to indicate to clients (particularly those that log everything in the cloud™) that they don't want their channel to be logged, to protect the privacy of their users.

Would a metadata key like nolog, nostore, etc, etc, or something make sense? I feel like channel modes are a bit of a dead-end for standardisation at this point, until we have something like named modes and a registry in place.

It would be on the honour system, but might still be a feature that privacy-minded clients would want to implement.

One obvious issue is that a user might immediately want to override such a setting and log anyway, if they disagree with the channel policy and rely on logs for their own reasons. Would that be an issue?

As long as the default behaviour of a client was to not log, channel owners might be satisfied that it's still a useful mitigation. Of course, you can't prevent all logging as long as people are able to copy/paste, but mitigation may still be worthwhile.

Any thoughts?

Background

This protocol is an adaptation of Matrix.org's Olm and Megolm encryption to the IRC protocol.
Olm is an implementation of the double ratchet algorithm developed by Open Whisper Systems and
first used in the Signal app.

The IRC adaptation is being designed under KiwiIRC with the goal of creating a modern end-to-end
encryption standard for IRC that could be implemented by many different clients.

Peer sessions

Raw byte arrays are base64 encoded without padding for transmission as Message Tag values.

To establish a one-on-one session with another user, we must first obtain their public identity key
and a one-time-key.

# request public identity key
@+kiwi/olm-identity-request TAGMSG bob

# receive public identity key response
@+kiwi/olm-identity=2XA4WCDGeTi9OW/XaiKXN550LUTsw0sQpi0UKANAxWZd7lLodg :[email protected] TAGMSG alice

# request one-time-key
@+kiwi/olm-onetimekey-request TAGMSG bob

# receive one-time-key response
@+kiwi/olm-onetimekey=2XA3WCDNR7uNOVnzjrvXRVA9p3FyHWLUPBP/w+GVUXkXneHYaw :[email protected] TAGMSG alice

At this point, alice can construct an outgoing session to bob using the onetimekey and identity and
start sending encrypted payloads such as OlmMessages:

# encrypted OlmPacket containing an OlmMessage with the text "hello"
@+kiwi/olm-packet=2XA1g1ggGsgfjI52+dKMvHbHOu9ujGcUq+7Z905ah+lh+8rpehEAWKgDCiAjcvT3D6AQNHKzFXOmb6jNssLC7m+G2kHC1AsZsJOaBBIglK1cV5dWjyWpc5aTxcJhTNuXkJdlwb5Msah6jQDp9m0aIBrIH4yOdvnSjLx2xzrvboxnFKvu2fdOWofpYfvK6XoRIj8DCiDVs+9A28hvj/YpQ+7aNgh92SpAZvBJSE6hckSgF8iUZxABIhD4/ZpTTCeh8YnWjSyiEs0qvvmY8j755/o TAGMSG bob

When the first packet is received by the other side, they will be able to construct the session
ratchet and use it to send packets back as well.

Group sessions

For one-to-many encryption (in IRC channels), each sender creates an outbound-only ratchet. This
mitigates some scalability issues with ongoing sessions in large channels by avoiding the need to
encrypt a copy of each message separately for each recipient. First, encrypted one-to-one sessions
must be established between participants, as described in the previous section. Once these secure
channels are available they are used to share the ratchet state for the outbound group sessions.
Further details about the ratchet design can be found in the [Megolm docs].

# encrypted OlmPacket containing a MegolmSessionState
@+kiwi/olm-packet=2XA1g1ggTR6P+jorlFtkqxc8ZjvdqqP598MYtWftFikr+wDhuCYAWQGqAwogSSqvrpm9pz7w2u+CBySrcU7G5PQrNsibQ4Mpa/JfDQwSIJagDGK3zbd23eABM1Z84FnLWb3TBFbjzPjVv0ROVZo/GiBNHo/6OiuUW2SrFzxmO92qo/n3wxi1Z+0WKSv7AOG4JiLAAgMKIEpGWJSu6xndGM1kaRGaSGOIIhXMOhv8jszNhcIrm7hnEAAikAI5NEOwE6EaoLYJkb/jfKaraL9op/XQ7ooLb7c9dnuDa0pelZ01+8VdBqIB+R+RO48dnz+QrN0N3xqHcxHSfOgP8mcdT2TanLVax8DnSgaqaLOlCeIv3vA3HQCl2BVTMUoD7j0s0fQH+v2YOZvUB8IEvVe4AOYNRcRhB+P4yz5s1AQ9/vPmOo6o/Nxu8UOHl7065pplL6ngMR5IGzECVq3ohxYpF0oXXxVT9Q0X7Arm8tLA3+LBLOSAqPfYMPySWw+YXuwwNWOFNbGm4MDVWWr/nzi7GFjc5zTGtBJkBwMAp0Qt40pUUoAdbXkW4hzJrgQnVNBZdYVkg4IDllSKCdcoWPw9/NMEYf3syS+5H1LB8Kdg+gPmEP4t TAGMSG bob

After receiving the MegolmSessionState, any MegolmPackets created with that session from that point
forward can be decrypted.

# encrypted MegolmPacket containing a MegolmMessage with the text "hello"
@+kiwi/megolm-packet=2XA6hFhdAwgAEhCHnBpj2VbBf2pS5C9oV+fJhwMgb7b9IRAdE0Lstg4lSniU/Wc8FJeY5DEE+2feUocZQkaJtRk16oyTrNH+VENClcyHBpGQsnay7qVQWoXtD1oYEKSOmZcNWCBGUHuR6rck9tWqwTbFzXNX3ipREMFLdoBJq7jwot97EFggpJKNuwSzSe+dvEnxGJysH7XnfY9AYnQTmp9PL6ffhH9YQCKLjDvQNdSZVm65HOVCbEmEud3KTL+0rgFLf6M8OukBm91wnZ8+FacjAlzGFJBYYEH3PG2zOUXUSdp7SBqI3wQ;draft/msgid=bqx72n65z1921xh7 :[email protected] TAGMSG #example

All of the protocol sample codeblocks up to this point form a complete key negotiation and
conversation between two users in both one-to-one mode and group mode.

Payload types and serialization

Protocol payloads are serialized to CBOR as tagged entities with the following tag IDs and fields:

OlmPacket

• CBOR tag: 0x7035
• CBOR value: [senderKey: ByteString, type: int, body: ByteString]

The body field can contain an encrypted OlmMessage or MegolmSessionState.

OlmMessage

• CBOR tag: 0x7036
• CBOR value: text: string

A single chat message in a peer session.

OlmOneTimeKey

• CBOR tag: 0x7037
• CBOR value: oneTimeKey: ByteString

Combined with an OlmIdentity, OlmOneTimeKey is used to initialize a new peer session.

OlmIdentity

• CBOR tag: 0x7038
• CBOR value: curve25519IdentityKey: ByteString

MegolmMessage

• CBOR tag: 0x7039
• CBOR value: text: string

A single chat message in a group session.

MegolmPacket

• CBOR tag: 0x703a
• CBOR value: [ciphertext: ByteString, senderKey: ByteString, sessionID: ByteString, signature: ByteString]

Ciphertext contains an encrypted MegolmMessage.

MegolmSessionState

• CBOR tag: 0x703b
• CBOR value: [sessionID: ByteString, sessionKey: ByteString, messageIndex: ByteString]

Contains the ratchet state necessary to decrypt received MegolmPackets from a user.

Message Tag fragmentation

Because the serialized payloads can be particularly large, the message tag data will sometimes be
split across multiple IRC messages.

When a message is fragmented, it is marked with the tag @+kiwi/fragmented. When a message is a
continuation of a previous fragment, it is tagged @+kiwi/previous-frag=<previous message ID>.

Fragmentation is only allowed on the following tags' values:

+kiwi/olm-packet
+kiwi/olm-identity
+kiwi/olm-onetimekey
+kiwi/megolm-state
+kiwi/megolm-packet

The tag values should be split into chunks of as large a size as possible within the limitations of
the Message Tags spec. The chunks do not need to be of equal size, but they must be transmitted in
order.

A client must not interpret the fragmented data until it has been reconstructed, with the final
fragment being indicated by the lack of a @+kiwi/fragmented tag.

For example, @+kiwi/olm-packet=abcdefghijklmnopqrstuvwxyz TAGMSG user could be fragmented as
follows:

# receiver view:
@+kiwi/olm-packet=abcdef;+kiwi/fragmented;draft/msgid=100 TAGMSG user
@+kiwi/olm-packet=ghijklmnopq;+kiwi/fragmented;+kiwi/previous-frag=100;draft/msgid=101 TAGMSG user
@+kiwi/olm-packet=rstuvwxyz;+kiwi/previous-frag=101;draft/msgid=102 TAGMSG user

The sender will need to use a label tag and the echo-message capability to find the
draft/msgid of their sent message fragment in order to reference it with the +kiwi/previous-frag
tag.

Creating a compatible implementation

Our experimental javascript implementation makes use of the C libolm library compiled to WASM with
emscripten. Clients written in other languages should be able to use bindings to libolm to
implement the protocol in without needing to reimplement the cryptographic functions from the Olm
specs. Although the latter always remains a possibility.

Points of difficulty / Room for improvement

Tag fragmentation

1. It's unfortunate to have to reimplement layer 3 IP packet fragmentation inside a layer 7
   protocol.
2. Calculating the available space for each fragment of data is somewhat tedious because it depends
   on the length of the server's generated msgids, whether we're trying to send the first, last, or
   a middle fragment, and so on.
3. Having to use echo-message with a label to find out your own msgid adds significant latency
   since we can't predict or generate our own msgids.
4. Care must be taken to avoid DoS from yourself (if the available data space in client tags was
   very small due to other tags being present) or others (i.e. resource leaks from never completing
   the reassembly process).

Binary encoding overhead

Not having a way to directly transmit binary data causes significant overhead through base64
encoding.

Message Tags vs CBOR tagged entities

There is some impedance mismatch between the Message Tags and the CBOR serialized records. For
example, MegolmPacket packs four different values into one tag because using a separate Message Tag
for each part would be quite verbose, which eats into the space available for the actual data. The
values of our tags end up being self-describing through very efficient headers inside the CBOR
serialization, so it's tempting to only use a +kiwi/olm tag for everything instead.

The self-describing serialized values are necessary for part of the protocol due to the end-to-end
encryption itself: some of the protocol messages need to be encapsulated inside encrypted blobs, and
we might as well not leak metadata about the nature of the encrypted payload.

But I stuck with multiple separate Message Tags in an attempt to mesh with the human-readable style
of the IRC protocol to the extent it was possible.

Spinning this off from #45 because it seems to have enough traction on its own, and I don't want it to drown out the conversation about orthogonal initiatives.

Current state of the proposal: a new isupport token named TLSMODES, taking a value of the form a,b,c, where:

1. If present, a is a user mode. If this mode is set, the server MUST NOT relay private messages between the affected user and any user who does not have TLS, in either direction.
2. If present, b is a channel mode. If this mode is set, the server MUST NOT allow users who do not have TLS to join the channel.
3. If present, c is a channel mode. If this mode is set, mode b MUST also be set, and moreover all users currently in the channel MUST be using TLS.

"TLS" is construed not to refer narrowly to the TLS protocol, but any case where the transport provides integrity and confidentiality, such as loopback, Tor, a VPN link, or a trusted LAN.

Example values: TLSMODES=Z,z,Z for Unreal, TLSMODES=z,z,z for Inspircd, TLSMODES=,S, for Freenode, and TLSMODES=z,z,z for Oragono (ergochat/ergo#420).

I think it's worth starting to think about providing IRC over QUIC for these reasons:

• Mandatory strong encryption - This basically provides HSTS but for IRC, helping to somewhat solve this: ircv3/ircv3-specifications#300
• In theory provides lower overhead, latency and reduces transfer sizes - 0RTT is also really nice
• Could in theory provide smooth connection migration when an IRC server goes down
• Has a lot of development power behind it from big corporations
• We'll most certainly see Websockets over QUIC(or HTTP/3) so that would be easier to provide when there's an existing QUIC capability in the server

What do you think? Should it maybe even be called IRCv4 :P?

The Web PKI is great because it comes default with everything. Its not so great because it has quite a few known weaknesses. In addition it only works on the public internet. It's pretty useless on TOR(yes, I know you can get a .onion signed), I2P, VPNs, and LANs

idea:

Optional spec for clients to add certificates per server at config time. This solves the use case of a private server on a private network such as a VPN or LAN.

As mentioned in ircv3/ircv3-specifications#302

I've started experimenting with a tag for attaching richer data to a message, similar to https://api.slack.com/docs/message-attachments

It's basically a JSON blob with fields like this:

{
    "from_url": "http://ircv3.net",
    "service_icon": "http://ircv3.net/apple-touch-icon.png",
    "service_name": "ircv3.net",
    "text": "Welcome to the IRCv3 Working Group. We're a group of IRC client and server software authors working to improve the IRC protocol.",
    "title": "Welcome - IRCv3",
    "title_link": "http://ircv3.net"
}

@+draft/attachments=[{"title_link":"http://ircv3.net","title":"Welcome\s-\sIRCv3","text":"Welcome\sto\sthe\sIRCv3\sWorking\sGroup.\sWe're\sa\sgroup\sof\sIRC\sclient\sand\sserver\ssoftware\sauthors\sworking\sto\simprove\sthe\sIRC\sprotocol.","service_name":"ircv3.net","service_icon":"http://ircv3.net/apple-touch-icon.png","from_url":"http://ircv3.net"}] :[email protected] PRIVMSG #test :check out this cool website http://ircv3.net/

Rendering might look like this:

Many of the fields in slack's version are pretty generic, here's the subset I've been using:

author_icon
author_link
author_name
author_subname
author_url
color
fields
file_url
footer
footer_icon
from_url
image_bytes
image_height
image_url
image_width
pretext
pretext_emoji
service_icon
service_name
service_url
snippet_bytes
snippet_filename
snippet_lines
snippet_preview
snippet_preview_lines
snippet_raw
snippet_type
text
text_emoji
thumb_height
thumb_url
thumb_width
title
title_link
ts

Maybe I've missed it, but there is a bunch of stuff that is not really specific in IRC, and seems to depend on the implementation of client/server.

What should happen if a NUL (0x00) is received within a message?
Should spaces be trimmed from the beginning of a message (presumably, yes)
What nickname should be used before a client/server is registered (ie. a client connects and issues an Unknown Command, in the reply raw, which name should be used)

I'm sure there are others... It would be great to weed these out.

Surprised this hasn't been brought up yet. It would be a logical extension of CHATHISTORY from all I can tell. This is critical particularly to networks meant for intra-organization communication, where it may be important to reference a previous decision, explanation, etc.

I think there should be a standardised way (e.g. a numeric) for a server to inform a client that they are using a nickname/account that requires authentication, e.g. in the scenario of...

:NickServ!NickServ@services. NOTICE jesopo :This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify .

There should be a parsable standardised way to communicate this (in addition to the NOTICE) so that clients can e.g. give a popup to the user to request credentials (like HTTP Authentication popups)

Something that I brought up probably forever ago was the idea that clients should provide a consistent user experience. However, that isn't typically up for the protocol to decide, so I thought some kind of non-normative section with guidelines on how to improve user experience could be helpful. Things such as "happy eyeballs" (checking both IPv4 and IPv6 connectivity), checking port 6697 for TLS automatically, and other things that might not directly be on the protocol level - such as #16 (considerations for loading images).

Ninja-edit: Sorry, pressed enter instead of tab, editing comment now

At the minute labeled-response requires an empty batch if a response is not otherwise generated to a command. This is quite verbose, and a little confusing to understand.

If a client labels all outgoing commands, then the usual PING/PONG exchange turns into:

server: PING 12345
client: @label=abcdefg PONG 12345
server: @label=abcdefg :irc.example.com BATCH +NMzYSq45x labeled-response
server: :irc.example.com BATCH -NMzYSq45x

And similarly PRIVMSGs when the echo-message cap isn't negotiated:

client: @label=abcdefg PRIVMSG #ircv3 :Hi
server: @label=abcdefg :irc.example.com BATCH +NMzYSq45x labeled-response
server: :irc.example.com BATCH -NMzYSq45x

Having an ACK message (or something else along those likes - such as a NOOP message) makes this a lot simplier, more readable, feels more semantic, and saves clients having to track otherwise pointless batches:

server: PING 12345
client: @label=abcdefg PONG 12345
server: @label=abcdefg :irc.example.com ACK

or:

client: @label=abcdefg PRIVMSG #ircv3 :Hi
server: @label=abcdefg :irc.example.com ACK

Making this issue primarily to collect ideas.

KiwiIRC and Snoonet are currently in-the-wild showing typing status and I saw some backlash over it. Probably best we discuss the potentially unforeseen impact of this spec, what we think about it, what we think (if anything) could/should be done about it, etc.

This is something that's been in the works for a fairly decent while now, and has been pretty consistently recommended as something we should work on. This issue's mostly a note that "yea this is being worked on".

For prior art on the stuff currently being worked on, here's a few links:
https://gist.github.com/prawnsalad/d864822d9bb8116626a4370bee6e6fc6
https://www.irccloud.com/pastebin/IMi5OozE/
https://github.com/goshuirc/bnc/blob/master/lib/components/bouncer/bouncer.go

The ability to specify an account instead of a nickname would be convenient. For example, !bar would refer to anyone authenticated as bar - PRIVMSG !bar :Hello! would be delivered to everyone logged into the bar account.

This would be useful for things like opping a particular authenticated user or sending private messages that are guaranteed to be delivered only to someone logged into the right account.

A server could advertise support for this via an ISUPPORT token.

I think it would be great if it were possible to drive typical IRC usage fully through a GUI, rather than being required to use text commands in many cases.

Many things work great currently, the main blockers I can think of are:

• Modes
• User registration
• Channel management with services

Having a full fledged GUI for configuring user/channel settings would require at a minimum being able to enumerate all the configurables for a given target, and some server provided descriptions to display alongside them.

Other things like describing the type (text, on/off, a number, etc) and categorisation would allow an IRC clients to drastically improve their ease of use.

Are there any solutions in the pipeline that cover this? And have I missed any other blockers?

On IRC there are multiple things that someone might want to log into. Due to security needs it is not always desirable to use the same credentials for all of these things so separate logins are required.

I propose that this is fixed by adding an optional context parameter to the initial AUTHENTICATE message like so:

initial-authenticate = "AUTHENTICATE" SP mechanism [ SP context ] CRLF

Two new contexts in which this would be useful:

1. server -- logging in to the server as an alternative to PASS.
2. operator -- logging into operator accounts (which are separate from services accounts) as an alternative to OPER.

If no context parameter is provided we can default it to account which would be the existing SASL behaviour. This would preserve existing behaviour for legacy implementations because as far as I know existing implementations extraneous parameters to the AUTHENTICATE command just like with CAP (which allowed us to enable cap-3.2 with a value of 302).

Following on from discussion here: ircv3/ircv3-specifications#289 (comment)

Services like Slack and Twitch have custom emoji that go beyond the unicode standard. It would be good if IRC messages and reactions could support this too.

For reactions we could retain the plain text +react tag to serve as a fallback or tooltip/alt text value, but send a separate URL in a +react-image tag that clients can optionally display if they want to.

@+reply=123;+react=:lol:;+react-image=https://example.com/custom-emoji/lol.png :[email protected] TAGMSG #channel

For custom emoji in messages, we could send text replacement offsets, similar to twitch's custom "emotes" tag (https://dev.twitch.tv/docs/irc/tags/#privmsg-tags)

Using an +emoji client tag with JSON, it might look something like:

@+emoji=[{"url":"https://example.com/custom-emoji/lol.png","idx":[[0,5]]}] :[email protected] PRIVMSG #channel ::lol:

Plain text clients would just show a message :lol:, supporting clients would replace the text starting at index 0 with length 5 with the defined image.

I have working implementations of both of these in an unreleased project (suitably prefixed with draft/. Posting this here as a placeholder and for comments before I write up proper specs.

With Slack and such, you can drag an image into your client and it'll upload to Slack for everyone else to see.

Similar functionality would be nice to have for IRC clients that wish to use it. Here are some proposed ideas:

• IRCd provides the client with an endpoint to upload images and such to. This may also be extendable to other types of files if we're already implementing it this way, and seems like the best way to go about this in my eyes. Essentially, allowing similar interactions to the way IRCCloud does it.
• Providing them directly in-line, encoded. This won't fly, since message lengths and having to send 100 messages to get an image across.
• Providing them directly to clients in some sort of a dcc-like system. Interesting theoretically, but a massive pain to actually implement and I can see it being fraught with issues so I think this idea is best binned.

@dequis posted this, and it's essentially along the lines of what I was thinking for the best way to approach it:

Using an external protocol complicates stuff.. new ports to open (NAT/firewall issues) sync with another service/process supplying that protocol.

If this is your main concern, there are two ports that are available practically everywhere: 80 and 443.

My idea of an out of band implementation of upload would be the ircd providing a http(s) url, optionally with user/session/channel specific GET parameters (for any required rate limiting), which can be accessed directly by the user (showing an html page) or can be POSTed directly by the irc client with multipart/form-data with predefined field names, and returns the result in an easily parseable format - which, if no extra information is needed, may be just a 302 Found redirect with the image URL in the Location header and the plaintext body.

This came to mind because of ircv3/ircv3-specifications#208 - there's suggestions about using client->server BATCHes to send multi line messages and that made me realise that, even if we don't use a BATCH for multi line messages, we're probably going to need client->server BATCHes at some point.

Should we spec this out? Should this go in the batch spec? What are some examples of when a client would send a BATCH, other than a multi line message?

IRC is commonly still used in plaintext over the public Internet. This is extremely bad --- in my opinion, one of the most severe and pressing issues facing the platform --- and we should be trying to change it. Some ideas:

1. Legacy clients (and servers) can use external TLS termination proxies, in particular stunnel which is cross-platform FOSS. How adequate is this as a solution? Should we write documentation/guides that cover this?
2. What are the prospects for lobbying existing networks to disable plaintext access?
3. Can standardizing the ircs:// URI format, as in #8, provide an effective way to communicate to clients that they should exclusively use TLS for connections?
4. What is the proper role of STS in this initiative? (Given the currently poor levels of client support, I'm relatively bearish on STS.)

Currently configuring a channel as a user is not the easiest experience:

• Different ircds have different commands to display the help for modes, sometimes they conflict with the client /help command
• Mode lines are hard to disambiguate by eye
• There are varying implementations of services

It would be nice to have a mechanism to allow clients to display a window/buffer that has all the configuration in one place without requiring networks to standardise around a specific configuration layout.

An OPTIONS command could fulfil this role, the reply could contain enough information to build either a full settings GUI, drive command autocomplete or something in-between.

A minimum implementation may have option names paired up with a description and basic type (whether it takes an argument, if it's a list). A more complicated spec could allow things like sections, complicated inputs (like access rules) and more specific field types (radio buttons, checkboxes, etc).

I'd love to hear some thoughts on this, it seems there's a pretty wide scope it could sit in

Other specs

The key difference to existing proposals is that OPTIONS are effectively opaque to the client, they should only be used to create some form of display for the user.

Metadata

Metadata keys should be specified and listed in the registry, it's useful for things the client itself needs to access like avatars. In contrast the keys for OPTIONS are intentionally not specified, the client should not attempt to interpret their values beyond displaying it to the user.

Named Modes

Named modes covers a part of the goal, provided the names are reasonably consistent the client can use them to display help messages and the like. Uncommon modes might not be covered by the client however, whereas with OPTIONS the help text is included in the reply.

Another major difference is that OPTIONS can expose configuration beyond modes, such as services integration.

An example

To illustrate the general idea, here's a concrete scenario of OPTIONS in use, the syntax is for illustrative purposes only and may not be the best but bear with it.

Here the client requests the options list for the #ircv3 channel, additionally znc inserts its own settings into the reply

--> OPTIONS #ircv3 LIST
BATCH +outer options #ircv3 list
@batch=outer BATCH +section1 options #ircv3 section :Channel Modes
@batch=section1 OPTIONS #ircv3 LIST mode_n type=boolean value=true title=No\sExternal\sMessages :Only channel members may talk in the channel.
@batch=section1 OPTIONS #ircv3 LIST mode_L type=boolean value=false title=Free\sTarget :Anyone may be forwarded to the channel.
@batch=outer BATCH -section1
@batch=outer BATCH +section2 options #ircv3 section :Chanserv
@batch=section2 OPTIONS #ircv3 LIST chanserv_entry_msg type=text title=Entry\nMessage :A message sent to all users joining the channel.
@batch=outer BATCH -section2
@batch=outer BATCH +section3 options #ircv3 section :ZNC
@batch=section3 OPTIONS #ircv3 LIST znc/buffersize type=number value=50 title=Buffer\sSize :The buffer count.
@batch=outer BATCH -section3
BATCH -outer

The main reply of interest is roughly OPTIONS <target> LIST <key> [<param> [<param> ...]] <description> where params are keys with optional values using tag encoding

Here a key such as mode_n would be used only to inform the server of changes made by the user, the keys are opaque and would not required to be standardised across implementations.

The title param and description are for displaying to the user, as an example they may vary within a single server depending on the language of a user.

The type param is standardised and would be a hint to clients if they wish to choose a particular input field, numeric input uses a different soft keyboard on touchscreen devices for example. value is the current state of an option.

Nested batches are used to split the options into categories/sections.

Putting this all together, the client can display a screen like

I spent way too long formatting this bit

Alternatives

Rather than a new command, this could be built on top of the metadata spec, it would need a few additions:

• Allowing extra keys that are not specified or part of a registry

  Aribtrary keys could be allowed as long as they follow a scheme such as vendor prefixing to prevent collisions in the future

• Attaching types, human readable names, descriptions and other such items to said keys

  A new subcommand could be added, such as METADATA DESCRIBE that functions similarly to the ideas described above

• Tying in modes somehow

Edit: to keep this updated a bit with the discussion, my initial cap-099-draft has been somewhat superseded by various suggestions, so let me put here what the discussion below yielded:

Updated suggestion

There is a de-facto start sequence as best described by @DanielOaks here: #3 (comment)

I think this sequence should be put into writing as part of IRCv3 (but not necessarily associated with any new CAP), and numerics 002-004 (specified in RFC2812 which currently isn't considered part of IRCv3, while RFC1459 is) as well as numeric 005 (RPL_ISUPPORT, which isn't currently officially standardized at all) should be put down as official standardized part of IRCv3 as well - including a mention that RPL_BOUNCE is officially no longer used and RPL_ISUPPORT replaces it with no exceptions.

More elaborate solutions aren't really required because this is already de-facto standard and pretty much nobody violates it, so all it would do is give a much-needed spec to actually rely on instead of hoping that all server devs will indeed stick to the de-facto in the future (why this is a problem and what happens if they don't is described in the discussion below).

Original suggestion:

I'm suggesting a draft for a new capability. I attached the full specification draft as text to the ideas repo since there is currently no implementation of it. First, let me explain what this is about though:

Situation

Currently, valid IRC servers can do one of the following:

• Send 001 only as in basic RFC1459
• Send 001-004 only (no RPL_ISUPPORT), and at least twitch appears to do that in practice
• Send 001-005

Also, RFC1459 specifies that a MOTD may be sent, and offers an error message if there is no MOTD - but it doesn't seem to require that either a MOTD or a MOTD error is sent.

Resulting problem

Therefore, a fully compliant IRC client which wants to support legacy servers will need to do some timed wait for numerics 004 and 005 or assume that there will always be a proper MOTD notification. This seems a bit brittle, also because timed wait can lead to random failures to recognize 004/005 on modern servers due to connection slowdowns and similar.

Proposed solution

Therefore, I'm proposing a new mechanism offered by new servers to indicate that they're not legacy servers, which allows a client to have an expected "end of startup" point to wait for safely. Any modern server announcing this can then be sure that any client who supports this mechanism will parse all its startup numerics even when a shaky connection is involved and the client wants to keep timing heuristics for legacy server support.

draft-testing-cap-099.txt

Some specifications are more aimed at private networks than existing public and popular ones, indicating the target audience in the specification would help provide a little bit more context.

Normalizing this process would help.

A popular feature in public web based chat services and requested fairly often in kiwiirc, is the ability for visitors to see whats happening in a channel before actually joining it. Example, opening a twitch or youtube stream while not logged in. The client would then have the option to actually /join (or connect to the network in some cases...) it if the user wants.

Currently on kiwiirc people have bots in their channel that pipes all the content elsewhere, and then modifies kiwi to connect to the external service to collect messages. They typically have these read only interfaces on their website with a button "Connect now to talk!" before they can actually send a message.

This type of integration increases the number of users getting involved as it removes a barrier to see into a community.

I could see 2 versions of this though theres probably better suited methods an actual IRCd dev could think of.

1. A client connects to the network as normal as a complete client, then taps into the read only mode channel.
2. A client connects to the network but does not do a complete registration. As a full user instance is not required this could save resources on popular channels. The client would then be required to actually register as an ordinary full connection to join.

Would this be of any interest to IRCd devs?

There should be something normalized for providers (irccloud, bouncer providers, etc.) to determine an user is no longer welcome on the network (gline, kline, whatever) so that it can be gracefully handled and the administrators can log or deny access to reconnection to that network of sorts.

I'd like to propose using a message-tag on a PRIVMSG to denote a message with a content warning.

I suggest this works by the PRIVMSG message being ROT13-encoded for backwards compatibility and the message-tag be something like @warning-title=<warning>.

GUI clients could e.g. show a "show" button next to the title which, when pressed, would ROT13-decode the content of the message and show it to the user.

Here are some thoughts in no particular order from today's IRC discussion:

• Currently charset/encoding support is a mess on IRC because it was never defined, and clients do not communicate which charsets they use (which lead to hacks like casemappings)
• Some IRCv3 caps will want to use unicode (reactions, display names, etc)
• Mixing UTF-8 for tags only, and other encoding for the message itself is not a particularly good idea
• Legacy encodings (but not all of them) include the base ASCII set (<128 bytes), which makes UTF-8 backwards compatible here
• It is impossible to detect used encoding without knowing which one exactly was used
• If UTF-8 is enforced, it is impossible to make it fully backwards compatible with all legacy encodings (thus leading to question marks when decoding)
• If servers start storing messages for chathistory backlog and message searching, they will want to use a proper encoding there as well

I am most likely missing more points, but that's what I currently remembered from top of my head.

The current situation is pretty sad, in the way that a lot of clients try to decode UTF-8 and if it fails, they fallback to one of the common encodings (like latin1), which still leads to messy results. Enforcing (or at least strongly suggesting) use of unicode will increase interoperability and compatibility between all kinds of IRC software.

Legacy charsets are not compatible with one another, and are super limited. A glaring example of this is emojis. If a client wants to correctly send and display them, it needs to deal with unicode correctly.

Currently we have very similar formatting in multiple places but each differ slightly (or currently being discussed):

• ISUPPORT tokens
• CAP
• Message tags
• WEBIRC extended info
• Metadata

We could do with picking and sticking to a format for any future key/val related structures for consistency. I bring this up now since the topic has arisen for the WEBIRC extended info format and being discussed for metadata.

Message tag format

• Full characters support including spaces with escaping
• Fits into a single IRC argument if required
• Requires escaping

ISUPPORT tokens

• Simpler to use
• Does not support spaces in values
• Cannot be used in a single IRC argument

Why is this important?

Having multiple ways to do the same thing causes confusion and extra bloat in our software. Consistency in a protocol is also important for implementors to stay sane. And I enjoy my sanity at times.

Personally I'm in favour of the existing message tag format being used as the standard key/val formatting, simply because it is the more flexible format and supports spaces that may be required. While some things may not need support for spaces and other characters, consistency is still an important factor and we don't want to be locking things in such a way that it can't be extended in future.

Thoughts?

Similar to other chat services (Slack, Discord, etc...), a way to edit sent messages would be helpful to users who wish to correct a mistake. A single command to edit or delete the message could be sent. This command would only apply to PRIVMSG and NOTICE.

@label=ID DELMSG
@label=ID EDITMSG :new message content

This would provide no server-side history of message "versions", although clients may elect to do so themselves.

The biggest issue faced is security, in which the server must ensure that users can edit only their own messages. This is therefore intended most for services such as IRCCloud and similar that store messages linked to a specific user. There is also no ability to force deletion or edits logs and client support is optional.

WEBIRC is currently the only method to pass a users connection info to the IRCd when using some type of gateway service. For smaller setups this works well once setup, but for larger setups it starts to fall short.

Since running the Kiwi IRC webirc gateway for several years to support thousands of active networks and supporting hundreds of others to configure their own webirc gateways, these are the main issues that come up regularly:

• Configuration causes confusion and difficulties for a lot of admins.
• Whitelisting specific webirc gateways causes headaches as the gateway service scales or needs to change IP addresses.
• Networks still use identd lookups to a webirc gateway, which is pointless and slows down the connection from completing registration.
• Inconsistent results when using an incorrect webirc configuration.

It would be beneficial to discuss how we can improve this since the number of web client usage increases.

To kick start a discussion:

(For reference, the current WEBIRC implementation: WEBIRC password gateway hostname ip)

Idea 1

• Use client cert auth to auth a webirc gateway instead of passwords. Most IRCds have cert auth code already so this should be trivial to implement. A good side effect of forcing TLS connections.
• Keep the current WEBIRC command structure but pass * for the gateway password since it is no longer needed.
• No longer whitelist specific webirc gateways
• Force a consistent ERROR message and disconnection on invalid webirc configurations

Idea 2

• Replace the current static password in the WEBIRC command with a form of one time password.
• Use the gateway service name in the WEBIRC command to lookup any required secrets in the IRCd config.
• No longer whitelist specific webirc gateways
• Force a consistent ERROR message and disconnection on invalid webirc configurations

Let me flog a dead horse, and note some of the interesting things that MSN Chat had that I believe IRCv3 could benefit from (or could at least be a discussion point)...
Some of these may be implemented already, and I'm not aware of them. If this is the case, sorry. I'm not suggesting that these be implemented exactly as per IRCX/MSN, just that they are very useful and worth discussion.

MSN Chat was based upon the IRCX Draft. It's important to note that the IRCX Draft was not updated since June 1998, and MSN Chat kept pushing forward with updates in a proprietary manner. I think understanding how MSN Chat had pushed forward may help us see a way forward with IRCv3.

❌ACCESS command
IRCX (Section 5.1) supports adding ACCESS entries.
eg /access John ADD DENY *!*@* would disable anyone from contacting John
Additionally, it could be used to add access to channels in the form DENY, GRANT, VOICE, HOST, OWNER. ACCESS could bypass keys (for positive access)
Adding DENY access to a channel worked identically to CHMODE +b, with the exception that a reason could be added.

✅ AUTH command
The AUTH command is well defined in the IRCX draft, although it is not opinionated on which SASL authentication methods could be used. IRCv3 has implemented a suitable alternative.

✅AWAY command
The IRCv3.1 Away-Notif spec offers a somewhat suitable alternative to what MSN did.
Limitations: Away-Notify offers no way of being able to differentiate between if a user joined the channel and was already away, and if the user joins the channel, then uses the AWAY command. It also offers no notification when joining a channel of who is away, and the draft suggests using the /who command to get this information. I'm not sure why it wasn't suggested that the server automatically send a WHO reply on behalf of the client when joining a channel and had Away-Notify set active.
MSN used an extended JOIN / NAMES (see below, which was able to show this information, as well as others)

❌REDIRECT message
While it may seem limited, this is an amazing command for an IRC Admin. It's very useful for load balancing (and moving geographic users to their closest server). Additionally, it is very useful when a server is taken offline for maintenance.

❌ONJOIN (privmsg) / ONPART (notice) messages
When a user JOINS or PARTs a channel, they would receive a message from the channel if an onjoin/onpart message was set. This was set using the PROP command. Notably, messages could be split when set by escaping using \n.
ie. Channel operator setting ONJOIN message
PROP %#Channel ONJOIN :Welcome to our channel\nI hope you enjoy your stay
User receiving ONJOIN message
:%#Channel PRIVMSG %#Channel :Welcome to our channel
:%#Channel PRIVMSG %#Channel :I hope you enjoy your stay

❌Standard escaping
The IRCX draft notes a standard escaping sequence, although it should be noted that \0 was used to represent NUL in later revisions, so that the AUTH command could use all 256 bytes.

              \b            " " (blank)
              \c            ","
              \\            "\"
              \r            CR
              \n            LF
              \t            TAB

IRCv3 has worked around this with various methods, such as using base64 encoding (>25% extra data), as well as using other escaping methods such as the one defined in IRCv3 Message Tags. I believe it would be beneficial to create a standard escaping sequence that MUST be used where practical.
eg. Both message tags, as well as authentication could have used the same table above (including \0).

❌Extended channel keys
As well as a normal channel key, it was possible to specify an OWNERKEY or HOSTKEY, which would not only allow the user to join the channel, but to receive a specific mode (+o/+q) in this case. These were set using the IRCX PROP command. eg. PROP %#Test OWNERKEY :ThisIsThePassword. Setting a key to '' (null) would render it unusable.

❌Self reference
IRCX defines the dollar symbol ($) as a server prefix. ie $irc.example.com, but when it is used by itself rather than a prefix, it specifies the current client/server. This allows you to send commands without knowing your nickname.
eg. On connect, where a nickname is often forcibly changed by a server, you need to establish that nickname before you can set a MODE. By using $, it does not matter which nickname you use. MODE $ +i would allow you to set invisible mode on yourself.

❓Longer/Unicode nicknames and channel names
Although there was some suggestion in the IRCX draft, this was later changed to assume universal support by clients. As far as I'm aware, most/all clients will support this automatically, and did pre-year 2000.

❌Extended JOIN/NAMES reply
When sending a JOIN message, MSN Chat would specify the status of the user.
:Nick!User@Host JOIN H,U,RXB %#Test. The same prefix was also used on NAMES replies eg H,U,RXB,@Nickname, which interestingly, would be compatible with both IRCv3.1 Multi-Prefix and IRCv3.2 Userhost-In-Names
The format for H,U,RXB was as follows:

• Here | Gone (Away Status)
• User | Guide | Sysop | Admin (Guide/Sysop/Admin were all different levels of IRC operator)
• Male | Gender Neutral/Not Specified (P) | Female | No Profile (R)
• Has Picture (Y) | No Picture (X)
• Subscriber (B) | Non Subscriber (O)

The gender and picture fields would be set to a singular G if the user was a Guest

It would be nice to have an IGNORE command within the IRC protocol, to block messages from specified nicks. This way the clientside ignoring commands would become unnecessary. Also it would make things easier for people who often work from different clients.

I would suggest a command like:
/ignore nick(!user)?(@host)?
user and host are optional and wildcard use should be possible (similar to the ban command)

This came out of a discussion about ircv3/ircv3-specifications#306...

There should be a command to ask the server to allow the client to disconnect but hold the session open (e.g. don't send QUITs to other clients) to allow for a short period of time that the client can reconnect, have the state replayed (with a playback of missed data?) and carry on as it was. This would be very useful for e.g. restarting clients/bots for software upgrades without spamming other users with QUITs/JOINs.

I suggest the command used to request this be called BRB (Be Right Back)

A request which can be send to another user:

/clearreq <user> <#channel> <description>

In <user>s client a window will be opend: *** wants that you clear your chat history in <#channel> because <description>.

Additionaly a system to only allow requests from specified client or to not allow requests from specified client.

It would be nice if there was a way for clients to communicate to other clients that a message has been read/seen. This has two use-cases:

1. In a bouncer setup with multiple clients per user, it can be used to sync the scrollback marker/unread count between the user's clients.
2. It can be used to (optionally) inform other users that a message has been read/seen, similar to how Facebook Messenger conversations work. This use-case would typically be configurable on the client, to let the user decide whether or not to send these notifications, possibly only to a subset of users (known contacts), and in response to which action, eg. focusing the buffer of the conversation.

Prior art for the first use-case is e.g. Slack's im_marked notification, and for the second use-case, Facebook Messenger's message_reads callback.

Both protocols use a simple timestamp to signify the read-cursor/watermark.

A prototype of the first use-case has been implemented as the znc.in/message-seen capability, available as a ZNC module, with support in the Communi desktop client.

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://

Simple premise - imagine a bot that greets users via NOTICE when they join a channel. This is currently often done by NOTICE user :[#channel] hello! but I think we could do something a lot better than that.

My proposition: @+channel-context=#channel NOTICE user :[#channel] hello! - it'd be backwards compatible and be a lot more concretely related to a channel.

Inline formatting, as it stands, has a number of downsides. Some include:

• Clients that don't wish to display any formatting still have to support it, and strip it out manually
• Usage is 'documented' here but there is no formal spec and client implementations seem to vary a lot
• Only 16 colours are supported

I'm skeptical of inline formatting tools such as markdown, because clients have to understand them completely to be able to strip it. Users should also be able to type things like *statement* without it getting formatted, and adding an escaping burden to existing methods of expression feels odd.

I see an implementation as naturally being similar to "custom emoji" - a @formatting tag with a json array of formatting types and replacement indices and lengths, something like: @formatting=[{"type":"bold","idx":[[7,5]]}] which would produce "hello, world!".

We'd likely want types to include (as an idea, not limited to):

• Colour
• Italics
• Bold
• Underline
• Strikethrough

I'd like to start a conversation on getting some more formal client-to-client formatting tags specced up, and potentially seek a working group member to sponsor it. Also interested in people's considerations and concerns.

So, spoilered text is a thing that's really, really damn common out there. Every forum supports it, Reddit supports it, Mastedon supports it, and even Discord supports it. There's also been a defacto way of doing spoilers in IRC – just having the bg and fg colours be the same – that's been picked up in Textual as show-on-hover.

This issue discusses whether there's a better way to mark spoilered text that fulfils typical requirements of spoilered content:

• Content should be hidden unless the user explicitly opts to see them (such as clicking a button, hovering, or enabling some 'always show spoilers' feature in their client).
• Users should be able to perform some action to see the spoilered content.
• Should work in channels that block colours, since channels like that are somewhat common.
• Hopefully allows clients to show some rich representation of it. For example, instead of just showing the entire line blacked-out, replacing that with an explicit show/hide button as some forums handled it back in the day.
• Should work on existing servers (those that don't support c2c tags, etc), and those that do support c2c tags and the like.

Spoilered text is and has been very common in all sorts of text systems, so I don't think there's much of a case to be made that we can't discuss possible ways to support this more effectively.

Same Fg/Bg Colours

So this is one of the ways it's done currently. Basically, you set a block of text to have the same bg and fg colours (14 - dark grey is used for this, because clients sometimes modify or ignore the 00/01 colours, and because like half of IRC has a pure white bg and half has pure black, so it's real easy to miss text that is coloured in this way).

Upsides:

• No external utilities or similar to view it, simply highlighting the text is enough to show it.
• Works on existing servers.

Downsides:

• Does not work in channels that block colours.

Rot13 Text Substitution

This is another way that people represent spoilered content today. They manually change the text using a rot13 rotation utility, post it in the channel, and then receiving users need to do the same.

Upsides:

• Not visible to other users in the channel, no matter whether the chan blocks colours or not.
• Works on existing servers.

Downsides:

• Does not support text outside regular latin characters, so unicode goes through entirely as-is.
• Requires that users know that the text is rot13, and requires them to perform the conversion themselves.

So, those are the only two methods that currently exist to do this. Are there any new ones people can think of that do fulfill the above requirements whether the receiver does or does not support the method, and would be not-too-difficult for client authors to implement?

Some previous discussion of interest on #32

While ircv3/ircv3-specifications#297 already mentions this; I'd like to just expand a bit further.

IRCv3 could benefit from a generic list of constants that can be referred to in a specification, specifically when it comes down to commonly used things like escaping values, and defining what <vendor> may be.

It'll be up for debate whether these specifications should be written as a full-on jekyll importable/includable, or whether we should use something like The RFC2119 header as a 'This document uses the key word vendor as described in https://ircv3.net/definitions/vendor'.

Care should be taken so that it does not detract reading experience, nor should it be so dynamically imported that it might be possible to forget adding an Errata to the specifications that utilise it.

Allow channels to pin a message to give it more prominence.

This is how Discord implements it UI-wise.

Some ideas on things which need to be decided on:

• How it should be implemented
  • C2C tags
  • A C2S/S2C command
  • Something else
• Whether pinned messages should be in a chathistory batch or their own special batch type
• Whether to allow in PMs (Discord allows this but i'm not really sure how useful it is)

Is it considered to implement something like offline notifications ? upon connect, the client would ask the server if anyone mentioned him before.

Use cases:

• user was away / disconnected and wants to know who pinged him
• user has two devices connected. One in online and unreachable by the user at a given point in time, the second just connected, the client wants to know who pinged him, possibly using the nickname of the first client which might be different.

Simple enough concept. I think we should standardise a way to mark a "user" as a bot.

I've found 4 IRCds within the IRCv3 support tables that offer this as a +B usermode.

• UnrealIRCd (usermodes/bot module)
• InspIRCd (botmode module)
• ChatIRCd
• Nefarious

I'm not sure if trying to standardise around this umode is a good idea - umodes are dwindling and we can't just assume that all servers support +B as "I am a bot".

From @jwheare via IRC...

<@jwheare> re bot denotation, I’m using a bot-url metadata key for that in our slack gateway
<@jwheare>  With the assumption that all bots have urls

I, personally, would be very pleased with standardisation of bot denotation through metadata.

Currently, any one can change what each color code refers to (in terms of colors). I suggest making a standard similar to CSS colors. This would help with applications where you send colors and they render differently depending on the client and the client theme and user preferences

So, ircv3/ircv3-specifications#276 does the job of introducing a way to basically expose NickServ methods natively (allowing clients to build pretty interfaces for them). This issue is about doing the same thing for ChanServ and channel management more generally.

My plan is:

1. Get #276 accepted, or at least get other implementers on-board with it so we know the API is stable and relatively well-received.
2. Introduce a channel management PR that's... basically the same thing, using an extremely similar API and command/subcommand set, but aimed at registering channels instead.

Pretty simple. I won't introduce a channel management PR before the account management one goes ahead, because... plain and simple, I don't want to bother keeping two separate PRs in-sync in terms of the API they expose, and also don't want to run into the situation where one gets standardised in one state and the other gets standardised in a slightly different state.

Was thinking about internationalization and nicknames, and thought about a possible scheme to implement nickname internationalization in a way that does not break clients or servers, nor does it
invite abuse.

Internationalized nicknames could be represented in ASCII using a variation on Punycode (which is used for internationalization of domain names).

The ASCII representation would be used for all IRC commands, and it would be recommended for clients to show and accept both the "proper" UTF-8 representation and the ASCII representation.

Thoughts?