[Feature request] API extension: Room tags

[mdPlusPlus]

Hi, maintainer of sessioncommunities.online here.

We're supposing the following API extension:

• Addition of tags for rooms/communities

Inspired by session.directory, we'd like to see the addition of some form of content tagging system for communities present on a SOGS. Operators could then use these tags at time of creation to correctly categorize their communities publicly.

We'd like to present three different proposals on how to approach this:

Variant A

A simple differentiation between NSFW and SFW content.
Basically a single flag, that tells us whether a community is supposed to contain NSFW content or not.
This would make it easier to list community related information in a work environment.

Variant B

A general tagging system relying on a hard-coded set of given tags. This would mean the Session/PySOGS devs had to come up with a set of a dozen or so content tags that would be shared across all SOGS instances. This has the added benefit that third-parties could group communities from different SOGS instances together under a single tag. We imagine this to greatly improve discoverability. Possible tags for this are: nsfw, offtopic, anime/manga, tech, gaming, popculture and so on.
Inspiration can be taken from the user-provided tags on session.directory.

Variant C

A general tagging system with operator-provided tags. This would allow operators to choose whichever tags they see fit for their communities. This system is a lot more flexible than variant B, but has the drawback of not sharing a common set across all SOGS. Basically this is what session.directory has implemented already.

[KeeJef]

Seems like a good idea, variant A seems like the best starting place, since its probably the most major distinction we want to make when displaying a list of groups to join, and developing a list of exhaustive tags for groups in variant B seems like it could be tricky. Variant C would seem to lose most of the attractive qualities of tagging since its harder to group custom terms.

[jagerman]

At the sogs backend level itself the only sensible implementation here is C, but for higher level interfaces (e.g. in the CLI took, or Session built-in management interface) we will want a standardized list. Thus if we decide to add new values it doesn't require a SOGS update to support them, but merely a client update to start using/recognizing new tags.