Server icons

[SadieCat]

It'd be nice if server admins could associate an icon with their server which clients could show in their UI.

An entirely unthought through idea for how this could be done is an ICON=[<url>] 005 token which has the URL of the icon as the value.

It could also be like the proposed avatar metadata in ircv3/ircv3-specifications#336 and contain {size} for the size of the icon and then we could have another ICONSIZE=<size>,[<size>]+ token with a list of available icon sizes.

Input from client developers is appreciated.

[jwheare]

Dunno if ICONSIZE is necessary, if the {size} value is used in the same way as the avatar metadata proposal (any value is acceptable as a sizing hint, though the image server can decide whether or not to honour it, as long as the url still returns an image)

I like the idea, would need some UI experimentation around where to show it, what to fall back on when servers don't present one, etc.

[SadieCat]

I made a quick module to add an ICON 005 token and put it on testnet.inspircd.org if anyone is interested in experimenting this.

[GIJack]

URL is a bad idea. It should be included in stream. to prevent abuse, propose a max file size in bytes, as well as dimensions, perhaps 512x512, with the expected icons being 128x128 being normal. perhaps specify the format that it would have to be a png or something?

should be icon=/path/to/local/file

[SadieCat]

Realistically there's no reasonable way to have images in-band due to character and length restrictions and the risk of abuse is minimal as clients already fetch arbitrary images from users.

[GIJack]

reasonable way? just an array of bytes, ascii encoded if need be. It could also be spaced over many blocks/messages. There is no reason for avatars to be longer than 60-100KB anyway. could be just another server message.

edit: if you have a URL, you need a URL handler, which now the client needs another protocol handler. http:// ? How much HTTP do you want to put in an IRC client. This becomes standard?

[SadieCat]

reasonable way? just an array of bytes, ascii encoded if need be. It could also be spaced over many blocks/messages. There is no reason for avatars to be longer than 60-100KB anyway. could be just another server message.

60-100KB is about the size of 120-200 IRC messages even if you ignore everything else that needs to be in the message and the overhead from base64 encoding.

edit: if you have a URL, you need a URL handler, which now the client needs another protocol handler. http:// ? How much HTTP do you want to put in an IRC client. This becomes standard?

Clients fetching HTTP resources (e.g. embedding images posted in channels) is pretty standard nowadays and every programming language has the tools for fetching HTTP resources. Using an URL is also in line with other proposals such as the avatar metadata.

[slingamn]

What exactly is the abuse concern?

[DanielOaks]

+1 for having this just be a URL

[dequis]

URL concerns belong in #16, a ticket made specifically so that we don't repeat that discussion every single time.

[slingamn]

Thanks, #16 is very helpful.

However, #16 is about URLs provided by other clients, not by the server, and server-provided URLs seem to pose a strict subset of the privacy concerns that client-provided URLs do. For example, there's no concern about leaking the client's IP, since the server already has it.

I am still not sure how Sadie's proposed solution (server publishes a URL in an isupport token) would pose an abuse concern.

[nillkitty]

I don't see any risk associated with the client obtaining a server icon from an arbitrary URL; the server already knows the client's IP and any image processing/display vulnerabilities are a risk regardless of the client displays the (admin-set) icon.

My suggestion is that the icon, along with other meta details (rules, staff, services info) be incorporated into a schema the server sends to clients, with, among other things, descriptions of the mode char mappings and other instance-specific details.

Cluttering 005 with URLs probably won't scale well as server operators and client authors come up with other things that can be "branded".

[SadieCat]

My suggestion is that the icon, along with other meta details (rules, staff, services info) be incorporated into a schema the server sends to clients, with, among other things, descriptions of the mode char mappings and other instance-specific details.

This is literally what 005 is for.

[nillkitty]

005 is not a schema; it's a bunch of support tokens. A client cannot look at 005 and know exactly what every mode character, command, extban, chanop level, etc. actually does. It knows which ones require parameters (and which priority/prefix they have), but how does a client translate "+u" into something meaningful that a normal person can reason about? How does a client objectively know that "+C" on this network means "No color" and "No CTCP" on another?

A schema describes not only describes the server/network constructs, but also what they actually do/how they will behave.

[progval]

@nillkitty Sadie meant you should define a new isupport token.