@[email protected] what part of the US are you in? I am assuming somewhere near US Central?

@[email protected] so whatcha doing with your free time now that everything is disrupted (I'm personally just chilling out waiting for the next wave of storms. doing some misc sysadmin stuff)

@[email protected] lol. i woke up this morning 4 minutes before my alarm by my weather radio going "TORNADO WARNING". I was taking a shower when the sirens went off and then I got dressed and ready for work after they stopped. I was then texted "work is closed for the day"

@[email protected] @[email protected] have i ever had a positive conversation in regards to AP or misskey

chat is this real?

#shitpost

@[email protected] @[email protected] there needs to be an activitypub extension to add boop activities

If anyone is curious to try out the cohost "following" timeline that @[email protected] has introduced it's here on transfem.social.

@[email protected] a tumblr post of yours has been screenshotted and posted on Reddit again. https://www.reddit.com/r/196/comments/1gfn3ba/it_was_his_penis_again/

@[email protected] I like when her/their thighs look like a muffin in thigh highs (I just realized you said tights not long socks/thigh highs/stockings…)

@[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=true we'd end up with shit like ed25519_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.

@[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] 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] Sorry I didn't notice this! I can just copy down the email contents verbatim if that'd be better. Wanted to let you know in case you were wondering why nobody was inquiring

@[email protected] Hey just an fyi, I sent an email and it bounced.

We could not deliver the attached mail for the following recipients. [email protected] at remote mailserver smtp.cyber.harvard.edu. (128.103.64.104): SMTPAddressFailedException: 450 4.1.1 <[email protected]>: Recipient address rejected: unverified address: unknown user: "fediverseobservatory" (450)

@[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)

@[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] wonder the likelihood of these being standardized (determining whether it's worth implementing the draft in anticipation)

@[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] 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] 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