rsky builds twenty-one Rust members and documents fourteen of them

Twenty-one workspace members, fourteen documented components

The README presents rsky in two tables, six crates and eight services, while the Cargo manifest at the root declares twenty-one workspace members. Set the two side by side and seven member directories are built without appearing in either table: palomar-sync, rsky-daemon, rsky-oauth, rsky-pds-router, rsky-space, rsky-space-host and rsky-video. An eighth directory, rsky-pdsadmin, sits in the tree without being a workspace member at all.

The crate table is the more precise half. rsky-crypto handles cryptographic signing and key serialization, rsky-identity resolves DIDs and handles, rsky-lexicon is the schema definition language, rsky-syntax holds string parsers for identifiers, rsky-common is shared code, and rsky-repo is the data storage structure including MST. The service table covers a relay that crawls the network and emits one large stream for other services to consume, a personal data server, a feed generator, three separate firehose consumers, a DASL CAR and repository explorer called rsky-satnav, and rsky-wintermute, an indexer for the bsky app-view. rsky-space and rsky-space-host appear to be a matched pair by name, but nothing in the two tables says what either of them holds, and neither the relay's storage layer nor any deployment shape is described anywhere in that section.

The stability warning names a version the repository has never cut

The warning at the top of the README is unusually blunt: this library is a work in progress, things will change, things are incomplete, things will break, and until the project reaches version 1.0.0 stability will not be guaranteed. The repository has no GitHub releases at all, so there is no tag history to check that promise against and nothing to download if you are not prepared to build from source.

Six crates are published on crates.io and pinned with explicit semver versions in the workspace dependency table: rsky-lexicon at 0.11.2, rsky-identity at 0.3.0, rsky-crypto at 0.2.1, rsky-common at 0.1.3, rsky-repo at 0.1.3 and rsky-syntax at 0.1.0. The eight services appear in the same manifest as members with no version entry in that dependency table, so the versioned, consumable surface is the library half of the project and the deployable half is what each adopter compiles. The spread in those numbers is itself informative: the schema language is furthest along and the identifier parsers are barely started, which matches a project that is still building the data layer before the network around it. The last push to the default branch, main, is dated 2026-09-25.

rsky-pds swaps SQLite for Postgres and disk for object storage

rsky-pds is where the project states its architectural choices most plainly. It hosts repository content for atproto accounts, and it differs from the canonical TypeScript implementation in three named ways: Postgres instead of SQLite, S3 compatible blob storage instead of on-disk storage, and Mailgun for email. The reason given is not throughput but portability, described as making the personal data server easier to migrate between cloud hosting providers and more maintainable.

The cost of that decision is concrete. A deployment that once needed a local database file now needs a managed Postgres instance, an object store and an email provider, and the operator inherits the availability and credential handling of all three. The dependency table still pins rusqlite at version 0.40 with the bundled feature, so a SQLite driver remains a workspace level dependency in a project whose personal data server is described as Postgres only. The manifest gives no note on whether another member crate needs it or whether the pin is inherited from earlier work.

The relay makes the mirror image choice, crawling the network and outputting everything it gathers as one big stream, described as analogous to a firehose provider or a super-powered relay node. That is the component with the largest storage appetite in the set, and it sits next to a personal data server that deliberately moved its storage off local disk.

Four build profiles, and two of the dev ones do nothing

The manifest carries four profile sections. The release profile sets debug = false, and three dev profiles sit beside it: wasm-dev, server-dev and android-dev. Two of those three are pure aliases that inherit dev and stop there. Only wasm-dev changes anything, setting opt-level = 1 on top of the inherited dev profile, which is the usual trade for a target that has to compile quickly rather than run quickly.

[profile.wasm-dev]
inherits = "dev"
opt-level = 1

Two named targets and a rust-toolchain file at the repository root are the only signals in the top level listing that non server builds are in scope, and one of the eight undocumented member directories is rsky-video. The dependency table asks tokio for the full feature set, and secp256k1 at 0.28.2 for global-context, serde, rand, hashes and rand-std together, which is the combination a signing crate needs when it also serialises key material. Nothing in the README mentions wasm, Android or video anywhere, so the profile names and the video member are the only evidence that the workspace targets more than the services the tables describe.

Two CBOR libraries and two routes to the derive macros

The workspace dependency table is where the pinning discipline shows, and where the duplication does too. serde appears at 1.0.160 with the derive feature enabled, and serde_derive appears separately at ^1.0, which is two declared routes to the same derive macros. Two CBOR libraries sit next to each other: serde_ipld_dagcbor at 0.6.1 with the codec feature, and serde_cbor at 0.11.2, a different implementation of the same format on a much older release line. The manifest carries no comment on why both are needed, and no crate in the listing says which one it uses.

Elsewhere the choices are tighter and easier to follow. Byte handling goes through serde_bytes at 0.11.15, identifiers are content addressed through lexicon_cid, which renames the cid crate at 0.11.1 with serde codec support, and IPLD core sits at 0.4.2. The resolver is set to version 2, which matters in a workspace this size because feature unification across twenty-one members is where duplicate dependencies normally come from.

That last point is worth pressing. The member directories carry their own Cargo.toml files that are not visible in the top level listing, so the versions above are only the shared floor. An adopter pinning dependencies for a compliance review has to read twenty-one manifests, not one, and the workspace table gives no way to see the resolved graph without running the resolver.

Two roadmaps, one checkbox, and two documents nothing links to

Progress is tracked in two places, which is one more than a reader can resolve. The README carries a Roadmap section with four items: feedgen and firehose consumer, PDS implementation, and frontend bluesky client are all checked, while the feedgen admin client is not. The repository root also holds a ROADMAP.md that the README never links to, so nothing tells you which of the two is current or whether they agree with each other. Two more root documents sit unlinked in the same way, TODO.md and SECURITY.md.

The unchecked item is the interesting one, because the tree contains rsky-pdsadmin, an administrative surface for the personal data server, as a directory that is not listed among the twenty-one workspace members and therefore is not part of a root build. That directory is either a component still being brought in or a leftover from an earlier layout, and neither state is written down anywhere in the two tables or in the manifest.

There is also a naming inconsistency inside the personal data server family itself: rsky-pds, rsky-pds-router and rsky-pdsadmin use one pattern, while rsky-space and rsky-space-host use another, and the second pair has no explanation in either table. For a project whose stated priority is community self-governance, an unexplained admin surface and an unexplained server pair are the two places a reviewer will want an answer first.

A .dockerignore with no Dockerfile at the root

Not every loose end is in the manifest. The root carries a .dockerignore and no Dockerfile, no compose file and no container recipe in the top level listing, so the container story that the personal data server's portability argument implies is not visible from the repository root. If an image is built somewhere, the recipe sits in one of the member directories or in the .github workflows, and neither is reachable from the README. An .idea directory is committed alongside the source, holding JetBrains project settings that mean nothing to anyone building from a checkout, and a scripts directory sits next to it for tooling beyond cargo.

The lexicons directory at the root is the one piece of layout the README does not explain but the crate table implies, since rsky-lexicon is described as the schema definition language and the protocol's schemas are lexicon documents. That pairing is worth checking against the crate's own README before assuming the two directories hold the same files.

The README itself closes with an OpenCollective backers grid running through dozens of numbered entries, and the badge row above the warning carries a link to a campaign explainer page at techforpalestine.org alongside the crates.io, dependency status, Apache license and Discord badges. The homepage field points at blackskyweb.xyz, and one badge points at the project's own Bluesky account at blacksky.app. The project describes itself as prioritising community safety and self-governance, and the funding and account links are where that shows up most concretely.

Editorial conclusion

rsky is a serious piece of infrastructure rather than a demo, and the two tables it publishes are a good map of the library half of the work. Three things are worth checking before you build on it. First, decide whether you need the crates or the services, because only the crates carry published versions. Second, count what you actually get from a root build, since eight member directories, including rsky-pdsadmin, are absent from the documentation. Third, if you need containers, plan to write the recipe yourself, because a .dockerignore is present at the root with no Dockerfile beside it. Anyone evaluating it for a long lived deployment should read the workspace manifest and the root ROADMAP.md directly, and treat the version table in the README as the only published release information that exists.

Frequently asked questions

Official sources

1. blacksky-algorithms/rsky on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README