James Wheare

I’m not comfortable at all with the relay nick being fully spoofed into the source. Clients seeing messages from nicks that aren’t actually on the network would be an issue,...

Oh so regular clients don’t even have to opt in to seeing spoofed nicks? That sounds even worse. I get that you’re trying to improve the landscape but just punting...

No shade intended whatsoever. It just seems much better suited to a vendor prefix.

To be clear, I don't think this idea is niche, just this implementation of it. I think for something that's after all largely a display issue, clients should be involved...

If I'm understanding your comment properly, no, that's not my objection. I'd be very happy for a solution that uses a single bridging bot client and "spoofing" using a message...

"Clients should be involved" means that clients should have to implement support for displaying the "spoofed" nick somehow, and not just be fooled into thinking a message is coming from...

It's not academic at all. Non-existent users can't be interacted with in the same way. kicks, bans, dms, whois, etc. It breaks fundamental expectations of IRC presence. This may be...

The point isn't whether they're broken already, it's that with source spoofing they *look* like they aren't broken.

I’d be happy with a “display name” or “relay name” client tag spec. Whether servers use this as a hint to rewrite the source nick would be out of scope...

These will probably take a very similar form to the message-tags-3.3 sections: https://github.com/ircv3/ircv3-specifications/blob/8eb2bd8b21f1216a21ffd88eb9b7cf94057c27af/core/message-tags-3.3.md#security-considerations