Decentralised governance is starting to spill out of the usual on-chain spaces and into public timelines, thanks to a new integration between Bluesky’s AT Protocol and the Internet Computer. The idea is simple to explain, but surprisingly hard to pull off: let a DAO manage its social media presence without trusting one person to hold the keys.
That’s now possible through a Personal Data Server (PDS) hosted entirely on the Internet Computer, allowing on-chain entities to control a Bluesky identity and publish content through community voting. Instead of a password sitting in someone’s notes app or a private key locked behind a single admin account, the DAO canister becomes the account.
The project, built by developer Gekctek as part of a DFINITY developer grant, connects the mechanics of decentralised decision-making with the everyday reality of online communication. For DAOs that want to behave like organisations rather than loose groups of wallet addresses, social media has always been an awkward weak spot. Governance may be decentralised, but the public-facing voice often ends up centralised by necessity.
This integration is designed to change that dynamic by bringing posting and account control into the same environment where the DAO already operates: proposals, votes, permissions, and verifiable execution.
At the centre of the system is the AT Protocol, the technology behind Bluesky. AT Protocol flips the typical social media model by separating identity and data from the app interface. Instead of your posts, profile, and follower graph living exclusively on a platform’s servers, AT Protocol allows users to host their own data on a Personal Data Server. Relay servers crawl across these PDS instances, collect the data, and app views such as Bluesky display it.
The practical benefit is portability. If you decide you don’t like one app view, you can switch to another without losing your identity or starting from scratch. Your data and social graph are designed to move with you.
This Internet Computer integration takes that architecture and pushes it further by letting a canister act as the authoritative source for an organisation’s AT Protocol identity and content. For a DAO, that means its social presence can be governed like any other part of the project: collectively, transparently, and through rules that are enforced by code.
For communities that already rely on on-chain voting to decide funding, partnerships, and upgrades, the ability to extend that process to communications is an obvious next step. Social media is where narratives form, where announcements land, and where reputations can be built or damaged in hours. When one person controls an account, they also control a powerful lever, whether they intend to or not.
The integration addresses that risk by removing the “trusted account manager” model entirely. Traditionally, a DAO that wants a presence on X, Bluesky, or any other platform needs someone to create the account, hold the password, manage the recovery options, and post on behalf of the group. Even if the community agrees on what to say, it still depends on one operator to execute it.
That creates a single point of failure. If the account manager disappears, loses access, gets hacked, or goes rogue, the DAO can lose its public identity overnight. In the best case, it’s messy and disruptive. In the worst case, it’s catastrophic for trust.
With this implementation, the canister itself holds the identity. No individual holds the keys, because there aren’t keys in the traditional sense that need to be downloaded, stored, or backed up. Key generation and signing are handled automatically through the Internet Computer’s chain key cryptography at the protocol level.
That matters because operational security is often where decentralised projects quietly struggle. Communities may have excellent governance rules, but poor key management. A system that removes passwords, private key files, and recovery phrases from the workflow reduces the risk of human error, and lowers the barrier for groups that want to do things properly without becoming security experts.
The project is written in Motoko and aims to support core AT Protocol functionality as it evolves. At a technical level, it includes full XRPC endpoint support for repository operations, an IPLD/CAR-based repository with commit history, DID document serving via certified assets, and a permission system that supports direct control or delegation.
For developers, those details matter because they signal this isn’t a lightweight “post to Bluesky” hack. It’s attempting to implement the foundations of a real PDS inside a canister environment, which opens the door to deeper integrations later. While the initial focus is on posting, the design supports the broader protocol spec over time, which could enable richer interactions and more advanced identity management.
Alongside the PDS canister itself, there is an example DAO implementation that demonstrates how governance can control social actions. It shows how members can propose and vote on posts, manage deployments, and adjust configuration through an on-chain process. It also includes mechanisms for uploading large WASM modules via chunked transfers, which is a practical consideration for teams shipping updates in the real world.
This is where the integration becomes more than a technical achievement. It points to a future where DAOs can operate with the polish of traditional organisations, while keeping the core promise of decentralisation intact.
In a normal company, the marketing team controls the social channels. In a DAO, that role is often unclear. Some communities create multi-sig groups, others appoint “core contributors”, and many simply accept that someone will run the account. That works, until it doesn’t.
On-chain social governance changes the question from “who has the password?” to “what does the community want to say?” That sounds like a small difference, but it changes incentives. It also changes accountability. If a post is made through a vote, it reflects the community’s decision, not an individual’s judgement call. That can be valuable for high-stakes moments such as token launches, governance disputes, crisis response, or sensitive announcements.
Of course, it also introduces new trade-offs. Voting on every post could slow down communication, and DAOs already have a reputation for moving at the speed of their governance process. A rigid approach could make an account feel stale or overly cautious, especially in fast-moving markets.
That’s why delegation and permissions matter. The implementation supports a system where certain permissions can be delegated to other principals, allowing communities to strike a balance between control and responsiveness. A DAO could vote on strategy and tone, then delegate execution to a trusted group within defined limits. Or it could require votes only for certain types of posts, such as treasury decisions or governance outcomes.
These are governance design questions, and they will vary by community. The point is that the tooling now exists to make those choices enforceable rather than informal.
The project also highlights an interesting alignment between AT Protocol’s architecture and the Internet Computer’s strengths. AT Protocol expects users to control their own data via PDS instances. The Internet Computer offers a hosting environment where canisters can serve content, manage state, and run logic continuously. Putting a PDS into a canister is a natural pairing in theory, and a challenging one in practice.
One of the biggest hurdles comes down to WebSockets.
AT Protocol relays require a WebSocket connection through the com.atproto.sync.subscribeRepos endpoint in order to crawl and index PDS servers. The Internet Computer does not currently support WebSocket connections, which creates a gap between the protocol’s expectations and the platform’s capabilities.
Rather than treating that as a dead end, the developer implemented a workaround using a reverse proxy architecture. In this setup, a custom domain routes traffic differently depending on the endpoint. Regular HTTP requests go directly to the canister through the raw ICP URL, while WebSocket requests are routed to a separate Node.js server. That server polls the canister and pushes events through the WebSocket connection so relays can stay updated.
The proxy itself can be handled through tools like a Cloudflare Worker, and the routing logic is described as straightforward. Still, the workaround introduces extra moving parts, and with them, extra operational complexity.
It also comes with an important limitation: standard IC domain registration can’t be used here, because the reverse proxy needs to control the domain routing. Without that, WebSocket connections won’t work properly.
This is the kind of detail that matters for teams evaluating whether a tool is ready for production. The project is currently described as beta, functional but not production-ready. That’s an honest status update, and it sets expectations appropriately. It can create, update, and delete records, serve DID documents, handle repository exports, manage permissions and delegates, and integrate with relay crawlers through the proxy approach.
The DAO example demonstrates a complete governance flow for posts and deployments, which is likely the part most communities will care about first.
There’s also a broader implication in the WebSocket limitation: it shows how infrastructure features can shape what “fully on-chain” really means. Many projects aim to minimise reliance on external systems, but protocols and platforms don’t always line up perfectly. Until native WebSocket support exists on the Internet Computer, running a PDS that relays can crawl requires some off-chain infrastructure, even if the identity and content remain anchored in a canister.
For decentralisation purists, that might feel like a compromise. For builders trying to ship, it’s a practical bridge that allows progress without waiting for platform upgrades. It also gives the community a clear target for improvement: remove the proxy by enabling WebSockets natively.
Beyond the integration itself, the project produced a set of reusable Motoko libraries that could have long-term value for the developer ecosystem. Building a PDS required implementing lower-level tooling for IPFS and AT Protocol data structures, including packages for CID encoding and decoding, DAG-CBOR codecs, timestamp identifiers, DID parsing, multiformats support, CAR file formatting, and AT Protocol types and utilities.
These libraries have been published as standalone packages on MOPS, the Motoko package manager, and they can be used independently in other projects. That’s a meaningful outcome because it reduces duplication of effort across teams building on the Internet Computer. Even developers who aren’t interested in Bluesky integration may benefit from robust libraries for content addressing and IPLD data handling.
Zooming out, this integration is part of a larger shift in how decentralised communities think about identity. For years, the common approach has been to decentralise governance while keeping public communications centralised out of convenience. That separation has always been slightly awkward. It’s hard to claim community ownership when the community doesn’t control its own voice.
By bringing social identity and posting into an on-chain governance model, the project offers a new template: DAOs that govern their public presence the same way they govern their treasury.
It also speaks to the growing interest in decentralised social, sometimes grouped under the DeSo umbrella. The appeal is not just censorship resistance or portability, but the ability to build online communities where control is distributed by design. When the mechanics of governance can extend to communication, DAOs can operate with clearer legitimacy, especially when decisions are controversial or stakes are high.
There’s still work to do before this becomes a default pattern. Tooling needs to become easier to deploy, the proxy workaround adds friction, and DAOs will need to experiment with governance models that don’t turn every post into a slow committee process.
Even so, the integration makes one thing clear: decentralised governance doesn’t have to stop at smart contracts and token votes. It can reach the public timeline too, and it can do it in a way that reduces trust assumptions rather than adding new ones.
For communities that want their social presence to reflect their decentralised values, the message is straightforward. The era of “someone runs the account” may finally have an alternative.
Dear Reader,
Ledger Life is an independent platform dedicated to covering the Internet Computer (ICP) ecosystem and beyond. We focus on real stories, builder updates, project launches, and the quiet innovations that often get missed.
We’re not backed by sponsors. We rely on readers like you.
If you find value in what we publish—whether it’s deep dives into dApps, explainers on decentralised tech, or just keeping track of what’s moving in Web3—please consider making a donation. It helps us cover costs, stay consistent, and remain truly independent.
Your support goes a long way.
🧠 ICP Principal: ins6i-d53ug-zxmgh-qvum3-r3pvl-ufcvu-bdyon-ovzdy-d26k3-lgq2v-3qe
🧾 ICP Address: f8deb966878f8b83204b251d5d799e0345ea72b8e62e8cf9da8d8830e1b3b05f
🪙 BTC Wallet: bc1pp5kuez9r2atdmrp4jmu6fxersny4uhnaxyrxau4dg7365je8sy2q9zff6p
Every contribution helps keep the lights on, the stories flowing, and the crypto clutter out.
Thank you for reading, sharing, and being part of this experiment in decentralised media.
—Team Ledger Life
