Open emersion opened 1 year ago
Is the use case for this that clients could cache the advertised alternate service ports for later use if the stored configuration for an IRC server is not reachable because of port blocks?
How would this help connecting to an IRC server the client has never used on such a port-block-happy network?
Yeah, that's the idea.
Now that I think about it, it sounds like https://github.com/ircv3/ircv3-specifications/pull/483 could also fit the bill pretty easily, and would also work in the case where the first connection is made from a potato network. So maybe it's a better solution to this problem.
the case where the first connection is made from a potato network
This was what had me thinking, yes. Advertising an alternative using a method that's not visible if a client is unable to connect using the default connection information is of limited use. Existing users of an IRC server are more likely to be aware of where they can get alternative connection info than are new users of that server.
I mean, most of the time users set up their IRC connection through a reasonably behaved network, and then it gets broken when they connect through a bad one. But yeah, if we can find something which works in all cases, the better.
Some (corporate or public) network operators choose to block most ports. This makes it complicated to connect to IRC servers on the default port.
Add a way for servers to indicate alternate host/port which can be used to connect, e.g.
tcp.irc.example.org:443
. Could also indicate support for alternate protocols like WebSocket.Would be similar to HTTP Alternative Services: https://www.rfc-editor.org/rfc/rfc7838.html