Move Community ID to advanced settings for simplify community creating process.

[MurzNN]

At now when we creating community, we must fill both fields - Community Name and Community ID, but popular Community ID's such as "ourcommunity", "mycompany", "supergroup" in public servers will be often already used, that will confuse users.

Maybe will be good to generate community id as UUID by default, and hide comminity id in advanced settings, to let users fill it manually only when needed, with allow to fill manual id later?

Like in Discord, we need only to fill the name for create new server, and don't need to think about id.

[lampholder]

Simplicity is valuable; there is a case for creating a group's to be just like creating a room (with an optional name, and an ugly unique string as the primary identifier internally, but with the ability to create aliases to provide more human-readable forms).

I did a fiddle a while ago suggesting a way some of the typing could be taken out of creating a group id http://jsfiddle.net/5ocu2cqk/5/ - that doesn't address uniqueness, though. Conceivably non-unique groupids could be suffixed with a unique integer (battlenet id style), but I'd be wary of introducing another unique identifier paradigm.

This whole thing bears more consideration. How important is the group id? Is it just for disambiguation, or is it the primary identifier of the group? We have three identifiers that look similar (mxids, room alises, group ids) - can they be considered peers?

/me makes a note to come back to this when it's not gone 6pm on a Friday 😛

[pafcu]

I feel like it would be valuable to have communities and rooms behave similarly, e.g. there is an arbitrary ID, a display name, and any number of aliases. It seems somewhat strange to have similar ID formats for communities and rooms when they in fact work differently.

(in fact this would be nice to have for user IDs too, just like it is common to have email aliases).

[MurzNN]

Yes, good solution will be use current community id value (ex +matrix:matrix.org) like room internal id !DgvjtOljKujDBrxyHk:matrix.org, and move human-readable id of community to separate field - community alias, like in rooms.

This will allow to keep current (already created) community ids, and use unique generated id's for new communities.

Community aliases will allow to make community server not significant, so users will can mirror communities like +matrix:matrix.org to his servers like +matrix-on-matrix-org:homeserver.com.

But for community alias we need new symbol (because + already used for id), or reuse symbol # with some prefix, like #community:matrix:matrix.org or something like #community#matrix:matrix.org - what do you think about this?

[pafcu]

Related: #5252

[pafcu]

Also, it might make sense to move the internal IDs to use a two-char prefix: first to show that it is internal '!', second to show type. E.g. !# for rooms, !+ for groups, ...

[turt2live]

The difference I see in group IDs vs room IDs is that group IDs look like aliases, which are user friendly. Room IDs are certainly not user friendly and should be hidden at all times.

Provided the group ID is presented in a way that's friendly (which it mostly is, in my opinion) then users should be able to understand the distinction of the group name vs group ID. In a very limited test of 5 very non-technical users, none of them had issues with the group ID and it felt reasonably natural for them.

Definitely a +1 to hiding the room ID at any given opportunity - that thing is just atrocious to look at.

[pafcu]

I don't think that group ids per se are somehow problematic. It more arises from the fact that they work differently than rooms (or the other way around), so if a user learns how rooms work (room ID, canonical alias, local aliases, etc.) they can't transfer that knowledge to groups, even though they look like they should behave similarly. And again, throw in user IDs into the soup, and now you have lots of different IDs that all work differently, even though the similar appearance suggests they probably shouldn't.

Sure, you can learn the difference. It just doesn't feel very intuitive. It just seems sensible to have a "canonical, non-changing ID", and then a number of aliases pointing to it.

[turt2live]

Well, on the groups having aliases front there's already existing issues for that: #5252

[t3chguy]

This is fixed by Spaces landing in Beta in next Release