Rashid Aziz: Extending ATproto for private data

Rashid Aziz gives a talk about extending ATproto for private data at ATmosphere Conf 2025 in Seattle.

Basic Tech profile: https://bsky.app/profile/basic.tech

I’m Raz, and I really like bookmarking things — probably too much. On my home screen I have hundreds of saved links, hundreds of YouTube videos in my “watch later” list, and so many Chrome tabs open that the app stopped counting and just shows a smiley face. They’re all tabs I intend to get back to someday.

Naturally, I was disappointed that Bluesky and ATproto don’t have bookmarks yet. So I decided to fix that, mostly because I clearly need even more bookmarks in my life.

I built a Chrome extension that adds a bookmark icon next to each post in the Bluesky web app. When I click it, the post gets saved to my bookmarks, and I can browse everything I’ve saved in a sidebar. It’s simple, but it works well.

What’s even more interesting is that ATproto is a permissionless protocol, which means other clients can build on top of it. I wanted the same bookmarking system to work in other interfaces, so I built a separate client called Cozy Sky. It has my feed, and it also has a bookmarks page that shows the exact same saved posts. I can bookmark something in Cozy Sky and see it in the Chrome extension, or bookmark something in the browser and see it in Cozy Sky. And all of these bookmarks are private — that’s the main point.

To push the idea further, I also made a small API viewer app. It reads from the same private store, so I can see all my Bluesky bookmarks in this completely separate application. This demonstrates the interop: different apps, same identity, same private data layer.

This all depends on a concept Boris mentioned once: protocol composition. The idea is that different protocols can work together, becoming greater than the sum of their parts. You can take the public social data of ATproto and combine it with a protocol for private data, and suddenly you can build things that weren’t possible before.

The protocol I’ve been developing for private data is called Basic. It’s an open protocol for user-owned data, similar to ATproto but with all PDS data private by default. Your ATproto PDS remains your main source of identity and public posts. The client then talks directly to your Basic PDS for private data, without any relay in the middle. That’s how my bookmark system works: public identity through ATproto, private bookmarks stored through Basic.

In the private data discussion earlier, someone mentioned an interesting idea: what if your Basic PDS could appear as a service inside your ATproto identity record? You’d have your ATproto PDS for public data and your Basic PDS alongside it for private data — one identity, two data layers, both interoperable.

Another thing we’ve been experimenting with is schema lenses, which translate between different schemas using an LLM. You define the data shape you want — for example, a URL and a text field — and the system determines which lexicons or schemas correspond to that. Even if one system calls something “text” and another calls it “textValue,” the lens figures out what you meant and returns the data. This could be a powerful bridge between ATproto lexicons and Basic’s schemas.

If you’re interested in any of this, feel free to say hi or message me on Bluesky.