@dansup We're stronger together, Dan. It's not worth throwing stones.
-
@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.networkplus 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 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)
-
@quillmatiq @evan @dansup I have been thinking about trying to do some sort of protocol bridging with my project Fedi+ but then that runs the risk of people like FediTips getting on the wrong side of things being like oh Fedi+ interacts with fashists or whatever all because of the protocol being associated with Bluesky, which verified ICE and other US government accounts, and so on. My goal with Fedi+ is to not only create that vibe people loved when Google+ was around, but also to make it super easy for people who don't care about Mastodon or ActivityPub or whatever to join on and not even need to think about the protocols behind the scenes.
@alexchapman @quillmatiq @evan @dansup
Have you looked at WAFRN for inspiration on the dual protocol side of things
-
@alexchapman @quillmatiq @evan @dansup
Have you looked at WAFRN for inspiration on the dual protocol side of things
@gbargoud @quillmatiq @evan @dansup Ye they do something where you enable the integration and it sets up some sort of additional account thing, kinda complex.
-
@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.
@thisismissem @mastodonmigration @cwebber Side tangent: if you build your own app that uses a different Lexicon than Bluesky, can you still interoperate with BlueSky users? Because for many, the desire is to have things operate like the Fediverse, where (for one example) a post on Loops can be seen in the home timeline for a Mastodon user, et al.
-
@thisismissem @mastodonmigration @cwebber Side tangent: if you build your own app that uses a different Lexicon than Bluesky, can you still interoperate with BlueSky users? Because for many, the desire is to have things operate like the Fediverse, where (for one example) a post on Loops can be seen in the home timeline for a Mastodon user, et al.
@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)
@thisismissem @baralheia @cwebber
Really appreciate you engaging in this discussion. Will take some time to reflect on what you are saying and try to frame it in generic network model language along the lines of what Christine has put forward.
For this purpose propose we agree that independent nodes be defined as fully autonomous, capable of operating on the network independent of all other components and interacting with all users of on the network (except the PLC directory).
Again, thanks.
-
@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.
@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.
-
@thisismissem @baralheia @cwebber
Really appreciate you engaging in this discussion. Will take some time to reflect on what you are saying and try to frame it in generic network model language along the lines of what Christine has put forward.
For this purpose propose we agree that independent nodes be defined as fully autonomous, capable of operating on the network independent of all other components and interacting with all users of on the network (except the PLC directory).
Again, thanks.
@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.
-
@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.
@thisismissem @baralheia @cwebber
Well, understand there may be advantages to separating components. However, the entire marketing premise of network 'decentralization' is grounded in the idea of independence of the network nodes. If this is no longer the key design objective, then we really aren't talking about a decentralized network. It sounds fine to say elements share burden and work together, but what happens when a dependent element decides not to cooperate? Isn't this the whole point?
-
@thisismissem @baralheia @cwebber
Well, understand there may be advantages to separating components. However, the entire marketing premise of network 'decentralization' is grounded in the idea of independence of the network nodes. If this is no longer the key design objective, then we really aren't talking about a decentralized network. It sounds fine to say elements share burden and work together, but what happens when a dependent element decides not to cooperate? Isn't this the whole point?
@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 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 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 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 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.
Seems like we are losing focus here. If the model is one principly centralized platform where satellites offload and contribute resources many interesting things are possible, and it may be a more fun and interesting development environment, but it is still dependent on the centralized platform.
Real decentralization is hard, but the advantage is true node independence. If real decentralization is not the operative model, then it should not be the marketing slogan.
-
@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)
Short answer is yes. Decentralization has nothing to do with keeping some universal identifier or address. In fact, keeping a universal handle is kind of a centralized concept since some central authority must adjudicate the name.
-
@mastodonmigration @baralheia @cwebber no, I mean, processing 2.4 billion posts, 3.4 billion follows, and 13.6 billion likes is a metric shittone of data to process. Serving up feeds to 42 million users (10-15 million monthly active) requires a lot of processing.
Stats from: https://bsky.jazco.dev/stats
It's not even talking about communication at a network layer between PDSes, Relays, and AppViews. That's a different matter, which is where Christine was mostly talking, iirc.
@thisismissem I'm sorry, where is the MAU from? I don't see it on the page you linked to.
https://bluefacts.app/bluesky-user-growth reports 5.36M (excluding users who don't interact with posts).
-
@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)
Want to thank you again for having this discussion. Fully recognize that what AT Proto folks prioritize in network architecture are not the same capabilities that ActivityPub boosters prioritize, and that it is frustrating to have this conversation here. Feel like we did make progress in clarifying and kind of agreeing about some of the respective characteristics of each protocol.
-
Seems like we are losing focus here. If the model is one principly centralized platform where satellites offload and contribute resources many interesting things are possible, and it may be a more fun and interesting development environment, but it is still dependent on the centralized platform.
Real decentralization is hard, but the advantage is true node independence. If real decentralization is not the operative model, then it should not be the marketing slogan.
@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.
-
@thisismissem I'm sorry, where is the MAU from? I don't see it on the page you linked to.
https://bluefacts.app/bluesky-user-growth reports 5.36M (excluding users who don't interact with posts).
@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.
Fair enough. Would just add that a key characteristic of a protocol is the 'cost' of 'running everything by yourself.' If that cost is very high then there is a significant barrier to real in practice decentralization. Alternately, network protocols with a lower independent node cost will achieve effective decentralization more rapidly and with greater distribution.
-
Want to thank you again for having this discussion. Fully recognize that what AT Proto folks prioritize in network architecture are not the same capabilities that ActivityPub boosters prioritize, and that it is frustrating to have this conversation here. Feel like we did make progress in clarifying and kind of agreeing about some of the respective characteristics of each protocol.
@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.