Thunderstore
Thunderstore copied to clipboard
thunderstore-io
[RFC] Tags
Originally posted by @MythicManiac in https://github.com/thunderstore-io/Thunderstore/issues/288#issuecomment-803599683 Details inferred by @nihaals
Italics means under review.
Tags are a way to add metadata about a package from the package manifest. They are intended to replace the existing category system part of metadata stored in Thunderstore (as opposed to the package manifest).
They are planned for manifest v1.
Manifest syntax
{
"name": "Test-Package",
...
// These example tags would probably conflict
"tags": ["modpack", "tool"]
}
Tags are restricted by a-zA-Z0-9- and have a max length of 32.
How they are connected to Thunderstore
Community admins (categories are scoped by community) can "connect"/bind tags to a corresponding category. Multiple tags can be assigned to a single category, but this should be reserved for synonyms. Categories should have both a display name and a slug (for the API).
To avoid typos and a lot of synonyms being used for the same category, uploads can be rejected if they contain an unknown tag. A disadvantage of this is you cannot upload a package with a tag that hasn't been made yet so the category can be created later. This could block an upload as a community admin needs to create a category mapping. If unknown tags are blocked, this could cause a package to be uploaded which would be considered invalid in the future if the category mapping is deleted after it is originally uploaded, which partially goes against the idea of all important information being in the manifest, allowing a registry to be made just based on the package files. This behaviour can be toggled by a community admin.
Tag categories can be filtered from package search and can be used in defining sections.
Tags on a package can be overridden by community admins to help reduce spam. This supports both removing and adding tags. These will apply to a specific version, usually latest. This means the overrides are removed when a new version is uploaded.
As tags are version specific, the latest version is used for filtering.
Having tags be free input (unlike for example PyPI's classifiers) means communities will likely develop their own "standard" tags. This could cause fragmentation as different communities may use different tag names yet may have very similar goals. For example, one community might use tool while another might use non-mod. This doesn't feel great in my opinion, but allowing community admins to create their own may be useful for smaller communities where a global list that can be selected might not fit. Maybe there's a solution to this?
I haven't looked at the implementation of sections yet but they appear to be community wide saved searches (possibly restricted to only category filters, but this can be improved if it is), so it would probably make sense to have tag categories/new categories be supported.
Having tags be free input
This is the only way, because tags are in the package schema, and we can't realistically predict every tag that might be useful. Grouping similar tags together is a much easier problem to solve than it would be to pre-define all possible tags that may or may not be useful. On the other hand, tag use fragmentation would have very little impact to the overall ecosystem, since it's a problem that can be solved by grouping similar tags, or packages can simply define all known variants of a certain tag. First and foremost I want to avoid having unnecessary restrictions in the package format, and in this case I'd argue restricting allowed tags to some preset values does not actually offer any real impactful benefit.
It would be nice to have this RFC stable soon since the implementation is blocking #289 and the experimental package upload API from being stabilised.
Agreed.
An additional consideration is what a package manifest based tag system implies for site moderation? Their role would fit as a substitute for the current category system, but we'd still want to retain moderation control over what package gets placed under which category, and to let moderators to add or remove tags appropriately.
One option would be to use the tags as defined in the package schema as the base set of tags, and allow moderators to "override" specific tags for site display purposes.
One option would be to use the tags as defined in the package schema as the base set of tags, and allow moderators to "override" specific tags for site display purposes.
I think this works well, especially if we can still encourage users to mainly use the manifest and not on rely on Thunderstore metadata changes. One way could be only supporting removing tags, but this wouldn't allow fixing a typo (as you would also need to add a tag) and might feel awkward since we're intentionally not adding functionality which might cause friction.
I've added 2 sections relating to overriding tags and how tags are actually fetched.
Tags on a package can be overridden by community admins to help reduce spam. This supports both removing and adding tags. These will apply to a specific version, usually latest. This means the overrides are removed when a new version is uploaded.
As tags are version specific, the latest version is used for filtering.
This also highlights a possible issue. If a package adds every tag used in a community and then gets overridden, they can just upload a new version.
We could store the "diff" of the overrides instead of a list of tags to use instead, which could be essentially merged with the latest version which would mostly solve this issue. We would probably need to make this clear somewhere, so people are not confused why a tag they added isn't being used on the website, which would also make it easier for uploaders to request their overrides to be changed as the package's tags have changed now for a good reason.