Yeah, but that can easily be implemented in a client, have the client issue commands to nickserv. Same with avatars, just have a url in your VERSION to the avatar or something. All the features of eg. slack could be implemented client side on top of irc. I even run slack via their irc gateway. I handle file/image uploads with my tiny daemon running on http://paste.click and it's easier (for me) with keybindings than just dragging a file onto the screen, although it wouldn't be difficult to implement it.
And it's not silly at all, I understand it, I just wish it wasn't the case. I don't like it but I get it and I don't expect that irc will ever hit the mainstream. Maybe something similar will in the future.
That can indeed be done, although I fear that many clients and servers would implement these additional features differently, thus losing all the good that comes from IRC being an open standard.
I don't know if it's been attempted before... but I think it would be interesting to see something open and community-centered like IRC, but with all these little features people now expect.
It might well bee that the best idea going forward is actually to form up a couple of RFCs regarding nickserv and other bots (eg: channel loggers, nickname registration, what are they called, how do they work -- eg: /invite ChanLog -- /who #mychannel -> ChanLog in list -> indicate messages are archived for this channel -- that kind of thing), mandate TLs only connections -- and then have clients implement on top of that.
Perhaps some RFCs dealing with SRV-records (where is the web UI with channel logs?) -- or maybe even RFCs on how to mirror some functions (nickserv, logs) via REST-apis.
And it's not silly at all, I understand it, I just wish it wasn't the case. I don't like it but I get it and I don't expect that irc will ever hit the mainstream. Maybe something similar will in the future.