Participants
Resources
The MobilePDS is a lightweight Rust implementation of an ATProto Personal Data Server designed to run locally on a user’s mobile device. It puts users back in control of their identity, posts, and credentials — while allowing caching and moderation infrastructure to scale separately via a mirror PDS. The MobilePDS is the canonical source of truth; the mirror is just a performance and compliance layer.
This architecture supports DSA-aligned content moderation, preserves user privacy, and avoids turning infrastructure operators into central platforms or data controllers.
The MobilePDS:
The mirror PDS:
| Component | Details |
|---|---|
| Keys | Stored in secure enclave / TEE |
| Repo | Local MST snapshot, signed and synced |
| Sync | Periodic push/pull to proxy via HTTP + CAR |
| Fallback | Mirror can temporarily serve repo to relays |
| Moderation | Labels enforced at proxy level (not on device) |
The MobilePDS is part of a public digital infrastructure strategy for Europe:
A simple overview of how the mobilePDS architecture works:
[MobilePDS on Device]
┌───────────────────────┐
│ - Hosts repo locally │
│ - Signs records │
│ - Stores keys securely│
└────────▲──────────────┘
│
Sync (CAR + HTTP)
│
▼
[Mirror PDS (Mirror)]
┌─────────────────────────────┐
│ - Caches signed data │
│ - Enforces DSA-based labels │
│ - Publishes to relays │
└────────▲─────────────▲───────┘
│ │
Firehose / │ │ AppView fetches
Repo Sync │ │ feed/posts/etc.
▼ ▼
[Relays (e.g. CEMR)] [AppViews]
A mobile PDS (MPDS) key asset is control over the signing key. When setting up an MPDS, the following keys are generated and subsequently registered at the PLC:
The SKD is generated using platform specific trusted computer mechanisms with the resulting private key remaining on the device. Under many circumstances this will require a PLC update to roll a new device key when migrating between devices.
Users might want to interact with web based clients though while still retaining the signing authority on their end. In order to support this, an SKW is generated like this:
Web clients can now reconstruct the SKW like this:
Now web clients can send signed writes to the CPDS which generates an appropriate diff for the MPDS to consume.
Note: domain binding (PRF salts, HKDF salt and info and GCM AAD) the cryptographic artifacts are TBD.