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
-
Jenniferplusplusreplied to Pumpkin Amber last edited by
@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?
-
Essem :skeeter:replied to Pumpkin Amber last edited by
@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
-
Pumpkin Amberreplied to Essem :skeeter: last edited by
@[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
-
halcy:icosahedron:replied to Pumpkin Amber last edited by
@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 -
Pumpkin Amberreplied to halcy:icosahedron: last edited by
@[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
-
halcy:icosahedron:replied to Pumpkin Amber last edited by
@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)
-
Pumpkin Amberreplied to halcy:icosahedron: last edited by
@[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) -
Really I think that the OpenSSH cipher negotiations—or a few equivalents along the lines of what you describe—are a quite good model for this sort of problem. It allows for a robust negotiation with options and fallbacks and without requiring dependency graph management.
It's also antithetical to how AP wants these things to be managed, but I personally view that as a feature, not a bug.
-
@[email protected] @[email protected] @[email protected] @[email protected] it literally feels like AP tries to shoot itself in the foot everywhere and stop itself from being a mature protocol. I would be fine with the quirkiness of you can represent something in 1,000+ ways... if i could have negotiation between software on how we represent something. Of course that isn't perfect compared to laying down how things need to be represented (actually standardizing something like a post, what sort of activities should be sent on post creation/deletion/modification - what the fuck is a TentativeAccept) but if we could have a way to specify which notation we want to use... that'd be good enough for me. Of course no, because fuck all of us right
-
@[email protected] @[email protected] @[email protected] @[email protected] god as much as people shit on X11 (and implementations like Xorg) at least they have a good fucking way of doing this in which both the X Server and the X Client negotiate the X extensions both support. And sure, right that's not the only thing here. Really you want to have it to where MINIMUM feature sets are available, anyone not supporting things like authorized fetch are kicked out... or removal of older versions (to prevent a downgrade style attack). It still goes a hell of a long way in comparison to gestures vaguely this mess.
-
@[email protected] @[email protected] @[email protected] @[email protected] I heard someone discussing the possibility of replacing the signing key used with ED25519 (I don't remember why, I know it wasn't about the key being inherently better but just as PROOF we can have widespread adopted change in the protocol). Being able to reject instances still using the previous key would be a crucial part of any "extension negotiation" related FEP (see semver as a way to determine this, because if we kept it as
signed_activity=truewe'd end up with shit likeed25519_signed_activity=true; signed_activity=false. Sometimes standards can feel out of place when there's no implementation backing it. Providing examples of things that we can use to quantify the need for such a thing... even if they don't exist outside of a proof of concept... It's how a lot of other committees work. I don't get why AP and AS are like this... it breaks my head. -
It goes back to several of the baseline assumptions in RDF along with some of, IMO, the early decisions that were then later very difficult to unwind around what things like "follow your nose" and "open world assumption" mean.
