IRCv3 is shaping to be amazingly good!

here's the things it offers, today, right now, on a chat server we just set up in one evening:

  • you don't need a bouncer (friggin finally)
  • there are moblie clients that work well
  • you can see backlog when joining a channel
  • you can browse chat history
  • you can connect from multiple devices with one account and nickname
  • if you disconnect, your nickname is still present in a channel you joined, marked as away
  • you can highlight or DM people who are away and they'll see your message when they join (without crutches like MemoServ)
  • there is a "last read message" marker and it is synchronized between multiple connections
  • messages have identifiers (and server timestamps) and replies can be tagged with the message you're replying to
  • messages can be redacted (for moderation)
  • you don't need to deal with fussy nonsense like NickServ authorization, ghosting, or such; connect with your username and password and that's it
  • there are typing notifiers, if you want them
  • there are message reactions, if you want them

here's the things it does not offer:

caveat: since IRCv3 is a true extension of IRCv2, the features listed above work if they're supported by both the server and the client. in my onboarding experience so far, people do not find it difficult to find a suitable client, but your mileage may vary. on the flipside, legacy clients will work just fine.

unexpectly, i realized that IRCv3 can completely replace Matrix rooms for my own group chat purposes, and i'm probably not going to set up any Matrix homeservers again; it's just not worth it and frankly I should instead put that effort into coming up with a file upload IRCv3 extension or something

Add filehost by emersion · Pull Request #562 · ircv3/ircv3-specifications

This is shipped by soju + gamja + goguma + senpai as a vendored spec, and is based on an earlier draft by @progval.

GitHub
in summary, i feel incredibly validated in being a long-time IRC holdout :D
@whitequark Iä! Iä! IRC fhtagn!

Which network is going to be the first to shift to this, do you speculate?

@whitequark

@futuresprog Libera is rolling out IRCv3 soon, which is going to be big https://libera.chat/news/new-and-upcoming-features-3
New And Upcoming IRCv3 Features

Adding message-tags, batch, msgid, and invite-notify.

Libera Chat

Neat! I'm already there. I guess I'd better update my irssi to take full advantage of the features.

@whitequark

@futuresprog @whitequark yeah i need to find myself an ircv3 capable client I'm still using Pidgin which I started for AIM, MSN, Yahoo, and IRC.

Of those, IRC is the only one still around.

@azonenberg @futuresprog @whitequark I'm still using finch in screen on a linode...

@whitequark @futuresprog they've had "IRCv3 support" since inception AFAIK (I believe even freenode had it)

what they're rolling out is support for some extensions to IRCv3, in particular the `message-tags` specification which will support things like `+draft/reply` by adding a new capability to add a bunch of metadata to a message (which involves bumping the line length up 8191 bytes, allowing for just under 4K of tag data)

IRCv3's capability negotiation is such a powerful way to let the ecosystem continue to grow in a way that allows more granular specifications

@whitequark @futuresprog it doesn't really help matters the IRCv3 working group has just kinda given up on versioning the whole thing and now there's "the modern IRC protocol" at the core and the cloud of extensions

so there's no versioned document you can point at and say IRCv3.x as there was with IRCv3.1 and IRCv3.2, and I'm not sure the smaller granular extension specifications have any versioning either. it all manages to hold together nonetheless, I guess because they don't make breaking changes (because all in the extensions, the core got it very right pretty early, especially if an implementation has the combination of capabilities AND tags)

@SnoopJ @whitequark @futuresprog yeah the whole point of v3 is the capability negotiation mechanism, with everything else being optional and up to the client to choose, so you can't really version it

That’s a more clever way to upgrade a federated system without a huge cutover

@SnoopJ @whitequark

@whitequark
Wow that really sounds great and promising, thanks a lot for sharing this very nice and quite exhaustive summary!
Here I've actually never stopped using IRC (plus its relative simplicity makes it really easy to implement useful status bots).
Note that if we won't really need bouncers anymore, we could still use these for a smooth transition until more networks adopt IRCv3. ZNC for instance implements more and more server and client IRCv3 features
@whitequark /DCC SEND

@mcc You are in queue position 5 of 10 to download CATDANCE.GIF

@whitequark

@mcc I miss those chat based warez servers.
@jonbro @mcc things can still be found in IRC
@jonbro @mcc There are still plenty around. ;)
@whitequark can you still use an irc client that doesnt support ircv3 in a server/channel with ircv3 users?
@whitequark that rules

@artemis yep! it just falls back to the 'classic experience'

you can do things like type /chathistory manually and get old messages retransmitted to you, like it's a bouncer

@whitequark whoaaaaaaaa
@whitequark im very set in my ways with irc and will probably never quit my irssi-in-tmux-on-a-server ways lol
@artemis i quit that for matrix after it became personally unusable for me but yeah that works just fine still
@artemis @whitequark as already explained by the OP: categorically yes. however some things won't show up right; the server isn't supposed to send non-v3 or partial v3 clients things they don't support #lang_en
@artemis @whitequark yes, that's what i do with irssi. my client has virtually no ircv3 support (none of the fun features), but i can still join ircv3 servers (ergo) and chat with ircv3 clients (halloy, etc.).
even if your client doesn't support ircv3, you can still /quote history #channelname and receive chat history! (i prefer to have an irc client that runs 24h/7, but in case of a power cut, that's an option)
@whitequark Not needing a bouncer is sweeeeeeeet

@whitequark
> you don't need a bouncer

WHAT

okay now I'm definitely interested

@groxx yeah it just works the way you'd expect haha
@whitequark Hm. Would the server lose the backlog and the rest of the state if it's restarted, or is it supposed to store it all now?
@whitequark this is awesome! Which daemon are you using?
@kevin ergochat
@whitequark oh, very cool. I wonder if now would be a good time to revive my IRCaudio extension I was working on for Mumble-esque audio channels

@whitequark Intriguing. Any recommendations for compatible servers and clients?

If session persistence is a thing now, that feels like a real step forward for IRC (having to use a bouncer or a client running on a server somewhere is a high bar for a lot of people, especially more casual users).

@whitequark I should look into the spec, maybe make my own client if it's not too complex. Been wanting to do that since forever.


It's nice that IRC is getting the love it finally deserves. I have been waiting for not having to use a bouncer since forever.

@whitequark I’ve found myself thinking of going back to IRC, and this gives me more reasons than I has hoped for!

Ps. I think everybody is finally using Utf-8.. please? 😜

@gimulnautti yes, UTF8ONLY is a feature now

@whitequark

Feels like this should have been news from around 2000.

@whitequark
File uploads could probably be kludged exclusively on the client side with something like
```
START FILE UPLOAD
METADATA <metadata>
BODY <base64 file contents>
END FILE UPLOAD
```
although it would be problematic in that it would show up as spam for anyone without the client extension, and would be less efficient than a binary solution. It could work the same with image, audio, video, and stickers, since those are all just specially tagged files. Could even work for streaming (hence live audio/video calls) if the files are chunked right, maybe adding CONTINUE BELOW and CONTINUED FROM ABOVE indicators.

Of course, that would be stupid, since a 2MB file would take more characters than make up the entire LotR trilogy (~2.3M) under this encoding scheme, all of which would be shown in their raw form to any user with an incompatible client (unless IRC lets users handle this somehow). Maybe there's a reason people leave some things to the server.

I realize I have just given an oversimplified description of how XMPP handles (or maybe handled, depending on implemented XEPs) file uploads.

(please don't interpret this as me trying to fedisplain how you should implement a file upload protocol. don't implement it this way, please.)

@anonax I have XMPP file transfer trauma. for reals.

I still remember what bz2|base64 starts with because it was more reliable to do that to send small files.

(it's Qlp...)

@whitequark @anonax
Even XMPP uses HTTP for file uploads now