instance version numbers are turning into a more batshit insane version of User Agents and I can’t do anything to stop it. When am I going to get
-
@puppygirlhornypost2 "Swear to god" is not a recognized user-agent of any supported ActivityPub software. This might indicate that your client is insecure and unsupported. Please upgraded to a supported ActivityPub with a useragent string we recognize.
-
@[email protected] help they remade user agents in AP implementations
-
@puppygirlhornypost2 oh no
-
@hrefna @puppygirlhornypost2 s/in AP implementations/in Mastodon API implementations/
Because as far as I remember stock Masto API has no feature flags and just has version numbers -
@[email protected] @[email protected] gee if only we had a way to share this information. We should make a page that instances fetch to get the appropriate version number, maintainer contact and more. Hm… what should we name it… info node.. yes.
-
@puppygirlhornypost2 @hrefna @erincandescent there's no way that would work. You would need some kind of well known location to look for it. But how could such a thing even exist?
-
@puppygirlhornypost2 @hrefna @erincandescent there still doesn't really seem to be a "standard" way to specify features in nodeinfo to my knowledge, if there was then i'd probably have attempted to add that ages ago
-
@[email protected] @[email protected] @[email protected] I don't blame you for the mastodon ecosystem. it's mainly the other popular forks that are leaning into this. It'd be nice if all software was bound by adding their relevant extensions to node info. I do not like checks that rely on specific instance software. If akkoma, misskey support quotes and those quotes federate between each other why would i check for specifically misskey or akkoma instances to figure out compatibility? I should just check if the other software has specified in node info they accept that extension... This is how it should have been done from the start with User Agents and while this thread was a lighthearted half joke... I am serious it needs to be figured out before we end up with an even more confusing system than User Agents. Although, that would be more for everyone and not just you in particular
-
@puppygirlhornypost2 @hrefna @erincandescent unfortunately, since it is in fact version numbers not feature flags, that still is kind of a pain because of course people make changes to it that make parsing hard and also mapping version to supported features is A Pain
-
-
@puppygirlhornypost2 @esm @hrefna it’s in both nodeinfo and Mastodon
/v1/api/instance -
@[email protected] @[email protected] @[email protected] OpenZFS actually had a great way around this issue. They set the zpool version number to something absurd (that way it wouldn't conflict with Oracle ZFS) and kept it a constant. Any pool with that specific version number has feature flags that you can query. Perhaps it would make sense to do this to mastodon forks, setting mastodon to a specific version like "mastodon-5000" (the specific number zfs uses lol). Then any instance seeing "mastodon-5000" can go ahead and assume there's an extra attribute in node info
-
@puppygirlhornypost2 @hrefna @erincandescent unfortunately, as you probably already know, compatibility with already deployed software (but really I feel they could just go into a field in nodeinfo, which is always at least queryable. But I am probably not the right person to design that type thing)
-
@[email protected] @[email protected] @[email protected] it is compatible with existing deployments. You can check for if the instance version number is "mastodon-5000" and if so query for feature flags, or if you see an existing mastodon version number you can parse it for features. That's why I recommended following ZFS' lead (they used this to upgrade pools iirc)
-
@[email protected] @[email protected] @[email protected] @[email protected] why are all the coolest feps the ones that just stagnate and aren't widely known
-
@[email protected] @[email protected] @[email protected] @[email protected] wonder the likelihood of these being standardized (determining whether it's worth implementing the draft in anticipation)
-
@[email protected] we could implement some of that in Sharkey (allocating the Misskey features as well, then getting them to merge)… not before 2024.11, though
@[email protected] @[email protected] @[email protected] -
@[email protected] @[email protected] @[email protected] @[email protected] https://codeberg.org/fediverse/fep/src/branch/main/fep/9fde/fep-9fde.md im biased towards this one because it's more akin to ZFS. https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Feature%20Flags.html I think it's clarified a lot more (telling people not to include things like character limits). I would be interested in this draft in particular, and yeah I don't think it's feasible to add it right now but it is something we could work towards.
-
@[email protected] @[email protected] @[email protected] @[email protected] I like the semvar as well
"org.joinmastodon.api.some.operation": ["1.0.0", "1.1.0", "1.2.0", "2.0.0"]directly from that FEP because it means in case of breaking API changes you can specify a list of supported versions for clients to utilize. Much akin to how OpenSSH does cryptographic cipher negotiations... (say I have something like post create abstracted for various old and new versions of the api... this would be very helpful as a library developer)
