FoxQuirk 🦊 @quirk@computerfairi.es

I have suspiciously good internet on this train ride

Am I on one of these trains where PKP with ISPs installed signal repeaters

Little tape robot friend files LTO tapes: https://www.youtube.com/watch?v=q5TCb-kArEE

"Hetzner doesn't allow porn"

​​ what

Some folks have speculated that we may have added some logic to #GoToSocial to refuse federation with threads, since GtS and Threads cannot federate together. We have not! We may in the future set federation with threads.net to "off" by default, and have this setting be adjustable by admins (with a link to Threads ToS for third-party services), but we haven't done anything like this yet.

It seems that as of the moment of writing, Threads responds to requests for ActivityPub representations -- requests which work just fine for all the fedi softwares we know about -- with a huge chunk of html+CSS. Of course GoToSocial doesn't parse this response as JSON, and therefore lookup of Threads users from GoToSocial fails. Likely Threads is requiring something very fussy with its Accept headers, or there's some other small issue preventing Threads from understanding GtS's outgoing HTTP requests. We haven't investigated it yet, because frankly getting federation working with Threads is not at all a priority for us.

Apparently some other fedi server devs have already implemented workarounds on their side for this issue, which brings up a rather tricky point: Is it the responsibility of open source fedi server developers to implement workarounds for Threads? In other words, is it for fedi devs to debug Threads' black-box implementation of ActivityPub for them, when Threads is closed source, for-profit, and not free?

Personally I would say no, it's not our responsibility, since Meta is an enormously large company with paid engineers working on this. In my view, if their implementation does not work with existing ActivityPub implementations (which mostly work fine with one another in this ecosystem we've created), it is their responsibility to fix their implementation, not ours.

At GoToSocial we work really hard to debug and fix compatibility issues with other open source fedi projects, within a reasonable scope and to the best of our abilities. Where the protocol is unclear (and AP is a protocol which is notoriously open to different interpretations), we try to err on the side of being generous in what we accept, and strict in what we send out, and to provide reasonable fallback behavior. We spend a lot of time poring through the code of other implementations, checking logs, trying to narrow down issues, etc. We would expect Threads to do the same.

This brings up another point: When this sort of thing happens (some federation bug or other issue), who do people assume is at fault? In other words, who wrote the bug: the big corporation, or the open source developers?

The power dynamics here are interesting. Based on my purely anecdotal (!) experience of seeing comments on such matters over the years, people tend to assume that developers at big corporations write code with fewer bugs than independent open source devs, and that corporate code is more reliable and more "technically correct". For better or worse, they seem to tend to view open source developers as being more amateurish and slapdash, and corporate developers as being more disciplined and by-the-book.

In a case like this, where open source implementations of a protocol are federating with a corporate implementation of a protocol, it seems likely to me that folks will generally assume that the "amateurish" open source developers are at fault if something does not work properly. If Threads, owned by Meta/Facebook puts something out there, it must be correct, right?

So already the burden of fixing things may fall disproportionately on the open source devs; and already even at this very early stage, we can get a feeling for the sort of weight that big corporations have to throw around, when it comes to interoperability matters. They have the money, the PR, the personnel, the reputation, all that stuff, and folks will tend to assume that they're in the right, without really interrogating that assumption for truth.

This is sort of worrying, and I don't really have a neat way to tie up this long post. I suppose I would caution folks against assuming that code produced by corporations is automatically more correct than code written by small independent groups. And I'd also caution folks to be aware of the power imbalances that are entering play here. It's not going to be an easy time for fedi devs.

Lesbiab

People get wrapped up over the silliest things and call it “opsec” but here’s an actual opsec tip a lot of people slip up on

are you covering a mailing address on an envelope for a photo? are there any barcodes of any kind anywhere on the envelope? (hint: yes, there are.) QR codes are a barcode. faint small tick marks are a barcode. fluorescent tick marks that seem invisible in the photo are a bar code. and the bar code IS the destination.

funk drummers in the 60s and 70s playing unaccompanied for 2 to 4 measures: This is so cool. Sampling will never be invented

Please like and share this post.

finally, some honest messaging

Best moment in a train is when you go parallel to the road and overtake all cars immediately

a couple people said they wanted to wait to purchase my games until after the sales were done, so this is your reminder that my games are now once again full price

itch.io: https://eniko.itch.io/
steam: https://store.steampowered.com/bundle/15673/Kitsune_Games_Complete_Pack/

so I know plain NaaN, cheese NaaN, garlic NaaN, what are the other 16,777,211 for?

nowadays you want to change like, i don't know, the size of your icons on your desktop and you have to fight against 10 different conf files ones less documented than the other

As Easter gets closer, please remember and spread the words that lilies are DEADLY for cats. "The entire lily plant is toxic: the stem, leaves, flowers, pollen, and even the water in a vase. Eating just a small amount of a leaf or flower petal, licking a few pollen grains off its fur while grooming, or drinking the water from the vase can cause your cat to develop fatal kidney failure in less than 3 days." https://www.fda.gov/animal-veterinary/animal-health-literacy/lovely-lilies-and-curious-cats-dangerous-combination#:~:text=The%20entire%20lily%20plant%20is,in%20less%20than%203%20days.