whoami extension for NUH discovery

[slingamn]

From discussion in #ircv3, this is an extension allowing clients to maintain an accurate view of their NUH for computing message lengths.

[jwheare]

I support the concept of a cap to allow this information to be sent earlier in the connection burst without having to be queried.

However, I suggest avoiding a new format and verb and simply reuse the WHO format. Negotiating the cap would indicate that the client can accept an unprompted bare 352 RPL_WHOREPLY sent on connect with or without an end of who.

This would mean no duplicated handling for clients that already WHO themselves on connect, which (despite this proposal's text) is a reliable mechanism for receiving this information, and which will need to remain for servers that don't advertise the proposed cap.

Why is there provision in this proposal for realname to be omitted in some circumstances? Feels like unnecessary uncertainty? Also, is an empty realname possible/valid?

Also, regarding CHGHOST's SHOULD weakness regarding sending to the affected user, I think that's an unfortunate case of having to deal with existing implementations in the wild based on an ambiguous original spec, rather than a deliberate soft intent. There is some discussion on that in #324.

I believe most implementations do now send it to self and would assume that anyone implementing the cap proposed here would do so.

[jwheare]

While I strongly approve of "nuh" as a shorthand in discussions, we don't normally use the term in specs. Modern and the registry use "nickmask", userhost-in-names mentions "full hostmask". Most specs just say "the user identified by nick!user@host"

[jwheare]

RFC1459 calls it "the extended prefix"

[slingamn]

However, I suggest avoiding a new format and verb and simply reuse the WHO format. Negotiating the cap would indicate that the client can accept an unprompted bare 352 RPL_WHOREPLY sent on connect with or without an end of who.

The motivation for this came from client library development, where it's not obvious that a consumer of the library will be able to handle bare 352 (since the consumer may have been written with conventional assumptions about 352/315).

I'm not totally confident in my stance here, but a new verb seems much cleaner to me (unlikely to interfere with any existing code) and the implementation burden seems minimal. My implementation would be something like this:

1. Add a handler to parse WHOAMI and populate a local userhost field (5-10 SLoC)
2. If at the end of connection registration, the local userhost field is already populated for any reason, suppress self-WHO

Why is there provision in this proposal for realname to be omitted in some circumstances? Feels like unnecessary uncertainty?

It's sent during connection registration so it can be a complete replacement for self-WHO. It's a MAY at other times because we don't expect the realname to change unprompted (in contrast to the userhost), because there's already a different cap for realname updates, because there's no expectation that the server send WHOAMI for a realname update, and to save some bytes.

Also, is an empty realname possible/valid?

I can take this line out (I'm not aware of any implementation that allows it), but I don't see that it's officially disallowed anywhere, and it would be valid at the protocol level since we always send realname as a trailing.

I believe most implementations do now send it to self and would assume that anyone implementing the cap proposed here would do so.

What are the implications of this, though? Clients still cannot rely on chghost as specified/advertised to receive self-updates.

While I strongly approve of "nuh" as a shorthand in discussions, we don't normally use the term in specs.

+1, I'll use some other language in the next round of updates.

[jwheare]

The motivation for this came from client library development, where it's not obvious that a consumer of the library will be able to handle bare 352 (since the consumer may have been written with conventional assumptions about 352/315).

The client library is responsible for its api surface. If it thinks consumers can't handle stuff bare, it needs to not pass that onto the consumer but provide it in a compatible way. Supporting a new cap requires code change from a consumer, but the consumer of the consumer feels out of scope to me. I'll let others chime in though.

save some bytes

I'd prioritise a consistent response structure over a handful of bytes. I don't think receiving this response this should imply that everything in it has necessarily changed. Clients shouldn't choke on a no op.

Clients still cannot rely on chghost as specified/advertised to receive self-updates.

Well, in practical reality terms they can. But if we want to strengthen the CHGHOST behaviour, we should do that instead of duplicating its functionality with a brand new verb. You could make this cap convert the chghost SHOULD to a MUST.

[slingamn]

Well, in practical reality terms they can. But if we want to strengthen the CHGHOST behaviour, we should do that instead of duplicating its functionality with a brand new verb. You could make this cap convert the chghost SHOULD to a MUST.

Heh, how would you feel about a cap that:

1. strengthens chghost's SHOULD to MUST
2. requires the server to send both a CHGHOST and a SETNAME line in the registration burst?

[jwheare]

I don't hate it :)

[slingamn]

Updated in response to feedback. tl;dr

1. The client now requests both draft/whoami and chghost
2. The server must send the client updates about its own userhost, via CHGHOST
3. The client indicates its ability to parse SETNAME in the registration burst; the server must send SETNAME in the registration burst (which carries both the NUH and the realname)

This is ironically much easier to implement on the server side (a server implementation of CHGHOST that already complies with MUST merely has to start sending SETNAME in the registration burst). It's an epsilon harder to implement on the client side, but I don't foresee any real problems. (The only thing that seems suboptimal to me is that the client gets everyone else's CHGHOST lines as well, even though it might not want them.)

I used "prefix" as the terminology for NUH (I personally consider anything with "mask" in it to be a misnomer).

[andymandias]

Having a standardized method for determining NUH would be a welcome capability for use in Halloy, and the utilization of CHGHOST and SETNAME messages will make it very straightforward to add draft/whoami. Thank you for proposing the specification.

For the current Halloy implementation there isn't any issue with tying draft/whoami to chghost and opting in to all CHGHOST messages. There also wouldn't be any issue with separating CHGHOST message utilization from the chghost capability, similar to SETNAME utilization without the setname capability, but there is no burning desire for it.

[ValwareIRC]

LGTM