Leveraging ATProto and ActivityPub to upend enclosed social networks
Leveraging ATProto and ActivityPub to upend enclosed social networks
Despite understandable misgivings with ATProto due to its corporate origins and its architecture lending itself to centralization, it's still open source. Moreover, it serves a different purpose compared to ActivityPub, in that it specifically aims to enable and support larger scale social networks.
In a way, ATProto could be complementary to ActivityPub, but for this to be the case, there needs to be more shared understanding between both communities. People working on both recognize the faults in existing social media, and aim to address them in different ways.
ATProto provides an opportunity to break down big social media enclosures with data portability and a similar vibe to big social media, but with more individual empowerment to adjust what they see. The latter point is a commonality with ActivityPub, but ActivityPub provides a different angle of breaking the big social media enclosures.
Where ATProto serves the interests of those into big social media vibes, ActivityPub serves the interests of those into small social media vibes. In other words, ATProto scales up, where ActivityPub scales down.
ActivityPub is arguably a better protocol for both individual and "small" group empowerment, as it can enable otherwise less active, small platforms to connect and ensure there's always some level of activity to encourage people to come back. Think of old forums that, on their own, gradually faded out as people stopped visiting and posting for more active online communities. ActivityPub can serve as a buffer against that, to some degree.
Together, both protocols could provide a better, open social web, and perhaps effectively topple big social media enclosures. After all, who wouldn't like to see the web without Meta/Facebook and Twitter/X?
TL;DR: ATProto/ActivityPub have a common foe in big social media enclosures like Meta/Facebook and Twitter/X and would be better served working together to erode their influence.
I'd rather that ATProto was just compatible with activitypub to begin with, or allowed for meaningful federation.
The ability to scale up into a behemoth like twitter will only be viable for a minority of people who can afford the infrastructure to do so, and with that level of centralization comes a certain level of control and allowable viewpoints. Not the worst thing if the people running it are good folk, but that's always reliant on luck, and your chances to roll a good team lessen dramatically with such a small pool of servers. Not to mention the inherent problem of adequate moderation on mega servers, where the ratio of mods/admins to users can quickly become overwhelming, especially if reliant on volunteers who don't like the feeling of just being a cog in a greater machine.
ActivityPub, on the other hand, allows for anyone to host an instance with an old laptop, while still having access to the big picture.
The argument should not be to tolerate ATProto since it's easier to use, it should be to rile up support to make Activitypub's interconnections so intuitive and smooth to use by default, that it can easily offer those 'big social media vibes' to those who want it.
The potential social benefits of truly federated, Citizen Owned media cannot be overstated.
I'd rather that ATProto was just compatible with activitypub to begin with, or allowed for meaningful federation.
Bluesky structure is too different from Mastodon instance to have a direct link. Brid.gy is the link between the 2 networks. Isn't is enough already for federation ? From the AP side, it's just a mastodon instance. However by default it's not open to everyone, Bluesky users and Mastodon user first need to opt-in to be able to interact.
Ideally they would be compatible, I agree.
Also you're right regarding the capacity to scale up, and frankly, while ATProto makes it feasible, I don't think it's necessarily desirable even with ATProto. Part of the point of it is to have various independent relays that would better distribute the load, and enable people's mobility when any of them go bad. Setting that aside, they don't all have to be full network relays, in fact someone is already toying with running a small network relay.
I also agree regarding moderation problems at a larger scale, and that ActivityPub's various software should take this as a wake-up call to improve the user experience, not so much for "big social media vibes" but for a better, less finicky experience.
However I also think there are potential benefits to ATProto, which blended together with ActivityPub, could make both better overall. The technical literacy and insistence on independent servers of the ActivityPub culture could make ATProto properly distributed and federated, which would be far better than letting it languish in corporate hands. Meanwhile the openness to optional transparent, customizable algorithms and preference for a smoother user experience of the ATProto/Bsky culture could make ActivityPub a more accessible, and livelier feeling space for more people.
Both can improve from one another, so long as both communities choose to try to learn from one another.
The minute that the community is able to meaningfully rest control of ATProto away from bluesky and host fully independent servers that can intercommunicate, I no longer have beef with it. if it can be made too work with activitypub later and they can learn from each other and improve, I'm all for it.
the hesitation at the moment is that first step may not be achieved, from what I understand.
ATProto exists because of ActivityPub's shortcomings for building Twitter 2.0. The protocol is much better suited for massive websites, and the "run your own data store but let someone else do the content tagging and filtering" approach is actually not a bad idea. The Bluesky firehose throughput is massive and any home ActivityPub instance that tried to enter the network would easily be overwhelmed just loading the basic home page feed. The Bluesky servers probably wouldn't enjoy the endless connections back home to verify the key material either.
Plus, many ActivityPub folks don't want to federate with big companies anyway. Threads is blocked by most small servers. A bridging service intended for allowing ATProto/ActivityPub cross communication was the center point of drama as well and had to go opt-in (and instantly became useless as a way to connect the two networks because nobody knows about the service anyway).
I don't think ActivityPub is made for large servers, and I don't think the protocol can be patched to support them well without upsetting a lot of people. AP works well for following friends and family, it's kind of terrible for the tailored topic based social media feed most people want out of social media apps these days.
many ActivityPub folks don’t want to federate with big companies anyway
This really shouldn't be a consideration. ActivityPub is a public standard for this kind of communication between websites, and the protocol really needs to be agnostic about which websites one is interested in using it to connect with. "I don't want Amazon using HTTP along side my indie blog" is a nonsensical statement, and so it "I don't want Facebook using ActivityPub".
The Bluesky firehose throughput is massive and any home ActivityPub instance that tried to enter the network would easily be overwhelmed just loading the basic home page feed.
AKAIK, activitypub (on mastodon) only requests and receives content from individual users that have been followed by someone on the local instance, it wouldn't load all of bluesky at once, it would just need to have an up to date database of bluesky's users so they are easily searchable. With that model, even crappy PC's can interact with the mega servers.
Plus, many ActivityPub folks don't want to federate with big companies anyway.
With the OP's point of ATProto being open-source, I assume the thrust of the argument is that at done point there would be a community hosted instance, which were it compatible, I think most activitypub se rvers would gladly federate with.
I don't think ActivityPub is made for large servers
Ideally there doesn't need to be any, as the conglomeration of all smaller instances should be able to act as a large server. Unfortunately as it currently stands, the UI of most fediverse software makes interacting with that wider pool more difficult than it needs to be, and thus punishes smaller Mastodon servers with more difficult discovery of interesting topics or people to follow. But I think that can be overcome simply with better UI design.
AP works well for following friends and family, it's kind of terrible for the tailored topic based social media feed most people want out of social media apps these days.
Again, I think that's a UI problem. I don't use mastodon myself because of it, as I find it difficult to find people that interest me. However, Lemmy's use of Topics, and more critically, the existence of Lemmyverse.net which searches across all instances, make finding interesting things possible regardless of the size of your home instance. It's criminal that that functionality is not a native feature in the standard lemmy Ui, and I'm not aware of anything similar for mastodon.
Why cant Activpub scale up? The only issues so far are big instances can sometimes overload smaller instances.
Atproto has a personel data store allowing universal accounts but their is work to implement this into activpub.
So whats the advantage of atproto? Atproto has arguably hurt a federated future more than anything else.
Boobam, a japanese blogger did a report / comparison of Bluesky with Mastodon. One of his conclusion on Mastodon, is that it can't grow too much, by design. The more Mastodon traffic grows, the slower is gets and smaller instances will be overwhelmed. Now, there is no defined limit from when Mastodon will slow down so much it will be unnusuable. You can use your favorite translator to read the page: https://whtwnd.com/boobam.bsky.social/3l5uqcwjawe2e
It's not so much that ActivityPub can't scale up, so much as that for one, as I've understood it that's not really been desirable anyway (undermines the point of decentralization/distribution), and for two, it starts getting bogged down as you already recognize. It also runs into similar, if not worse, cost problems to operate as ATProto's full network approaches are now.
ActivityPub is more suited to scaling across multiple instances/sites than up, and I'd argue that's its strength. It unintentionally has an implosion threshold to counter centralization in terms of cost and performance.
On the other hand, ATProto's advantage is that it enables scaling up while also enabling better data portability. I'm aware of work on this with ActivityPub as well, but it's still very early stages. My thinking is that there may be some ways to work with both to push towards their similar shared aims in terms of an open social web, with more flexibility in moving between spaces and adjusting experiences to better find what one wants from these different spaces.
I think you need to be more careful with your use of "scaling up". You mean vertical scaling, while ActivityPub is good in horizontal scaling.
Indeed, with ActivityPub you will probably never have a single point that has a global view of the network, which (at least for now) is the way ATProto presents the network. Arguably that is not a desirable feature anyways, but lets just say that people have different opinions on that.