Hah, nah, I’m just mean to myself. 😅

Bridgy Fed isn’t a crawler, though. It doesn’t scrape anything, index anything, or store anything. It’s simply a translation layer.

This dude wrote a platform that speaks like four different protocols and translates back and forth between them. You can use it to bridge your Fediverse account to natively talk to people on Bluesky, or Nostr, or IndieWeb.

This podcast episode is a reflection on the guy’s experiences, insights, and thoughts on doing this work. He also weighs in on the weirdness of making not-exactly-compatible systems talk to each other, some of the really weird UX of interop that surprises people, and some thoughts on where the network is going.

Really smart dude, well-spoken, co-founded Google AppEngine back in the day.

I would absolutely love to do this, but haven’t figured it out yet. Part of the challenge is that some of this music is on different websites / storefronts. I might try to build something for this, though.

Wow, nice! Have you thought about submitting your work to Radio Free Fedi? It’s an amazing service, basically operates as an Internet radio stream. All of The Mixtapes are assembled through tracks discovered via RFF.

Sadly, it’s more complicated in the Fediverse, because Actor identities are tied to specific domains. If a user moves accounts, they basically send out an update that says “this profile is dead, follow this new account instead”, and users automatically switch upon receiving it.

There are three problems:

1. If your server goes down before you initiate this switch, the change can’t actually federate out to your followers. You basically have to build up your follower list from ground zero.
2. Mass migration is slow, spammy, and inefficient. If we had thought to incorporate some kind of decentralized identifier and relied on that, rather than @user@domain.tld, switching your account to something else could theoretically be more seamless.
3. Doing this for hundreds or thousands of users is not only a headache, but can be a real strain on servers. It’s one thing when a single person does this switch for 3,000 followers: the update is gradually trickled out across accounts, and after a while, the new account is at parity. Doing this with thousands of accounts with thousands of followers is extremely painful.

It’s technically possible, just really, really hard. One example of a successful migration was the transition from calckey.social to firefish.social. It was a massive, extremely difficult undertaking, though.

A big problem involves how user identities are tied to instances. If there were a way to decouple that, I think a lot of the pain goes away.

Actually, that’s probably my fault, I had to edit the graphic on a phone, and don’t have the steadiest hands.

I’ll fix it when I get home.

Yeah, they didn’t want their money going to the Taliban, and it’s a little shaky as to whether the Taliban’s Ministry of IT would take a stricter content enforcement on their ccTLD. For a while, it was only possible to renew domains, not buy new ones.

Still, I stuck with the title because the Taliban is still the reason.

Trust and Safety tooling, apparently.

I’m happy to improve it, if there’s a problem. What’s wrong with it, exactly?

ActivityPods can be thought of as a framework for building Fediverse apps on top of Solid. Solid itself is a standard developed by Sir Tim Berners-Lee, and once you get through the dry, somewhat brain-melting standards draft, what you get is something that strongly resembles a self-hostable Google Drive.

What makes this unique is that you can make apps that access resources (files) inside of this drive. Even more interesting is that Solid apps don’t rely on traditional databases in the way that regular Fediverse apps do: instead, the apps use files and metadata about those files, and basically parse information from a graph to act as a sort of rudimentary database instead.

What ActivityPods does is bridge the gap: it does all the heavy lifting to translate between Solid’s way of doing things (everything is a file) to ActivityPub’s way of doing things (everything is an activity performed on objects by actors, who have an inbox and outbox).

Why might someone want this? Well, the general idea is that this is a different approach to data ownership, where the data itself is portable as a file. Your Solid Pod acts as an identity provider that proves who you are, as well as a data store where you can decide who has access to read or modify your stuff.

Yeah, they apparently used scrapers for a while, but it’s obviously not a very performant way to do things. Artemis Camp was launched with an upstream branch that introduced API work, and the app was adjusted to use that as a playground.

For all intents and purposes, the dev did state their intentions on releasing the code “when it’s ready”, and was super active in working on it. Not releasing, and relying on one server running a specific upstream branch were definitely mistakes, 100%. But, I think the dev legitimately believed they would hit that target, which was a prerequisite for releasing.