Better clarity of which channels are connected to which service

[silverbucket]

When I have one or more XMPP and IRC accounts set up, it's a little confusing as to which rooms are which, since they all start with a hash at the moment #.

Some ideas:

• Use a mini XMPP SVG logo for prefixing XMPP rooms
• Use the logos at the service name header

Assuming we could make/find a nice little SVG logo I think option 1 could look nice.

As it is now, I always have a moment of pause when I am looking at the left because many of the channels are named the same and it's not immediately clear which is for which service.

[raucao]

How would you find a logo for a service in an automated way? Neither IRC nor XMPP support this at the moment AFAIK. It would be useful, of course, so you could also build UI similar to Discord for switching between servers for example.

XMPP has room avatars in the protocol, but IRC does not. In the case of that Kosmos room, the avatar would likely be the same on both though.

I never really had an issue with finding the right room so far, even though I have multiple with the same name. If you actually use the app for a little while, you can easily remember which space is which I think. And if you onboard normally, you likely don't have multiple spaces immediately, so you know which one is which by way of using it with one, then another one added, and so on. Not saying that means we shouldn't have service avatars, just that I would guess it's less of a problem in real usage, and more in testing.

[silverbucket]

I meant just find an SVG XMPP logo as part of the app resources. But yeah, good point about the icons for the rooms. So then the XMPP logo could be a part of the header of the service name (option 2)?

For me the hash before every single room is really confusing. I understand once you use it a lot it's less of an issue, but it would be nice to make it less likely to get mixed up. (unless of course it just ends up looking too cluttered)

[raucao]

For me the hash before every single room is really confusing. I understand once you use it a lot it's less of an issue, but it would be nice to make it less likely to get mixed up. (unless of course it just ends up looking too cluttered)

Yes, if you repeat the server name in every single line, then it's completely cluttered. Most clients don't even show the rooms by domain, but just show a list of rooms, and if they have the same name, then that's just unfortunate.

Once we can query room info, we can also get human-readable names, so we can add an app preference to show those instead (which will make it inconsistent with IRC rooms, of course). My current plan was to use the channel name/handle in the channel menu, and the human-readable name in the title bar of the channel container.

[silverbucket]

Yes, if you repeat the server name in every single line, then it's completely cluttered. Most clients don't even show the rooms by domain, but just show a list of rooms, and if they have the same name, then that's just unfortunate.

Maybe there's a misunderstanding here. I don't mean repeating a server name every line. I mean in the heading for the service (eg. kosmos.chat) there could also be included an XMPP SVG icon. Then we know everything in that grouping is an XMPP channel. Those channels in the list could also have their custom icons for the chat room.

Similar for IRC, though it's a little less clear how to best to do that, since # is sort of the icon for IRC itself, and also for each channel prefix.

[raucao]

With XMPP allowing you to connect to any room on any server, most of the domains in the list would show the same icon then, defeating the purpose for this use case.

[silverbucket]

With XMPP allowing you to connect to any room on any server, most of the domains in the list would show the same icon then, defeating the purpose for this use case.

Well it clarifies XMPP vs IRC services. But yeah I see your point.

[raucao]

Maybe we should write a small XEP for server/service avatars. I'll check if something like that exists already. Could also be added to IRCv3 I guess. Or it could just be something generic for any domain on the Web.