Nill

> Hi! I took a look at the code here based on a request from somebody else. > > Here's the first problem I spotted: > > > Because the...

+1

I would propose the obvious: `REGISTER ` `UNREGISTER ` Where `object` is a channel or nickname, or anything else in the future that may be registered to the currently authenticated...

I half-jokingly propose the commands and conventions in this spec I wrote 14 years ago: https://gist.github.com/nillkitty/77bad621d847a81d9cd68fb6f59c1cc7 See the Channel and Nickname services sections. This implies IRCX support but just pretend...

You'd probably want to be able to relay some other pre-pulled metadata besides the mime type, such as the file size, and a reasonable file name or alt text (the...

The issue with using capability nogotiation is that most clients do not wait for the server to send anything before sending their CAP, optional AUTH[ENTICATE]/PASS, NICK, and USER messages, so...

For example, mIRC sends `CAP LS`, `NICK ...`, and `USER ...` as soon as the socket connection is open. If you wanted to tell it that it needs to `AUTHENTICATE`...

Ok that makes sense -- I didn't realize it held waiting for `CAP END`. In that case I agree.

I'll take a look and see -- could you be any more specific with what you feel is off? Any particular animation or physics metric? Were you able to make...

This would work really well in combination with a specification for "auditorium mode" which IRCX had (+x) and many server impl's have some concept of. My preference would not to...