Add the ability for users to add custom tags to beatmaps

[apollo-dw]

Keeping this super short and sweet, there were talks about adding a guideline to ranking criteria to tag the "style" of a beatmap, however there were concerns with standardizing this sort of thing.

I propose delegating this task to players. Imagining a system similar to what Steam has (screenshot below), there will be no need to define terms - players will know that stuff best. My proposal is strictly for terms that would describe a map, since I'm not sure whether user tags would be useful for describing other things...

[cl8n]

for the RC thread, the perceived issue was that direction/organisation would be required to use the tags meaningfully, not that it needed standardization from the beginning. I think the same issue applies to this

also

• comparison to steam assumes that people have common sets of words to describe osu gameplay, I don't think this is true beyond the simplest of things
• I don't see how u could implement the restriction to gameplay tags
• moderating this seems impossible

seems cool but like the RC thing I don't think it's practical to implement (yet!)

[Hiviexd]

i think having something like this could greatly benefit searchability for players and mappers alike. to solve the moderation/consistency issue, we can have players submit tags for "approval" (a 5-second task that can be done by NAT/GMT), and have those approved tags to be usable on any map by players.

if a map has misleading user tags, that can be handled through the usual beatmap report where any moderator can fix it accordingly.

[Walavouchey]

this could potentially be viewed as an alternative direction for https://github.com/ppy/osu-web/issues/5852

https://omdb.nyahh.net/descriptors/ list of tags used by a community beatmap database

peppy mentioned making the list predefined instead of user-defined in today's catch-up meeting. in that case the nat or bn would likely be the ones to manage the tag list and fix wrong tags whenever needed

[apollo-dw]

peppy mentioned making the list predefined instead of user-defined in today's catch-up meeting. in that case the nat or bn would likely be the ones to manage the tag list and fix wrong tags whenever needed

just to give more detail here, the "user-defined" tags are added by virtue of proposals that are critiqued and voted on by users -- they only pass if they have a majority

i would love to elect myself to look after the tags/descriptor list on osu-web if this goes through, as someone whos bn and already oversees omdb... and has cared about this feature since 2021 according to the issue open date 😅

[Hiviexd]

the general consensus from the NAT meeting about how this should work was:

• start with incorporating (most of) the tags from https://omdb.nyahh.net/descriptors/
• implement the system in a way that makes it easy to add/edit tags via osu-web PRs
• have a forum thread where people would suggest tag additions, the NAT will periodically review requests and add the more popular requests to osu-web
• users can select any amount of tags on any beatmap (possibly limit to prevent abuse? could use more opinions)
• the beatmap page will immediately display the top 3 selected tags, with a "show all tags" button that can open a popup that contains all tags
• the amount of selections a tag received should be displayed (rough example below)
• GMT/NAT can remove any tag from any beatmap regardless of votes, this will be used for moderation purposes, i.e. map gets brigaded with wrong tags
• every action is logged in the beatmap discussion history page

by the way we didn't discuss if we should have dedicated selections of tags per mode (to allow more freedom for other modes + keep things organized to prevent the wrong tags from being used in the wrong modes), but it's worth considering as i think the majority would be in support for it.

[peppy]

All sound roughly in line with what I saw being required for MVP 👍

[peppy]

Here's an initial proposal for how we can get things moving.

TABLE beatmap_tags (beatmap_id, tag_id, user_id)
       PRIMARY KEY (beatmap_id, tag_id, user_id) -- mostly just to make it unique

TABLE tags (tag_id, name, NULLABLE BOOL approved)
PRIMARY KEY (tag_id)
UNIQUE INDEX (name)

to get displayable tags for a beatmap:

SELECT DISTINCT(name) FROM tags JOIN beatmap_tags USING (tag_id) WHERE beatmap_id = @beatmap_id AND approved = 1

would want to double-check this will perform okay. I think it should as it can use the beatmap_id,tag_id portion of the primary key, but it may still get slow when counting votes for each tag. In which case we'd want a totals table.

to give users a list of popular tags they can upvote:

SELECT name, COUNT(*) FROM tags JOIN beatmap_tags USING (tag_id) WHERE beatmap_id = @beatmap_id AND approved = 1 GROUP BY (beatmap_id, tag_id) ORDER BY COUNT(*) LIMIT 10

• To keep things simple, we'd be applying tags to beatmaps, not sets, which could be annoying if a user wants to tag a genre or similar. I think we could just handle this at the API level, where if a flag is specified the tag will be appended to all difficulties in the set. The user would select a setting like "Apply tag to all difficulties" when adding each tag.
• Let's keep the user facing modify operations as an API-only system for now, and implement in lazer to begin with. I'd hope it requires a user to play through the map to interact with, and is implemented in a way which makes it fun to participate.
• Approval of tags can be done using ASS or some kinda web system. It would just show all tags which don't have an approval state set, and allow rejecting or accepting. I'd propose that tags start in a non-displayed state until someone goes to approve them.

[apollo-dw]

My suggestions here would be:

• Let's allow providing descriptions for tags. Some might not be immediately obvious, and they would be helpful for people who are confused or new players.
• I'm not convinced that a single approval is appropriate here. Certain tags can be very subjective (for example, for tags related to aesthetics or gameplay), so I think we should be accounting for that with a majority-vote system. This also means there isn't a single person on the hook if they approve a tag which most people actually disagree with.
• I would love support for child-parent relationships between tags for UX and categorization, but this is lower priority and can come later.

Totally agreeing with applying tags to beatmaps, and a setting to apply to all difficulties seems nice.

[peppy]

Let's allow providing descriptions for tags. Some might not be immediately obvious, and they would be helpful for people who are confused or new players.

I don't think this should be up to the user. It should be up to moderation / management.

I'm not convinced that a single approval is appropriate here. Certain tags can be very subjective (for example, for tags related to aesthetics or gameplay), so I think we should be accounting for that with a majority-vote system. This also means there isn't a single person on the hook if they approve a tag which most people actually disagree with.

The approval is for completely disallowing tags, at a system level, not beatmap level. There is not approval for beatmap level tags – it would be based on user vote count. If abuse is seen we can wipe votes or add some kind of hide flag.

[apollo-dw]

Okay understood - so the full list of tags will be created by the userbase, and abuse tags will be disallowed on a case-by-case basis. I agree that descriptions shouldn't be up to the user, but I also suggested that under the impression that we will be providing the list of tags from the get-go and that there would be no support for custom tags. That doesn't sit well with me personally, but I'm not the boss and this is better than nothing

[peppy]

Just to be clear, you prefer the proposal I made just now where users can create new tags right?

[apollo-dw]

Unfortunately no, I think being rigid with the list of tags is preferable here. There are multiple reasons I can think of for why:

• Custom tags means there is a larger moderation overhead. Case-by-case approvals on a system level, although tiny, is something that could be avoided altogether with a rigid list of tags
• A rigid list means there can be support for more specialized detail for users. I've mentioned descriptions and potential child-parent relationships between tags: this can be extremely useful for new users and people exploring maps.
• A rigid list means there is a significantly stronger tagging coherency between maps. I can easily imagine people will be tagging, for example, comfortable aim maps in a multitude of different ways. "jump aim", "comfortable aim", "aim", these have to be consolidated into one to make beatmap filtering at all useful for anyone. Extend this synonym issue to every single possible way you can describe a beatmap.

These are the main reasons, there are some more minor ones as well. I suspect that for a custom tags system to be actually useful and usable for players, we'll need to be disapproving tags all the way down to what is basically a rigid list. Lets save ourselves the ballache here.

[peppy]

Okay, in that case we can nuke the approved flag and just use a flat list to start with.

We'll probably also want an endpoint to retrieve all flags for local filtering as a user types.

[peppy]

Updated proposal:

TABLE beatmap_tags (beatmap_id, tag_id, user_id)
       PRIMARY KEY (beatmap_id, tag_id, user_id) -- mostly just to make it unique

TABLE tags (tag_id, name, description)
PRIMARY KEY (tag_id)
UNIQUE INDEX (name)

to get displayable tags for a beatmap:

SELECT DISTINCT(name) FROM tags JOIN beatmap_tags USING (tag_id) WHERE beatmap_id = @beatmap_id

would want to double-check this will perform okay. I think it should as it can use the beatmap_id,tag_id portion of the primary key, but it may still get slow when counting votes for each tag. In which case we'd want a totals table.

to give users a list of popular tags they can upvote:

SELECT name, COUNT(*) FROM tags JOIN beatmap_tags USING (tag_id) WHERE beatmap_id = @beatmap_id AND approved = 1 GROUP BY (beatmap_id, tag_id) ORDER BY COUNT(*) LIMIT 10

• To keep things simple, we'd be applying tags to beatmaps, not sets, which could be annoying if a user wants to tag a genre or similar. I think we could just handle this at the API level, where if a flag is specified the tag will be appended to all difficulties in the set. The user would select a setting like "Apply tag to all difficulties" when adding each tag.
• Let's keep the user facing modify operations as an API-only system for now, and implement in lazer to begin with. I'd hope it requires a user to play through the map to interact with, and is implemented in a way which makes it fun to participate.
• The tags table will be filled from a provided source (so a user will be choosing from a specified list of tags). There should be a way to retrieve all tags in the system for local filtering / autocomplete in the client.

Required endpoints:

get_top_tags_for_beatmap(beatmap_id)
returns the top 50 tags for a specified beatmap

store_tag(beatmap_id, tag_id)
allows a user to specify (aka vote) for a tag

delete_tag(beatmap_id, tag_id)
allows a user to remove their vote for a tag

get_all_tags()
returns (id, name, description) for all known tags

[peppy]

Backend for this is now merged 🎉

Remaining is:

• Displaying these tags on web and client (lazer)
• Adding user voting controls for the tags to client (lazer)