@dansup We're stronger together, Dan. It's not worth throwing stones.
-
@alexchapman @quillmatiq @evan @dansup it happened to @HolosSocial just a week ago, that made me very sad, that the angry loud voices won.
@alexchapman @quillmatiq @evan @dansup @HolosSocial
and it has implications on innovation.
We/I could build a LinkedIn (when LinkedIn was good) version for the fediverse.
A nice professional UI fediverse-client that shows indexed #jobs posts, adding @badgefed / certifications celebrations, and some #lemmy forums on specific companies and job market. But I am afraid that simply indexing (even if done in the "right and respectful" way), would get a drawback.
-
@alexchapman @quillmatiq @evan @dansup @HolosSocial
and it has implications on innovation.
We/I could build a LinkedIn (when LinkedIn was good) version for the fediverse.
A nice professional UI fediverse-client that shows indexed #jobs posts, adding @badgefed / certifications celebrations, and some #lemmy forums on specific companies and job market. But I am afraid that simply indexing (even if done in the "right and respectful" way), would get a drawback.
@mapache @quillmatiq @evan @dansup @HolosSocial @badgefed I think we need to fight back against the elitest mentality and actually make it clear that stuff like this can be successful, and it doesn't hurt to allow different protocols and methods of doing stuff.
-
@quillmatiq not throwing stones, just spittin facts. To much glazing over AtProto when many seem to forget its history, so I feel a duty to remind people of this.
ATProto never cared about openness or the social web, or they would have adopted ActivityPub and helped improve it.
They had to control everything. Jack even said he regrets that himself.
@dansup @quillmatiq heya Dan! Going to do the mastodon/activitypub thing - I think you mean Bluesky
ATProto has a thriving community that I and others are part of.
I care about openness and the social web, which is why I spend time with the ATProto community
Feel free to yell at Bluesky-the-company
-
4. "Window of opportunity". This is a more complex one, but it is compelling. Basically, there is a non-zero chance that Bluesky's leadership team changes in the next few years, or that their strategy changes. (This has happened with other social networks like Twitter when the advertising business model was adopted.) They may at some point try to claw back the value that's been generated with the current open protocol, open source model. Hopefully not, but you never know!
4. (cont'd) The more that we as a whole social web community do now to encourage and accelerate the shifting of the centre of gravity of the ATmosphere from Bluesky to other PDSes, relays, lexicons, codebases, etc., the less effective that clawback effort will be, and the less damaging it will be. So, we in the Fediverse should support that shift as much as possible.
-
@thisismissem @mastodonmigration @quillmatiq @dansup @evan I appreciate this information, but my main interest in modern decentralized social media protocols is for social media (microblogging, as well as picture & video sharing), and I am not a developer - just a nerd. My primary concern in all of this is I simply don't trust Bluesky PBLLC. That's why complete and total independence from their infrastructure from a microblogging standpoint is important to me before I would ever consider using an ATproto-based service as my primary social media platform. While I'm okay using community resources for now, I *want* the ability to host my own completely independent full stack so I would never need to rely on a company or community to stand up a relay or AppView or something. I can do that easily and *cheaply* today with Mastodon or WAFRN (the ActivityPub side of it, anyway) or Pixelfed or Loops - it's not a big lift because these platforms were already designed with the full stack as a single deployment. This makes the network highly resistant to adversarial takeover, especially as things exist *right now*. It's a far, far, far bigger lift to stand up a similarly independent full stack of Bluesky (for example), and far far far easier for the majority of the network to be compromised if all statuses must be funneled through corporate or community chokepoints.
Tl;dr if I can't easily host a full stack that can run completely on it's own (while still being able to federate with others), that's not independence. *Every* service built on top of ActivityPub can give me that independence *by design*. It's the difference between human-scale networking and corporate-scale networking.
If there's an easy, lightweight, fully independent way for me to participate in Bluesky-compatible microblogging on ATproto with an experience that is comparable to what I'd get from using Bluesky directly, I'm interested to learn more - because I'm not currently aware of anything like that. I can get that from multiple platforms on AP *today*.
@thisismissem @mastodonmigration @quillmatiq @dansup @evan And I wanna be clear (since I used every single character allowed in my last post) that everything I've typed is both my personal opinion and knowledge - again I'm not a dev, just a nerd and a user. This is what I understand the situation to be today - but I know there's gaps in my knowledge so my request for information is not sarcasm or said to prove a point. So corrections are very welcome! I desire only to explain where I'm coming from and to learn more.
-
@thisismissem @mastodonmigration @quillmatiq @dansup @evan I appreciate this information, but my main interest in modern decentralized social media protocols is for social media (microblogging, as well as picture & video sharing), and I am not a developer - just a nerd. My primary concern in all of this is I simply don't trust Bluesky PBLLC. That's why complete and total independence from their infrastructure from a microblogging standpoint is important to me before I would ever consider using an ATproto-based service as my primary social media platform. While I'm okay using community resources for now, I *want* the ability to host my own completely independent full stack so I would never need to rely on a company or community to stand up a relay or AppView or something. I can do that easily and *cheaply* today with Mastodon or WAFRN (the ActivityPub side of it, anyway) or Pixelfed or Loops - it's not a big lift because these platforms were already designed with the full stack as a single deployment. This makes the network highly resistant to adversarial takeover, especially as things exist *right now*. It's a far, far, far bigger lift to stand up a similarly independent full stack of Bluesky (for example), and far far far easier for the majority of the network to be compromised if all statuses must be funneled through corporate or community chokepoints.
Tl;dr if I can't easily host a full stack that can run completely on it's own (while still being able to federate with others), that's not independence. *Every* service built on top of ActivityPub can give me that independence *by design*. It's the difference between human-scale networking and corporate-scale networking.
If there's an easy, lightweight, fully independent way for me to participate in Bluesky-compatible microblogging on ATproto with an experience that is comparable to what I'd get from using Bluesky directly, I'm interested to learn more - because I'm not currently aware of anything like that. I can get that from multiple platforms on AP *today*.
@baralheia Then use Blacksky or similar. They have their own PDS, their own Relay, their own Bluesky AppView, and to a degree own Moderation — they still do query the Bluesky Moderation Service for some stuff though.
So they are effectively entirely independent. They have done experiments with did:web too, though I think they're mostly using did:plc (not 100% sure).
But operating an entire global-scale network is expensive. Bluesky have stated that just generating following feeds is something like the majority of their infrastructure load. There are other projects that seek to not do global-scale, and instead have different tradeoffs.
With ActivityPub, you only have local-scale, which gives you a small perspective of the entire network. There are projects like fediscovery that are designed to facilitate sharing data across otherwise loosely federated boundaries, such that they can do near global scale things.
-
@thisismissem @mastodonmigration @quillmatiq @dansup @evan I appreciate this information, but my main interest in modern decentralized social media protocols is for social media (microblogging, as well as picture & video sharing), and I am not a developer - just a nerd. My primary concern in all of this is I simply don't trust Bluesky PBLLC. That's why complete and total independence from their infrastructure from a microblogging standpoint is important to me before I would ever consider using an ATproto-based service as my primary social media platform. While I'm okay using community resources for now, I *want* the ability to host my own completely independent full stack so I would never need to rely on a company or community to stand up a relay or AppView or something. I can do that easily and *cheaply* today with Mastodon or WAFRN (the ActivityPub side of it, anyway) or Pixelfed or Loops - it's not a big lift because these platforms were already designed with the full stack as a single deployment. This makes the network highly resistant to adversarial takeover, especially as things exist *right now*. It's a far, far, far bigger lift to stand up a similarly independent full stack of Bluesky (for example), and far far far easier for the majority of the network to be compromised if all statuses must be funneled through corporate or community chokepoints.
Tl;dr if I can't easily host a full stack that can run completely on it's own (while still being able to federate with others), that's not independence. *Every* service built on top of ActivityPub can give me that independence *by design*. It's the difference between human-scale networking and corporate-scale networking.
If there's an easy, lightweight, fully independent way for me to participate in Bluesky-compatible microblogging on ATproto with an experience that is comparable to what I'd get from using Bluesky directly, I'm interested to learn more - because I'm not currently aware of anything like that. I can get that from multiple platforms on AP *today*.
@baralheia @thisismissem @quillmatiq @dansup @evan
It does seem to come down to how one defines 'independent'. If you are dependent upon other components owned and controlled by others, it is hard to understand how that can be considered independent.
-
@baralheia Then use Blacksky or similar. They have their own PDS, their own Relay, their own Bluesky AppView, and to a degree own Moderation — they still do query the Bluesky Moderation Service for some stuff though.
So they are effectively entirely independent. They have done experiments with did:web too, though I think they're mostly using did:plc (not 100% sure).
But operating an entire global-scale network is expensive. Bluesky have stated that just generating following feeds is something like the majority of their infrastructure load. There are other projects that seek to not do global-scale, and instead have different tradeoffs.
With ActivityPub, you only have local-scale, which gives you a small perspective of the entire network. There are projects like fediscovery that are designed to facilitate sharing data across otherwise loosely federated boundaries, such that they can do near global scale things.
@baralheia it's also perfectly okay to not want global scale and be happy with local scale. That's a trade-off you get to decide with which platform or protocol you use.
-
@quillmatiq @dansup I'm not trying to burn you, I promise! I know that you want to engender a culture of kindness and cooperation. I'm trying to suggest a more effective way of doing it: not by telling people they're bad, but by telling people why it's in their own interest to be better.
@evan @quillmatiq @dansup well I regret getting tagged into this, I responded up thread.
Dan is yelling at ATProto rather than yelling at Bluesky which of course ends up hitting the very people that care.
-
@baralheia it's also perfectly okay to not want global scale and be happy with local scale. That's a trade-off you get to decide with which platform or protocol you use.
It would seem like this 'global scale' difficulty relates to the aforesaid 'quadratic scaling' issue raised by @cwebber
If, in fact this is true, it is very hard to see how the protocol is actually viable as a broadly decentralized protocol.
Would love to have someone knowledgeable address this.
https://mastodon.online/@mastodonmigration/116064809568107112
-
@evan @dansup @quillmatiq interest is great and all, but understanding the social and power dynamics at play is more important.
Every time some leader of an ActivityPub project goes on a tirade against another protocol or project, all it does is hurt the entire ecosystem. It prevents productive partnerships, it creates friction and fights.
We've seen this countless times, and meanwhile majority of ActivityPub applications are not striving for ActivityPub interoperability, but for Mastodon interoperability.
There is so much power centralization in ActivityPub it's not funny, let's not forget that the protocol was left to rot by the W3C for the longest time, when it could've continued on-wards. The amount of infighting and politics here drives people away.
I've talked with folks who have really great ideas, and I've been like "come bring this to a standards meeting, this is really cool" and the response time and again is "I don't want to be involved with those people", because they've seen countless negative interactions.
Meanwhile, in AT Protocol, it's extremely common place to get different application developers and organisations to come together to standardise things, the best example is https://standard.site — I'm also helping a few developers work on interoperability for other things within the Atmosphere, because they realise that they're stronger together.
In ActivityPub there's been constant division "this software is better than that software", and petty little fights about "this isn't really activitypub because it doesn't do what mastodon does, so it doesn't interoperate fully" — Dan was the target of one such hit piece.
The office hours that the bluesky team run every two weeks? They basically entirely focus on sharing and promoting the cool work by other people in the ecosystem, here's some notes from the latest: https://bsky.app/profile/thisismissem.social/post/3mere5l7knk2n
I've mentioned it before, but I've stopped actively contributing to Mastodon because the lack of respect that they show other contributors is so dire that it's not financially viable for me to contribute.
@thisismissem @evan @dansup @quillmatiq and for my MassiveWiki project I want both AT and AP interop. I think we just need a few bridges to use and experiment with. (nonetheless, he persists)
-
@sheislaurence That is an awesome question. I'm not sure!
There's a good landing page here with a lot of links to explore.
@evan @sheislaurence that’s a sort of bookmark on my own site and is pretty protocol focused.
@sheislaurence I help support a number of ATProto community resources.
Community blog https://atprotocol.dev and forum https://discourse.atprotocol.community, and I have some collected bookmarks of good articles https://semble.so/profile/bmann.ca/collections/3m5u77miiyf2h
Fun fact: that Semble site is also ATProto powered and you use your same account to store bookmarks
-
@sheislaurence That is an awesome question. I'm not sure!
There's a good landing page here with a lot of links to explore.
@evan @boris @reflex @dansup @quillmatiq will you forgive me cos I asked Gemini😂: Destroy as suitable. Under dependency challenges, it says:
- Identity Dependency: did:plc directory Bsky owned
- "Centralized Indexing: users can host their own PDS, but rely on "relays" to discover other users. Currently, the main relay is operated by Bky. Replacing this requires significant compute power."
- "Atproto's adoption depends on it having a "killer app" other than the initial microblogging client" -
It would seem like this 'global scale' difficulty relates to the aforesaid 'quadratic scaling' issue raised by @cwebber
If, in fact this is true, it is very hard to see how the protocol is actually viable as a broadly decentralized protocol.
Would love to have someone knowledgeable address this.
https://mastodon.online/@mastodonmigration/116064809568107112
@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 @evan @dansup @quillmatiq and for my MassiveWiki project I want both AT and AP interop. I think we just need a few bridges to use and experiment with. (nonetheless, he persists)
@band @evan @dansup @quillmatiq well, @quillmatiq is involved in Bridgy Fed, and it's open source, so, there's maybe a starting point. You could probably also re-use the https://standard.site lexicon
-
@evan @boris @reflex @dansup @quillmatiq will you forgive me cos I asked Gemini😂: Destroy as suitable. Under dependency challenges, it says:
- Identity Dependency: did:plc directory Bsky owned
- "Centralized Indexing: users can host their own PDS, but rely on "relays" to discover other users. Currently, the main relay is operated by Bky. Replacing this requires significant compute power."
- "Atproto's adoption depends on it having a "killer app" other than the initial microblogging client"@sheislaurence did:plc is spinning out to an independent org, relays are only necessary for things at scale (& aren’t used for user discovery), and relays currently cost $20/month for 42M accounts.
I presented at Fedicon last year about a selection of the many apps being built https://bmannconsulting.com/notes/beyond-microblogging-atproto/
For completeness, because of account architecture, ATProto doesn’t have a private data option today.
-
@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 @baralheia @cwebber
Hmmm... please excuse the layman's understanding of these matters, but it does seem like this relates to traffic at the network layer. What you are saying is that the difficulty for the smaller instance in scaling is "serving up feeds for 42 million users." With ActivityPub the first request would transfer a single copy to a cache on the requesting instance and subsequent requests would not generate any traffic. This is why AP is able to scale linearly.
-
@thisismissem @baralheia @cwebber
Hmmm... please excuse the layman's understanding of these matters, but it does seem like this relates to traffic at the network layer. What you are saying is that the difficulty for the smaller instance in scaling is "serving up feeds for 42 million users." With ActivityPub the first request would transfer a single copy to a cache on the requesting instance and subsequent requests would not generate any traffic. This is why AP is able to scale linearly.
@mastodonmigration @baralheia @cwebber so ingesting all the data for Bluesky does take time & resources, but it is doable: @FedicaHQ have actually done this, as have Blacksky. There's probably others too.
The AppView acts as a cache for this data. The cost is due to the sheer scale of the dataset, and in computing the feeds & notifications for however many million users.
The other cost is CDN and Moderation, which are kinda expensive at scale, however, definitely aren't costs unfamiliar for AP servers too.
Mastodon does an interesting design choice by stopping producing feeds for users that haven't been active for a while.
There's also been plenty of fediverse applications that have had issues with feed generation (Firefish, Hollo, and others have had issues in the past if memory serves).
So yeah, if you only need to serve feeds for say a dozen users and don't need the full network's worth of data, then it's cheaper.
But the article that Christine wrote was more about the network bandwidth between the components and how that scales. Which is a very different matter.
-
@mastodonmigration @baralheia @cwebber so ingesting all the data for Bluesky does take time & resources, but it is doable: @FedicaHQ have actually done this, as have Blacksky. There's probably others too.
The AppView acts as a cache for this data. The cost is due to the sheer scale of the dataset, and in computing the feeds & notifications for however many million users.
The other cost is CDN and Moderation, which are kinda expensive at scale, however, definitely aren't costs unfamiliar for AP servers too.
Mastodon does an interesting design choice by stopping producing feeds for users that haven't been active for a while.
There's also been plenty of fediverse applications that have had issues with feed generation (Firefish, Hollo, and others have had issues in the past if memory serves).
So yeah, if you only need to serve feeds for say a dozen users and don't need the full network's worth of data, then it's cheaper.
But the article that Christine wrote was more about the network bandwidth between the components and how that scales. Which is a very different matter.
@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.
-
@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.
@thisismissem @mastodonmigration @cwebber is there a list or directory of independent Bluesky relays and AppViews somewhere?