mayel
commented
1 year ago Hi @makoConstruct thanks for your suggestions! We very much agree, and in fact you are almost exactly describing the "Topics" extension which we've developed (but isn't currently enabled on the campground instance while we focus on stabilising the more core functionality).
Hashtags are what some call a "folksonomy", whereas Topics are intended to be used more like a "taxonomy" (though actually a decentralised graph of taxonomies curated by many different people/communities on independent federated instances, compared to a more usual centrally-defined and read-only taxonomy).
Personally I think hashtags are very cool in how they're created bottom-up by users, and their definitions are indeed not clear or unique (the best one can do is observe and describe their common usage(s), similarly to how sites like https://knowyourmeme.com index and analyse memes, or what https://www.urbandictionary.com does with slang). On the other hand, taxonomies (which can be clearly defined, localised, and curated as trees or graphs, with links to sub-topics, parent topics, similar topics, etc) can be useful when you want to curate and organise knowledge/news/learning resources/skills/physical objects/plants & animals/etc... I'm very curious to see what people do with them in a decentralised network as opposed to central repositories of information though.
I'm including the definitions from Wikipedia for reference:
Folksonomy is a classification system in which end users apply public tags to online items, typically to make those items easier for themselves or others to find later. Over time, this can give rise to a classification system based on those tags and how often they are applied or searched for, in contrast to a taxonomic classification designed by the owners of the content and specified when it is published.
A taxonomy (or taxonomical classification) is a scheme of classification, especially a hierarchical classification, in which things are organized into groups or types. Among other things, a taxonomy can be used to organize and index knowledge (stored as documents, articles, videos, etc.), such as in the form of a library classification system, or a search engine taxonomy, so that users can more easily find the information they are searching for. Many taxonomies are hierarchies (and thus, have an intrinsic tree structure), but not all are.
makoConstruct
ivanminutillo
Is your feature request related to a problem? Please describe. It's not always obvious what a word means, just from usage, especially in large language communities where the meanings stray and multiple conflicting meanings exist. People often need the meanings of words to be explained to them. Tags will be the same. Some tags might be used for games with complex rules. Some tags might belong to movements. Some tags might just refer to tricky concepts. If you want tags to be able to hold nuanced meanings, or hold to a single usefully specific meaning on the federation level, they're going to need to be able to have descriptions.
Describe the solution you'd like There's a complication: What do you do when people disagree about a tag's meaning? (and what do you do when people disagree about how a tag should be localized? #31) You have to let them disagree. In a big decentralized world, there will always be disagreements about the meanings of words, we have to allow for that! We have to let the different communities of use go their separate ways, provide ways of resolving the confusion, and separating those invocations of the tag into different feeds that don't have to interfere with each other.
So, let different tags be defined under the same shortname, with full descriptions to disambiguate them.
The data representation can be unambiguous too, we can represent a tag mention as a link to a specific tag activity. (where the description is kept). Bonfire's editor should take '#' as a prompt to start an autocompletion (in the same way it already does for '@') that searches, first, through tags the user has used before, or tags that are popular on their instance, and finally through tags from the broader fediverse, and when they choose an option, the completion should produce a link like
[#oranges](https://bonfire.orangefarm.town/tag/12393298234919814384).When you go to the page of a tag, a (maybe cropped) description of its meaning and intended purpose should be visible. The full description should not have a char limit. The tag might have an owner who's able to edit the description, or it might be disowned/immutable, or it might be placed under the ownership of the instance's admins.
Related thoughts about localization I'm not sure if you know how you're going to do localization, so I'll think about that a bit, because this seems to be related.
... It's very rare that a tag owner (when there even is one) would ever gather every translation from every language themselves, it needs to be possible for people on different instances to contribute translations without having to coordinate.
I guess when you look at a tag, it would first check the translations defined on your own instance, then it would start looking at translations on other instances, with conflicts resolved according to some priority/ordering over instances set by the admin in the federation configuration (or, if you ever start using webs of trust between instances, the prioritization could also consider shortest path distance to the translation's instance).
Descriptions should also have translations.
(I notice that translations could potentially be abused/be subject to disputes. I'm not sure there's a really great way of dealing with abuse aside from webs of trust, but those are going to require new graph database indexes, I haven't developed those yet, so we'll just have to do it a non-great way and keep leaving all of the moderation burden to instance admins!)