ircv3-ideas
ircv3-ideas copied to clipboard
ircv3
IRC over QUIC as a standard
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: https://github.com/ircv3/ircv3-specifications/issues/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?
Could in theory provide smooth connection migration when an IRC server goes down
IRC connections are somewhat stateful, so I'm not sure how this could help, or be any different from making a new TCP connection to the new server and asking it to "resume".
Could in theory provide smooth connection migration when an IRC server goes down
IRC connections are somewhat stateful, so I'm not sure how this could help, or be any different from making a new TCP connection to the new server and asking it to "resume".
Well, in theory that state could be migrated and then clients don't have to massively reconnect.
Well, in theory that state could be migrated and then clients don't have to massively reconnect.
The same can be said of TCP.
Well, in theory that state could be migrated and then clients don't have to massively reconnect.
The same can be said of TCP.
Maybe with just TCP but with TCP+TLS it's way more complex than what QUIC offers though?
IRC doesn't specify any transport. Second paragraph of RFC1459: The IRC protocol has been developed on systems using the TCP/IP network protocol, although there is no requirement that this remain the only sphere in which it operates.
So it already supports QUIC in theory.
Maybe with just TCP but with TCP+TLS it's way more complex than what QUIC offers though?
As far as I know, the transport is nearly irrelevant to the problem – most of the complexity is on the application layer anyway (getting the new server to recognize you, rebuild state, update routing for the nickname across the network). But do you have a specific mechanism in mind already? That is, what precisely does QUIC offer for this feature?
For everything else, QUIC would do the job, but it doesn't sound like it needs a specific "IRC over QUIC" profile, just a generic "QUIC as TLS substitute", same as SMTP or IMAP...
Has a lot of development power behind it from big corporations
Do any of them care about non-HTTP applications?
So it already supports QUIC in theory.
It does not forbid QUIC, supporting it is a whole another topic.
Do any of them care about non-HTTP applications?
There's an expired RFC draft for DNS-over-QUIC, so there's some interest, but QUIC is still really new so making a definite decision if they care or not is rather hard to say.
But do you have a specific mechanism in mind already? That is, what precisely does QUIC offer for this feature?
You can read more about what QUIC inherently tries to provide for migration in the RFC: https://tools.ietf.org/html/draft-ietf-quic-transport-17#section-9
You can read more about what QUIC inherently tries to provide for migration in the RFC:
It is all about migrating to new addresses for the same endpoint (or at least an endpoint that can exactly replicate the state at both QUIC and IRC levels), and currently seems to be limited by spec to clients only.
This would be very useful for roaming clients without having to use a bouncer, in place of the work-in-progress "RESUME" extension that's necessary for TCP. But I still don't see it helping with moving to a completely new endpoint – especially when the original one goes down unexpectedly and its state is lost (and I even suspect it would be simpler for the client to just reconnect and try resuming at IRC level.)
I think there should be documents about IRC's usage of e.g. transport layer roaming features (how they interact with bans and I:lines, whether the host change should be announced as a CHGHOST, etc.) or 0RTT usage and so on. But I feel like this should be a generic document and only using QUIC as an example, since many of those features aren't exclusive to it either.
I would be interested in seeing an experimental implementation of this once the IETF publish the QUIC RFC.
SCTP gets mangled by middleboxes and will not have such a good support as QUIC/HTTP3 does in various (standard)libraries.
I don't think it should be mandatory. Perhaps a feature where is mandatory for being labeled IRCv3, but also consider that unencrypted IRC may be used for networks that are already private/encrypted and is both redundant and hard to implement a Key Infrastructure.
VPNs, and darknets like TOR and I2P come to mind.
SCTP gets mangled by middleboxes
Then, SCTP-over-UDP (RFC 6951), for the same reason QUIC uses UDP.
The main reason i'm personally uninterested in SCTP is that there's no support in either Windows or macOS (which has it IPPROTO_SCTP in the headers but creating a socket using it results in an error) which makes it not very useful for the average user.
You can blame whoever you want but that doesn't change the reality that features which 90% of potential users can't use are useless.
If Google couldn't get OS vendors to care about SCTP then we won't be able to.
There is a proper driver which can be installed for OSX and one for windows, but I heard its not in a good state. Maybe we should get more SCTP applications first and then demand OS vendors to add SCTP drivers.
Please move SCTP discussion over here: https://github.com/ircv3/ircv3-ideas/issues/62
The current QUIC interop situation is this: https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=117825384
The current draft for IETF QUIC is still moving relatively quickly, so it makes sense to be cautious and wait for consensus before standardising this, but IMO it'd be interesting to experiment with the current 14th draft against which implementations are currently slowly converging.
QUICv1 has been finished for a while at this point (A small v2 is currently being worked on), support should be good enough that devs shouldn't expect to run into issues with functionality or compatibility
