might try a new thing where i discipline myself into using hashtags as a pseudo-category thing at the beginning of my posts here so as to make better use of the featured hashtags feature... if i can keep up doing that

the thing that bothers me though is that i don't particularly want to opt-in to the other behaviors of the hashtag for my public posts. i just want categories like how Google+ Collections worked, but i don't want to make one account per feed/category

of course i might also end up just quitting mastodon entirely depending on how my "online presence reorganization" project pans out. maybe a shim layer that basically acts as a boost bot for compatibility with the mastoverse is not a bad idea. i still need to plot out the architectural diagram regarding fedi back-compat

tangential to this i am thinking about the world if Note never existed and we just used Article to refer to published written works regardless of length/formatting/structure

it's been how many years later and the distinction still feels completely arbitrary and nonsensical and a bad thing to build into your worldview because you can't define it in a way that matters. you need a base model for "content" that you can then further refine, dependent on the consuming profile and use-case

really the ideal consumer here is a consumer that looks for known properties and uses them in the exact same way every single time with clearly defined semantics and behaviors

and fedi is... not that

tangent to the tangent... god i wish fedi devs understood and properly utilized multityping and/or profiles. i wish people realized that something can belong to multiple different sets/types/classes. i wish people realized that the same information can be expressed in multiple different ways or represented in different shapes.

there's an argument to be made that this could/should be baked into the Content-Type somehow, because profiles and classes are really just punting the problem of compat and interop further down the road so thus represent an overcomplication

i mostly agree with this argument, but it is what it is, i guess? the missing bit is a way to declare which Content-Types inherit from which other Content-Types, because you can't easily declare multiple Content-Types. everything expects exactly one type.

some of the newer jsonld-adjacent spec work has this concept of "media type precision" or specificity https://www.w3.org/TR/vc-data-model-2.0/#media-type-precision

basically you can have a resource say it is application/vc but how do you then know that it is also conformant with application/ld+json, and with application/json, arguably also with text/plain and application/octet-stream

you want to avoid a situation where everyone just uses MIME sniffing to guess the type

you also want to avoid everyone hardcoding hierarchies?

in RDF you have a similar issue with classes and properties, being able to declare that something is a subClassOf or subPropertyOf something else. everyone just "knows" that a Note is also an Object, right? this is defined in the spec and can be stated via an rdf schema. no one goes around multityping ["Note", "Object"] because you can infer Object from Note being a subclass

we need something like that, but for MIME/IANA media type, not just rdf:type