@baralheia @mastodonmigration I'm super experienced with AT Protocol, ActivityPub, AND Solid.

What you as a nerd are looking for from social media software is likely very different to the majority of folks out there. AT Protocol is designed to allow a path away from Bluesky PBC, but it doesn't force you to take that path *yet*.

Just because a big beefy AppView like Bluesky is the main way folks interact with the network for microblogging, it doesn't mean it's the only way.

You could totally spin up all the tech reddwarf uses and still interact with the network. In fact, I was just chatting the other day with the guy behind Microcosm about spinning up some of those services myself, and he was like "oh, yeah, totally doable". Spinning up a relay and microcosm is totally doable.

So like, the point about you just wanting to connect with your friends, that's totally valid, and like, for that you don't necessarily need a global view of the entire network. But for other things you do possibly want that (discovery, search, trends, etc).

Everyone has different ways they use social media, for some folks, the Fediverse with it's individual servers and how it works, will work better for them. For other folks, AT Protocol and full global views of the entire network will work better for how they interact with social media/networking.

That's why the very start of this thread started with a "We're stronger together" comment. Neither ActivityPub nor AT Protocol alone is going to be the best for all people, because people have different requirements and desires.

If Dan didn't throw stones at AT Protocol, and say, jumped on a call with the folks behind Skylight.social and Sprk.so (both of whom have a tiktok like experience), maybe they'd find common ground and like bridge the content and that'd be a benefit to *both* platforms.

Dividing people is easy. Uniting them and fostering collaboration is hard.

@skarnio @mastodonmigration @baralheia as someone *actively* developing on AT Protocol, I can tell you that Bluesky PBC could disappear tomorrow, and we'd just work around it. There's complete mirrors of the did:plc directory, and we'd just pick one to replace the existing directory. Sure, it'd be hugely disruptive, but life would go on. We would work around it.

There's alternative relays, hostile migration of PDSes is possible, and changing the plc directory is possible. Blacksky probably couldn't handle all of Bluesky's users suddenly all using it, because they're still new, but *shrug* life would go on.

@cy @mastodonmigration @baralheia true there's not a central webfinger server one must finger. But that comes with a trade-off that your identity is permanently tied to your server.

That's why account migration is lossy and why you need to create a new account just to change your handle.

If you don't do webfinger as an ActivityPub software implementer today, you'll have a hard time interoperating with the rest of the network who expect webfinger, because back in the distant past Mastodon decided webfinger was the technology to use. In fairness, DIDs didn't exist yet, only some of their nascent ideas did (that's where alsoKnownAs comes from in AP)

There's a thread somewhere here that was like "ActivityPub was never designed to have usernames or handles or anything like that, just actor ID URIs"

Microblogging doesn't really work if you can't @mention someone, as far as most people are concerned.

Also, you don't *need* DID PLC to do AT Protocol, you can totally use did:web, it just has a trade off like that of using webfinger: your identity becomes tied to a domain name.

Here's how you do did:web: https://whtwnd.com/bnewbold.net/3mdc7fpbxhk26

It's pretty manual because it's a pretty technical way to do things. Some PDS implementations may do did:web by default, but that article is covering the reference pds implementation, that doesn't focus on did:web

@cy @mastodonmigration @baralheia you have no idea how close to a sell out that almost happened we came, and how it would've affected a significant portion of the fediverse.

They hid that from you.

AT Protocol does and will function without a central authority. Sure, we all use did:plc for identity pretty much, because it's a good trade-off for most people. But did:web is also supported, and the working group at IETF specifically is chartered to allow new DID methods to become part of the network.

Can you use ActivityPub without Webfinger support? That's something Mastodon forced on the network, and everyone else had to adopt if they wanted to federate with Mastodon.

(Hint: you can't choose *not* to do Webfinger with ActivityPub, because you won't be able to interoperate with most of the network which requires webfinger).

Edit: Also, Dan posts almost too frequently about *not* selling out, which is mildly disconcerting.

@baralheia @mastodonmigration that's the thing: we're comparing apples to oranges.

Yes, it is expensive and complicated to run an entire appview for 42 million users and process billions of records/events. Just like it's expensive to run hachyderm or mastodon.social (granted they're perhaps cheaper because they're a hundredth the size)

You're comparing your mastodon server which does a slice of a pie, with a bluesky appview that does the entire fucking pie, where your slice is less than 10% of the network.

Of course that is different. Anyone can see that's different, I would hope.

Like I've repeatedly said: you can run the whole pie if you want to, but you don't need to, and in fact, some people have decided that they want to, like Blacksky, and Eurosky (but they're not there yet)

The number of relays can always grow. The number of PDSes can always grow. Same with the number of independent app views. I have my own appview, but it doesn't do microblogging or bluesky stuff, because that's not what my app is about.

When 43k+ servers are 71.1% Mastodon and 11% Pixelfed (by active accounts), or ~30% each Wordpress and Ghost and 20% Mastodon by number of servers, are you really in full control? Sure, you can operate the software, but is that really "control"?

The "control" we say we have only makes us "feel good", if mastodon.social decided to defederate from you, would your Mastodon experience be the same? (you wouldn't have been able to see a significant part of this conversation, since they run mastodon.online too)

AT Protocol can scale down too: https://bsky.bad-example.com/can-atproto-scale-down/

The components of AT Protocol are cheap to run, PDSes and Relays both run on commodity hardware. It's the full-network aware AppView that is a specialized piece of software, but even without that you can still interact with the network, see Red Dwarf: https://reddwarf.app/

I guarantee you there are way more people hacking with AT Protocol than ActivityPub-based systems. The Mastodon codebase is a beast to understand fully, and I say that as someone who has been a regular contributor (100+ pull requests merged)

@mastodonmigration @baralheia right, like, for instance, the IETF where protocol development is moving to, as we're in the final stages of setting up a working group there: https://datatracker.ietf.org/wg/atp/about/

There's plenty of people building in the protocol who don't use anything related to Bluesky (none of their code, alternative relays, etc).

Bluesky PBC has designed the protocol and its layers to prevent Bluesky PBC from asserting anything over the whole network.

Though, Mastodon, whew, they asserted webfinger on everyone in ActivityPub.

@mastodonmigration @baralheia well, like I said before, no one has to run an AppView for 42 million people. It's a choice. There's a way to interact with the protocol and be social without needing to do that. Konbini, Red dwarf, etc all provide alternatives.

@mastodonmigration @baralheia the root argument here is that none of us are actually fighting each other, as Bluesky grows, so does the fediverse. We're fighting the big tech companies like Meta, Google and TikTok.

Fighting which decentralisation or social protocol is better doesn't serve anyone on any protocol. It just strokes egos and makes tribalism feel good.

I regularly see posts on the fediverse that are trying to fight AT Protocol. I never see the same from the AT Protocol developer community back at ActivityPub: we've recognised that fight is frankly not serving anyone.

People don't care about protocols. Ain't no one going "ewww, you use IMAP? That's so lame, you should use JMAP" because no one cares. They care about what features their email app has and if it sends emails and receives them. Maybe they care about data being hosted in EU vs US, maybe.

@stefan it comes from @laurenshof.

@mastodonmigration @baralheia AT Protocol is decentralised in that you can run the parts yourself, if you *really* want to, but you don't *need* to.

Needing to run everything yourself has a massive cost associated with it, and relies on a tonne of volunteer labour to provide infrastructure, moderation, etc.

Just because we *choose* to share resources, does not make it centralised. We can also *choose* to not share resources, which is what Blacksky has done for microblogging on AT Protocol. They have features Bluesky doesn't have. They run completely independently at all levels of infrastructure*.

There is an * here, because they are currently choosing to consume the Bluesky Moderation Service's data alongside with their own moderation service, because that provides significant value to them at this time (I'm assuming that's the reason)

Decentralisation doesn't mean I need to host everything myself. It means I can if I want to.

We'd all say Email is a pretty decentralised network, even though majority of people are with like four different dominant providers. ActivityPub is generally equated to email in a lot of explanations.

"Real decentralisation" isn't a thing people – normal people – want nor care about. They want better social apps that don't lock them in. They don't care about servers, federation, message passing, blah blah blah.

Sure, you can focus on "how hard is it to run the entire network by yourself on a raspberry pi" and for majority of people that is impossible. Sure, they could learn, but it's just not something that they *want* to learn typically.

@mastodonmigration @baralheia Is it really decentralized if, for most people, their identity (i.e., handle) is tied to a domain that they don't control (because they don't want to operate social apps, they just want to use them), and migrating from one provider to another looses all their data apart from their follow graph (which still looses some data)

(sure, LOLA might help with this, maybe, but it's just a technical demo right now)

@mastodonmigration @baralheia if an independent element decides to not cooperate, you just route around. Sure, you may have a temporary outage, but it's manageable.

For example, a popular labeler for pronouns on bluesky went offline the other day. Within 24 hours, Blacksky had shipped native pronouns support within their social app.

@mastodonmigration @baralheia decentralized *where* and *how*

Is ActivityPub really decentralized when everyone builds for compatibility with Mastodon (apart from Lemmy) or is it only decentralized in operations? Where mastodon.social accounts for a significant portion of the network? What about Pixelfed? How much decentralization there? Loops? I think there's only really one maybe two loops servers of any size?

Decentralization doesn't mean "run absolutely everything myself", I mean, sure, you *could* but that's expensive, complicated, and time consuming. Moderation? Most servers just import some blocklist snapshot at a given point in time.

Thing is, decentralization isn't the goal, the goal is better social apps.

Decentralization focuses on technology, not people. It's the "how" not the "why" and "for who"

@mastodonmigration @baralheia @cwebber well, that's the thing: the network topology does not match that.

Sure, I could run a relay and an appview and a PDS if I really wanted to, but I don't *need* to.

That's where folks are stumbling because they think they *need* to run the entire network topology or stack, which just doesn't make a whole lot of sense for individuals to do.

Instead we pool resources and work together. It's kinda like how there's been the ideas in the ActivityPub ecosystem for ages for a shared media CDN and a shared link resolver for link previews, and even shared moderation infrastructure.

Running everything gets complicated and expensive as the network grows, whether that's AT Protocol or ActivityPub.

@baralheia @mastodonmigration like, say I publish a song on Bandwagon, maybe I publish it with album art, I include the track listing, the credits for songwriting, production, etc. Maybe I also include the lyrics for each track.

If Bandwagon cross-posts that to Mastodon, or wants to publish an activity in a form that Mastodon understands, then that data obviously can't all be sent to Mastodon, so instead you post something like:

> Introducing our new album “Music for the soul“ available now on our bandwagon: https://...

And that's actually perfectly fine. In fact, the anti-pattern in ActivityPub is the reduction of literally everything to a Note, just to be compatible with Mastodon.

Like, you'd expect Loops to publish a Video object, but no, it publishes a Note: https://blog.joinloops.org/loops-joins-the-fediverse/#:~:text=Smart%20Content%20Representation

This is an anti-pattern that's been repeated across the fediverse ad-infinitum, and reduces all our content to what can be represented in a Note, which is designed for microblogging.

@baralheia @mastodonmigration @cwebber you'd need to write a record in your own lexicon and then write a cross-post record in the Bluesky lexicon, for the post to show up on bluesky feeds.

For instance, I wrote a review on popfeed.social: https://popfeed.social/review/at:/did:plc:5w4eqcxzw5jv5qfnmzxcakfy/social.popfeed.feed.review/3mezfspxcbk2j

And when I did that, I opted to cross-post to bluesky: https://bsky.app/profile/thisismissem.social/post/3mezfv3ydp22j

However, such a conversion is inherently lossy. This is true for ActivityPub as well.

You can also write an application that uses the bluesky social graph whilst writing records to your own lexicon without doing bluesky posts.

Or you can have your own social graph. Maybe instead of following people (actors in AP) you're actually following topics, or hashtags, or a website. The AP concept of "following" is limited to following an Actor, which is something that can send and receive activities, where as on AT Protocol, "following" is an application concern where you work with links between data.

@mastodonmigration @baralheia @cwebber on activitypub, if I have 30,000 followers (1 follower per server), and I want to post a message, my server has to send out 30,000 messages.

In AT Protocol, if I want to do the same write operation, I send one http request to my PDS, the PDS then publishes that message to N connected relays (where N =< 12)

@mastodonmigration @baralheia @cwebber in Christine's article (and I've just spoken with her about it), it assumes a network topology that does not exist in the real world.

It assumes that every user is on a different pds, and every user runs a full network relay. The reality is that multiple users are usually on a single PDS, and there's only like 12 relays.

- 2 from bluesky (+ 1 deprecated)
- 2 from hose.cam
- 1 from blacksky
- 1 from upcloud
- 3 from firehose.network

plus a few more from various people.

In the ActivityPub ecosystem for every user to message every other user, you need connections between 30,000 servers.

For the same in AT Protocol, you need connections between N PDS to one or more relays (most use the bluesky relay, which others get their list of PDSes from).

@mastodonmigration @baralheia @cwebber right, so on the ingest side, if you want to build an application that is ingesting all the data from bluesky, then you'd be asking the relay for all records targeting the app.bsky.* NSID and all events about repositories that contain the app.bsky.actor.profile record.

That's 42 million accounts across however many PDSes.

That's specifically for an AppView where you *want* a full network copy of all microblogging data. That's obviously going to be expensive.

You can also build a system where you say "Actually, only give me data from these accounts" (partial network copy). Konbini is one such project: https://github.com/whyrusleeping/konbini

Doll's Aurora Prism is another project in this space: https://github.com/dollspace-gay/Aurora-Prism

If I build an app with my own lexicon, I don't need to process all that bluesky data. I process only the data for accounts using my application.

@mastodonmigration @baralheia @cwebber An AppView typically consumes data from a single full-network relay, with failover. A PDS typically has subscriptions from 1 or more relays for data. There are also some relays that just consume other relays.

Adding more PDSes means more connections for relays, adding more relays means more subscriptions to individual PDSes for data.

There's like, a dozen or so relays operating in full-network mode, as far as I know, and relays don't do archival anymore, which was the largest cost.