Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone
  1. Home
  2. Categories
  3. General Discussion
  4. A few facts and thoughts about #BlueSky being decentralized or not:

A few facts and thoughts about #BlueSky being decentralized or not:

General Discussion
3 2 0
  • res260@infosec.exchangeundefined

    A few facts and thoughts about being decentralized or not:

    1. (the protocol behind bluesky) is decentralized and open-source, but is controlled by a for-profit (albeit fiscally a public benefit) organization, "Bluesky Social PBC".

    2. "Bluesky" refers to a sum of ATProto concepts, notably the AppView (bsky.app), the main Personal Data Servers (PDS, bsky.social), and the Relays (or firehose, bsky.network). There are others, but they're the 3 important ones.

    3. Anyone can run their own AppView, PDS or Relay AND consume the content from/get their content consumed by the Bluesky infrastructure. HOWEVER, not everything is trivial or cheap to run.

    3.0 A PDS, which contains your data (account details but also posts, likes, follows, etc), is trivial and cheap to self-host. Cheaper than hosting a mastodon instance, even, because it does way less stuff and receives way less requests. See https://github.com/bluesky-social/pds

    3.1 An AppView (the presentation layer, where users interact with ATProto content) can be created by anyone, but the bsky.app backend is NOT open-source, so there are not a ton of options right now.
    EDIT: seems like I was wrong and that the bsky.app AppView is open-source: https://github.com/bluesky-social/atproto/tree/main/packages/bsky

    3.2 Running a relay is trivial but expensive to self-host. This is because its purpose is to act as an aggregator for all the PDS so that AppViews can consume the data in a way that scales better. The Bluesky relay implementation (bigsky) is open-source: https://github.com/bluesky-social/indigo/blob/main/cmd/bigsky/README.md
    About 2.5 months ago, 4.5TB of storage was needed and an OVH server costing 150$/month worked to host a full-atmosphere relay (more on that later).

    4.0 To make a comparison with (the protocol behind ), the AppView and PDS is the same thing in ActivityPub, and the concept of relay doesn't exist. There are advantages and drawbacks to both architectures, I might do a future post highlighting those.

    5.0 With those definitions out of the way, some observations:

    5.1 A lot of users self-host their PDS, but the vast majority of users chose the simpler option.

    5.2 There are some alternative AppViews built on ATProto, but the vast majority of users visit bsky.app.

    5.3 There are very little non-bluesky self-hosting of relays, mostly because of their prohibitive cost. Running the bigsky relay is expensive partly because of design decisions for ATProto and partly because it takes ALL content from ALL accounts for ALL the network on the atmosphere (in this case atmosphere == fediverse but for ATProto). This is like if your Mastodon instance queried ALL servers for ALL accounts querying ALL posts. In the future, there might exist relays that don't scrape ALL data but only a subset of it, which would bring down costs, but it's not yet the case.

    6.0 So "is Bluesky decentralized?"

    6.1 In theory, yes, everything that bluesky does on ATProto can be.

    6.2 In practice, however, the most decentralized part of Bluesky is the PDS, where the user data is stored, and even that is not that decentralized.

    6.3 Will it stay this way? I'm hopeful it won't, but I don't know. ATProto is fairly new compared to ActivityPub, and the ecosystem around it was mostly built by the BlueSky company, but I expect this to change in the future. However, the cost of entry for things built on ATProto will always be more than the cost of entry for things built on ActivityPub.

    6.4 Things built on ActivityPub will always be more decentralized than things built on ATProto, because of design decisions from both of these protocols.

    0
  • wendythedruid@thistleandmoss.orgundefined
    While I like the protocol for what it is, and how it was written, it is indeed NOT actually decentralized in the classical sense. And it is also algorithmic, even if they say its not.
    0
  • wendythedruid@thistleandmoss.orgundefined wendythedruid@thistleandmoss.org
    While I like the protocol for what it is, and how it was written, it is indeed NOT actually decentralized in the classical sense. And it is also algorithmic, even if they say its not.
    res260@infosec.exchangeundefined

    @wendythedruid I really like the PDS part of the protocol and the way identity is handled. The fact that you decide where your data is regardless of the app you choose to use is neat

    0
Log in to reply

Feed RSS
A few facts and thoughts about #BlueSky being decentralized or not:

Gli ultimi otto messaggi ricevuti dalla Federazione
@pierobosio@soc.bosio.info
Post suggeriti
  • activitypub.blog@activitypub.blogundefined

    Roadmap 2026 — Charting the stars of the open social web

    Fediverso activitypub api c2s directmessages discoverability fediverse findability interoperability
    3
    3
    0 Votes
    3 Posts
    16 Views
    kaffeeringe@social.tchncs.deundefined
    @activitypub.blog Nice! Very cool outlook!I would love to see some action not just on the technical side of ActivityPub in WordPress but also on the promotion side. It woud be great to convince some of the more interesting blog from wordpress.com to activate ActivityPub.
  • lqdev@lqdev.meundefined

    Thoughts on the Social Web from FOSDEM 2026

    General Discussion fosdem2026 fosdem socialweb indieweb activitypub fediverse decentralization community
    1
    0 Votes
    1 Posts
    15 Views
    lqdev@lqdev.meundefined
    I had the opportunity to attend FOSDEM 2026 virtually, and I spent almost all of my time in the [Social Web](https://fosdem.org/2026/schedule/track/social-web/) track. A few themes kept coming up across talks. Some were explicit, some were between the lines. Either way, they prompted a bunch of thoughts I wanted to capture. DISCLAIMER: AI was used to help me organize and improve the flow of this post. Ideas and thoughts expressed are my own. ## Hosting is hard In [*Building a sustainable Italian Fediverse: overcoming technical, adoption and moderation challenges*](https://fosdem.org/2026/schedule/event/VKHGXT-building_a_sustainable_italian_fediverse_overcoming_technical_adoption_and_moder/), there was a moment (not the main focus of the talk) where hosting came up in a way that really stuck with me. I’m paraphrasing, so apologies if I misrepresent anything, but the gist was: - Hosting Mastodon is hard, so we simplify with hosting services like Masto.Host - Hosting PixelFed and PeerTube is easier thanks to appliances like YunoHost Based on my own experience, that rings true, with some nuance. Getting Mastodon running isn’t actually the hardest part. The self-hosting docs are good enough in my opinion, and that’s how I originally stood up my instance at [toot.lqdev.tech](https://toot.lqdev.tech/@lqdev). I even maintain guides for [cleanup](https://lqdev.me/resources/wiki/mastodon-server-cleanup/) and [upgrades](/resources/wiki/mastodon-server-upgrades/) that largely mirror the official Mastodon documentation and release notes. The harder part is everything after provisioning. Mastodon (especially with federation enabled) can be resource-intensive, and that cost shows up fast even on a single-user instance. If I’m not staying on top of maintenance, disk fills up. Every few weeks, my instance will go down because I’ve run out of storage. Add database migrations, which can be error-prone, and you end up with a setup that’s straightforward to launch but expensive to operate. You pay in money for a big enough server, and you pay in time for ongoing maintenace. I still want to participate in the Fediverse, but I don’t want to keep paying the maintenance tax for Mastodon. That’s one of the reasons [I implemented ActivityPub on my static site](/notes/website-now-natively-posts-to-the-fediverse-2026-01-22/) instead. On the PixelFed side, I did try to self-host it once, and I couldn’t get it working cleanly from scratch. Some of that is on me (I’m not familiar with PHP), but either way, YunoHost was a lifesaver. With YunoHost, I had PixelFed up and running quickly, and what that ecosystem provides is genuinely impressive. That said, I also learned the “operations” lesson there too. During an upgrade, something went wrong with the database, it got corrupted, and I couldn’t restore from backup. I ultimately took the instance down. I’m willing to attribute that to user error, but it still reinforces the bigger point. The promise of federation and decentralization is that you can stand up your own node for yourself, your family, a school, a company, a city, even a government. In practice, that’s still too hard for most people unless they use appliances like YunoHost or managed hosting like Masto.Host. And yes, those options mean giving up some control. But even with that tradeoff, I’d argue it’s still better than centralized platforms. As someone fairly technical and a little extreme about owning the whole stack (I implemented my own static site generator, Webmentions service, and now ActivityPub), I still find this hard. I can’t imagine how unapproachable it feels if you’re not technical. I just wish it were simpler and more cost-effective to run these services without needing either deep system administration knowledge or active ongoing maintenance. ## One identity, many post types In the talk, [*How to level up the Fediverse*](https://fosdem.org/2026/schedule/event/HVJRNV-how_to_level_up_the_fediverse/), Christine and Jessica talked about ActivityPub implementations and touched on something that really resonated with me. The idea (again, paraphrasing) was that splitting content types by app (video goes to PeerTube, images go to PixelFed, microblogging goes to Mastodon) might not be the right long-term model. Instead, they suggested something closer to one place to publish and follow people, with rich post types handled in one identity and one experience. That immediately made me think about Tumblr. When I first heard [Tumblr was planning to implement ActivityPub](https://techcrunch.com/2022/11/21/tumblr-to-add-support-for-activitypub-the-social-protocol-powering-mastodon-and-other-apps/), I was excited because Tumblr is already “that kind of app.” You can publish videos, photos, polls, longer posts, and everything in between, all in one place. There was also talk about [moving Tumblr to WordPress](https://techcrunch.com/2024/08/28/tumblr-to-move-its-half-a-billion-blogs-to-wordpress/), which (in theory) could make ActivityPub integration even more powerful. But as of now, [Tumblr’s ActivityPub work seems to be paused](https://techcrunch.com/2025/07/01/automattic-puts-tumblr-migration-to-wordpress-on-hold/). The more I think about it, the more this model makes sense, especially because the most important part isn’t the “single app.” It’s the single identity. You should have one account where your content originates. Then people can consume it from different experiences. Maybe that is a video-focused client, maybe it is an image-first view, maybe it is a Mastodon-like timeline. The key is that you do not need separate accounts everywhere. That’s essentially how I think about my website. My site is my digital home and my identity. I post different content types which align with [IndieWeb post types](https://indieweb.org/posts#Types_of_Posts): - Articles - Notes - Responses (reposts, replies, likes) - Bookmarks - Media (photos and videos) - RSVPs People can follow via RSS. And more recently, I implemented my own ActivityPub support so my posts generate native ActivityPub activities. That means Mastodon and other clients can follow and interact with my site directly. What I like about this is that it decouples publishing from consumption. I choose where I publish (my site). Others choose how they consume (their client). The protocols handle the translation. ## The web is already social and decentralized In Social Web conversations, sometimes the tone implies the "social web" is separate from "the web". I don't really buy that. The web is social because people are on it. People use it to learn, create, find community, do commerce, argue, collaborate, share memes, and everything else. The web is also decentralized by default. That's the baseline architecture. Dave Winer recently wrote about software being ["of the web"](http://scripting.com/2025/11/24/141418.html). Software that's built to share data, accept input, produce output, and let users move their data. Not locked into silos. This is why I'm so bullish on a different architectural approach: **start as a website, add social capabilities as components.** People are already using WordPress, Ghost, and Micro.blog to build sites. With an ActivityPub plugin, your existing web presence becomes followable and interactive in the Fediverse. The site remains a site. It just gets socially interoperable. Bridgy Fed reinforces this. It takes what already exists on the web and helps it participate in social protocols, without forcing you to rebuild as a native social app first. That's also my own setup. My website worked as a publishing platform and people could follow via RSS. When I implemented ActivityPub, it became progressively enhanced. Same posts, new social vocabulary. I didn't have to abandon my site. I just made it speak the social language. ## Modular and extensible feels like the right direction This is the architectural vision I took away from Bonfire: [Building Modular, Consentful, and Federated Social Networks](https://fosdem.org/2026/schedule/event/3QHALR-bonfire_building_modular_consentful_and_federated_social_networks/). The "opt-in pieces" approach is about choosing which parts you want, evolving your experience based on what you enable. It echoes [small pieces loosely joined](http://scripting.com/2026/01/30/140150.html). It's a practical model for a federated future: - Start with the basic web - Add social capabilities as components - Get progressively more powerful as you opt in Your site still works normally. When you speak the lingua franca of protocols like ActivityPub, you can express social intent in a way other systems understand. So it's not "the web vs the social web." It's the web, with richer native social vocabulary. ## Conclusion This probably reads like I’m nitpicking, but I’m genuinely bullish on federated and decentralized networks. That’s why I’m still participating. What stood out to me at FOSDEM this year is momentum. Last year, the Social Web track was a half day. This year, it expanded to a full day. That signals to me that there are a lot of smart, passionate people working across protocol design, UX, moderation, policy, community, activism, and implementation, trying to build real alternatives to entrenched silos. And the plurality of implementations is a strength. It encourages exploration, competition, and innovation. My hope is that the “end state” isn’t a separate social web you have to join. It’s a web that continues to work as expected, but gets progressively enhanced when you opt into interoperable social protocols. Ultimately, there isn’t “the web” and “the social web.” There's just the web, and social vocabularies that participants can adopt without thinking about it.
  • dominikhofer@social.lolundefined

    Quick question to all #activitypub and #atproto experts:

    General Discussion activitypub atproto fediverse indieweb
    8
    0 Votes
    8 Posts
    46 Views
    thisismissem@activitypub.spaceundefined
    dominikhofer@social.lol nope, ActivityPDS was initially exploring if I could reuse the bluesky OAuth code outside of their codebase, the next phase of development would be exploring Actors & Webfinger (or not) and ActivityPub C2S paired with S2S. It's specifically not a protocol translator, but rather a "what if we had a AT Protocol PDS shaped thing in the AP universe. Like how can C2S DX be improved? Can it even be improved?
  • aral@mastodon.ar.alundefined

    Hey everyone,

    Fediverso gaza palestine gazaverified mastodon fediverse newmembers verification
    1
    0 Votes
    1 Posts
    25 Views
    aral@mastodon.ar.alundefined
    Hey everyone,While @joynewacc’s Internet connection is offline during her move, I was lucky enough to have @aseelfromgz with me today as we carried out today’s verification video calls for Gaza Verified and we’re happy to welcome four new accounts/families to Gaza Verified.They are:• Mohamed Hesham – @mohamedhesham• Naeema family – @naeemafamily• Hema Alshaer – @hemaalshaer• Seraj Alnajjar – @serajnjar20Please give them a warm welcome to Mastodon and the fediverse, follow their accounts, and, if you can, please help them with their fundraisers and please share this so others might also.Also, please remember that Aseel is in Gaza too and is helping others despite facing the very same challenges herself. You can help her and her family via her:• PayPal (easier for them to get the funds): https://www.paypal.com/donate/?hosted_button_id=7DTFU9TQV44EY• GoFundMe: https://www.gofundme.com/f/help-aseel-and-family-leave-gaza-before-its-too-late/💕#Gaza #Palestine #GazaVerified #Mastodon #fediverse #newMembers #verification