Disable implicit MOTD and NAMES

[emersion]

It would be handy for some clients (especially mobile clients which often disconnect/reconnect) to disable implicit MOTD and/or NAMES sent after connection registration. This would allow these clients to more quickly synchronize with the server when resumed.

This could for instance be enabled with no-implicit-motd and no-implicit-names caps.

[slingamn]

Here's some benchmarking I did earlier. I think my inclination is to see this as two separate issues:

1. Opting out of the MOTD and possibly the 005; this is not a huge win AFAICT because it's just additional data sent by the server, not additional roundtrips (and probably not that much data relative to history backlog). Reattach latency in current implementations seems to be dominated by the roundtrips of CAP negotiation and SASL, which are actually inessential (a reattaching client could send the entire client side of the negotiation at once without waiting).
2. A paginated API for NAMES and/or WHO; this is applicable even outside of the mobile reattach context because it improves the scalability of extremely large channels

[emersion]

Opting out of the MOTD and possibly the 005; this is not a huge win AFAICT because it's just additional data sent by the server, not additional roundtrips

Right, I'd tend to agree here. Also ENDOFMOTD/ERR_NOMOTD is used by some clients to fetch chat history and perform some other bookkeeping.

Reattach latency in current implementations seems to be dominated by the roundtrips of CAP negotiation and SASL, which are actually inessential (a reattaching client could send the entire client side of the negotiation at once without waiting).

FWIW, in Goguma I've actually implemented a single-roundtrip connection registration (sending everything at once: CAP, NICK+USER, AUTHENTICATE, etc).

A paginated API for NAMES and/or WHO; this is applicable even outside of the mobile reattach context because it improves the scalability of extremely large channels

Interesting, although I'm not sure this is really a concern? Even on very large channels (e.g. #libera with 2k members) this doesn't seem to be much of an issue, at least for NAMES. For a WHO on the channel I haven't tested, the whole reply is maybe 200KiB?

[emersion]

BTW in my client I don't actually need the list of all members in all joined channels. I can lazy-load it when the channel details page is opened or when autocomplete kicks in.

[slingamn]

Also ENDOFMOTD/ERR_NOMOTD is used by some clients to fetch chat history and perform some other bookkeeping.

+1 for this use case of RPL_ENDOFMOTD/ERR_NOMOTD to indicate "end of handshake". I think if we designed a CAP for this, it would just mandate that the server send ERR_NOMOTD (which a compliant client would treat as a non-error case). (Alternatively RPL_MOTDSTART followed immediately by RPL_ENDOFMOTD would probably work just as well.)

FWIW, in Goguma I've actually implemented a single-roundtrip connection registration (sending everything at once: CAP, NICK+USER, AUTHENTICATE, etc).

Awesome!

Even on very large channels (e.g. #libera with 2k members) this doesn't seem to be much of an issue, at least for NAMES.

I think on competing platforms the largest communities are significantly larger than this. I think the Fortnite Discord has 100k participants?

[emersion]

I've done a few experiments with no-implicit-names in the Android emulator. Here are a few numbers when connected to 6 of the more popular Libera Chat channels:

HSDPA:
vanilla:           0:03:35.857771
no-implicit-names: 0:00:01.473293

LTE:
vanilla:           0:00:01.499554
no-implicit-names: 0:00:01.446111

(Network strength set to "moderate" in the emulator settings.)

This is very beneficial for 3G+, but doesn't buy much when running with 4G.

(Another benefit is saving bytes for small mobile data plans -- mobile clients are bound to disconnect and reconnect very often.)

[emersion]

draft/no-implicit-names has been merged.