Nicolas Gimenez

Decentralized Deliberation Standard (DDS) An open protocol for sovereign, verifiable, interoperable, and resilient deliberation.

Since then, it has evolved into its own nascent working group:
www.dds.xyz
Welcome to join

That being said... The next wave of AI breakthrough is going to kill software engineers for sure. And every other intellectual jobs with it.

Not going to happen before at least a decade probably?

With world models maybe? I don't know enough about AI research to say.

LLM won't kill software engineering. Quite the opposite. So much more work is FINALLY at reach. Things were so slow before. It's still kinda slow now, but we can build so much FASTER!

As a founder and a builder with so many ideas I have no time to work on (even now), it's super exciting!

🙏

Every such announcement is incredible news for everyone building in the Atmosphere. No better way to signal that atproto is an ecosystem worth investing in.

Huge congrats to @anirudh.fi and @oppi.li you guys rock!

Group photo of some of the people involved in DWeb Camp. Full list and info on https://dwebcamp.org/people

Brewster Kahle in a fireside chat with Wendy Hanamura

Mai telling the story of DWeb Camp

Photo from the little garden outside of c-base

Here is (part of) the team that is making #DWebCamp happen.

We had some truly insightful conversations at @c-base.org yesterday, thank you to all who participated!

For those who are interested but were not able to join, please stay tuned. More coming soon!

Tickets on sale from the 9th March 2026.

Have to experiment. (But no time right now...)

But this is not realistic. It's a huge protocol change.
So I'll probably go with did:key within Lexicon data with the higher level origin being the Appview self-managed did:plc.
Kinda worried about rate-limits on the single did:plc. Maybe I will have to batch did:keys guests in several did:plc hosts

The simplest approach would be for atproto to support did:key instead of did:plc. And then allow upgrading/merging did:key guest accounts into did:plc/did:web accounts.

What's more important is to give users their root recovery key client-side so they can walk away without asking for permission.

It's a cool technology.

But I'm not sure that protecting users against third-party PDS providers forging posts is the right threat to optimize for.
See bsky.app/profile/nico... for my reasoning.

You get the identity sovereignty that matters most without running infrastructure or worrying about where your data is stored and by whom.

AT Protocol already makes migrating between providers far easier than switching email hosts. Option 3 just ensures you're always the one deciding when to move.

This is why option 3 is the crucial middle ground.

A rotation key in your password manager turns "you can leave" from a theoretical right into something almost anyone can exercise, without permission, at minimal UX cost.

For this purpose, AT Protocol brillant idea is to allow you to host your PDS to your own infra, cheaply.

But it's still heavy: you need to run infrastructure, pay for it, and maintain uptime.

Most people won't do that, including techies.
But when they finally need it, it might be too late.

But we still need to have a credible exit from third-parties altogether. At least as an option.

Imagine a bad actor acquires your PDS provider. Without owning the rotation key, you're stuck. The provider controls your signing key AND your identity.

You'd need to act fast, and most people won't.

AT Protocol makes a different bet for the vast majority of people: trust your PDS operator the way you trust your email provider.

With a clever design: you can choose whichever operator you trust, and migrate among them. The incentive structure of PDS operators makes forgery self-defeating anyway.

But transplanting it to social networking optimizes for a threat that has no precedent and no clear incentive. What social app would forge posts under your name?

Users would notice content they didn't write. The provider's reputation would be destroyed. It's a self-defeating attack.

I think Nostr's choice here comes from its Bitcoin roots. In Bitcoin, self-custody is fundamental: nobody should ever sign transactions on your behalf.

That's a sound principle when we're talking about money.

This is the core architectural difference from Nostr. In Nostr, you and only you hold the signing key.

Nobody can author content as you, period. The cost is steep: your key is your identity, you need specialized software to manage it, and there's no "forgot password" recovery.

Even with option 3, a fundamental property of AT Protocol doesn't change: your PDS holds your signing key and can sign content on your behalf.

Keeping a rotation key client-side makes walking away easier, but a malicious provider could still forge posts under your name until you rotate.

#3 obviously comes with security considerations. Managing keys and passwords isn’t trivial.

But it's manageable for some, more than self-hosting a PDS.

So #3 should be a standard option, not mandatory, but commonly offered.

Most people don't want the hassle of #2, even technical users. So we risk ending up with a more fragile, centrally controlled network.

This is somewhat mitigated by the fact that multiple third parties now offer PDS hosting, not just Bluesky.

But you're still trusting a third party.

I'd like this to be commoditized. Users should have three options:

1. Trust a third party to manage your keys in your PDS

2. Self-host your PDS and manage the keys yourself

3. (New) Use a third-party PDS but keep a copy of the root rotation key client-side (e.g., in your password manager)

UCAN - User Controlled Authorization Network A trustless, secure, local-first, user-originated, distributed authorization scheme.

Guests sign ucan.xyz to authenticate with their client-side keys. All of this was inspired by @fission.codes previous work.

The pure ephemeral guest use-case is also valid and should be defined with the style of mechanism you mention: suppression of session client-side after interactions.

2. Agora uses the WebCrypto API to generate P-256 or RSA keys whose private parts are un-extractable from JS. secp256k1 is not compatible with WebCrypto so it would be extractable in plain JS, reducing security. But I don't see why DDS would mandate any particular keypair in the spec itself.

...These users may come back to the same convo later (it lasts months sometimes) and re-participate with the same device, still without logging in formally. We don't want to count them twice so it's good to keep the session active until at least the convo is closed.

Interesting take. Similar to how it's implemented in Agora except:

1. users appear as Guest and may want to upgrade later (not really ephemeral, just a soft account). They keep their session with history for longer...

Thank you!

Decentralized Deliberation Standard (DDS) An open protocol for sovereign, verifiable, interoperable, and resilient deliberation.

We're working on this for dds.xyz, but it feels like something that should exist on its own, at the protocol level.

Curious if anyone else has run into this, or if there are ideas floating around.

It needs to be possible for guests to upgrade to a full account and keep their history.

Either by merging the guest content into an existing account, or by creating a brand new account and transferring the guest data to it.