Extensible formatting syntax

[emersion]

Up until now IRC formatting hasn't been extensible: adding a new formatting code will break existing clients, because existing clients will not be able to understand how to strip the unknown formatting codes in the message. This is a proposal for an extensible, backwards-compatible formatting code.

Use-cases include custom emoji, attachments, links, and so on.

A new formatting code 0x10 is introduced. A new extended-formatting cap can be negotiated by the client. If enabled, the server can pass through 0x10 codes. Otherwise, the server strips 0x10 codes. The 0x10 code is defined with a format name, key-value pairs, and a text. The text can always be used as a fallback. That is, if the format name is unknown, the whole 0x10 can be striped and replaced with the fallback text.

0x10 <name> " " <key-values> ";" <text> 0x10

Example, with F for 0x10:

PRIVMSG #ircv3 hi Fcustom-emoji;:gopher:F

On clients not supporting extended-formatting, the server would strip the formatting and send hi :gopher:. On clients supporting extended-formatting but not the custom-emoji format, the server would send the message as-is but the client would use the text as a fallback and display it as-is. On clients supporting extended-formatting and the custom-emoji format, the client would display the custom emoji.

[progval]

This could rapidly cause messages to be too long for 512-bytes lines. Such a spec could/should make require that only the length of the fallback counts toward the 512-bytes limit. With a new limit -- or way for servers to signal a new limit -- on the total length of the message, of course.

[SadieCat]

Wouldn't this be better as client tags?

[emersion]

This could rapidly cause messages to be too long for 512-bytes lines

For some formatting tags, it could indeed grow the message size quite a bit. I think it would be reasonable to make the cap bump the max message (with the regular size limit still being enforced on the fallback strings).

Alternatively, it would be possible to use multiline to join parts of long messages, but not sure it's a good idea to lean on that extension.

Wouldn't this be better as client tags?

Client tags have a few issues:

• They are awkward to use to represent formatting: we'd need to use byte ranges indexing into the original message contents.
• The server might mutate message contents arbitrarily (e.g. to strip formatting, or to replace a string with another, etc). The client tag would be broken in that case.

[ValwareIRC]

@+custom-emoji=gopher;+custom-emoji=cat PRIVMSG target :oh hi %e I thought you were a %e

[SadieCat]

AFAIK the way Signal handles it is that stickers are associated with Emoji and then the sticker is pulled out of metadata for newer clients that support it.

[ArmanHayots]

I think that subset from Markdown will fit better. Bold, italic, underline, strike-through and code seems to be enough.

[SadieCat]

I think that subset from Markdown will fit better. Bold, italic, underline, strike-through and code seems to be enough.

IRC already supports these formatting styles. This issue is about adding support for other rich text features that every modern chat protocol supports.