building in the open, from the dark forest

I want to sketch out the direction we're thinking about for DFOS's open/public surface — a set of entangled primitives that only really make sense together. None of this is locked in, and the details will change as we work through them, but the shape feels right and I want to get it in front of people building things.

The throughline: identity is portable, content stays private, every layer is opt-in, the DID is the primitive.

Open source SDK for offline DID generation, content signing, and proof verification. A public DID registry that would accept any cryptographically valid identity — including external DIDs that have never touched the DFOS platform, no account required. Signed identity proofs as a native "login with DFOS" flow: prove you control a DID without granting access to content, spaces, or social graph. A consent signing page for managed-key users that produces the same output as self-custody local signing. Public profiles as opt-in social legibility — any DID, platform or external, could make itself resolve to human-readable identity info via signed updates. And careful thinking about authenticated content access that doesn't turn dark forest spaces into public mirrors.

Every default is dark forest. You exist as math until you choose otherwise.

the SDK: lib-dfos

The first piece is open sourcing the crypto and identity primitives as lib-dfos — DID generation, content signing, DAG-CBOR proof bundles, key management, operation chains. Fully offline, zero platform dependency. Plus a typed client for the public API.

Deliberately small. The math and the wire format, not the social graph. More DIDs in the wild and more verification happening outside the platform only makes DFOS more valuable as the social resolution layer.

identity proofs and "login with DFOS"

The question that keeps coming up: how do DFOS identities extend beyond the platform without breaking dark forest privacy?

The idea we're working with: an identity proof. A 3P service generates a challenge (nonce, timestamp, domain), you sign it with your assertion key, the 3P verifies against your DID's public keys. No tokens issued, no ongoing access, no PII exchanged. The 3P learns one thing: this user controls did:dfos:abc123.

Two paths to the same output:

• Self-custody (SDK/CLI, self-rolled DIDs): sign locally with lib-dfos. No platform involvement.
• Managed keys (app users): redirect to a DFOS consent page, user sees who's asking, DFOS signs with their managed key, redirects back with the signature.

This would be "login with DFOS" without OAuth. Identity assertion without resource access. The consent page feels like "login with Google" but the output is a one-time cryptographic proof, not an ongoing session.

Full OAuth (scoped access, tokens, 3P read/write clients) is a heavier lift down the road. The identity proof flow feels like the right first move — DFOS-native, minimal, high leverage.

the public DID registry

For proofs to work, the 3P needs to resolve a DID to its public keys. The idea is a public registry for this.

Platform users' DIDs are already resolvable. The interesting move: the registry would accept any cryptographically valid op chain. Generate a DID offline with lib-dfos, submit it, and your identity is publicly resolvable. No account, no authentication. The op chain is self-validating — the math is the auth.

This would introduce external identities to DFOS — the registry as a public convenience layer, not a gatekeep. DFOS as a DID resolver at the protocol layer, not just a platform feature.

public profiles: opt-in social legibility

A verified DID is a stable identifier — useful for gating access, maintaining sessions, associating activity. But it's a hex string.

Public profiles would make DIDs human-readable. Flip a switch and the public API resolves your DID to display name, avatar, bio.

This could work for external identities too — a self-rolled DID submits a signed catalog update with profile info. No account required. Your signature is your auth.

Two layers, both opt-in:

• DID in registry → resolvable keys, verifiable proofs
• Public profile enabled → DID resolves to identity info

what this enables

Someone building an interest graph app, a community tool, a recommendation engine — could integrate DFOS identity without touching DFOS content:

1. User signs in with their DID (local signing or consent page)
2. App verifies the signature against public keys
3. App has a stable, verifiable user ID — zero access to spaces, content, or social graph
4. If the DID has a public profile, the app resolves their name and avatar. If not, the user builds a local profile keyed to their DID

Identity travels. Content doesn't.

the exfiltration question

Authenticated API access that acts as a user — reading their spaces, content, memberships — is a separate and harder problem. The risk isn't technical; the API correctly scopes to what the user can see. The risk is social: someone builds a reader app and mirrors dark forest content to the open web. Members of those spaces didn't consent to that.

This needs to be gotten right. Space-level API policies, conservative defaults, no bulk export surfaces. Worth its own post and conversation.

---

The rough sequence in our heads: lib-dfos first, public DID registry and identity proofs after, public profiles alongside. Each piece depends on the others.

What are you trying to build? What identity primitives would you need? What flows would make your integration work? This is the place — let's figure it out together.