Summary of 1025: The Open Web's second chance (w/ Dan Abramov)

Overview of 1025: The Open Web's second chance (w/ Dan Abramov)

In this episode of Syntax, Wes and Scott talk with Dan Abramov about the AT Protocol (often shortened to atproto), the open, app-agnostic data layer powering Bluesky and potentially much more. Dan argues that atproto is less about social media and more about bringing back a more people-centric, open-web model where users own their identity and data, while apps act as consumers and presenters of that data. The conversation covers how the protocol works, why it matters, how it differs from Mastodon/ActivityPub, and what kinds of new apps and workflows it enables.

What AT Protocol Is

Dan frames AT Protocol as a data and identity layer for the web:

• Every user gets a web identity with:
  • a handle
  • a storage location for their data
  • a public key for verification
• Content lives in the user’s own repository/folder, not locked inside one app
• Apps read from and write to that data, but the source of truth stays with the user

The big idea: instead of giving platforms control over your content, the protocol makes your data more like a personal folder that different apps can sync with.

Why It Matters

Dan’s core argument is that the modern web has become fragmented into walled gardens:

• Users create content on platforms like Twitter/X, Reddit, GitHub, Stack Overflow, etc.
• Those platforms eventually control the data, APIs, and user experience
• If you leave, you often lose access to your content or audience

AT Protocol tries to restore the web’s original spirit:

• open linking
• portability
• permissionless interoperability
• user-controlled identity and storage

In short, it aims to make the web more like the early internet again, but with modern app experiences.

How It Works

Apps vs. Hosting

A major theme of the discussion is the separation between:

• Apps: the user-facing experience
• Hosting: where the actual records/data live

Examples Dan mentions as possible AT Protocol apps:

• Bluesky
• Tangled (GitHub-like)
• Reddit-like or Stack Overflow-like apps
• blogging/microblogging tools
• music tracking apps like a Last.fm-style service

Apps don’t own the data; they consume and sync it.

Records, JSON, and “Folders”

Data is stored as JSON records in user repositories, organized by type and app-specific schema. For example:

• a post
• a follow
• a like
• a blog entry
• a music scrobble

This makes the protocol feel like a web of linked JSON files that apps can interpret.

Streams and Indexing

Apps subscribe to events from hosts, then:

• ingest relevant records
• build their own databases/indexes
• run feeds, rankings, search, recommendations, moderation, etc.

So the protocol handles the open data layer, while apps still provide the “product” layer.

Schema and Interoperability

AT Protocol does not try to force everyone to agree on one universal definition of “post” or “comment.”

Instead, it provides a schema system called Lexicon that lets app developers define their own data types.

Benefits:

• strongly typed data
• generated TypeScript types and parsers
• app-specific formats without losing interoperability
• the ability for multiple apps to standardize voluntarily when useful

Example: “Standard Site”

Dan describes a grassroots standard where multiple blogging apps agreed on a shared schema so their posts could appear across apps. That led to:

• cross-app publishing
• shared readers/aggregators
• branded embeds
• third-party tools publishing into the same ecosystem

This is one of the most compelling parts of the protocol: standards can emerge organically rather than being imposed top-down.

Public Data, Deletion, and Privacy

Right now, AT Protocol is mostly focused on public data:

• content is openly readable
• there are tools to inspect repos and records
• deletion signals can propagate, but the system is still fundamentally public-first

Dan notes that private or closed-group use cases are being explored, but they’re not the main focus yet.

Important nuance:

• deleting data on your host can broadcast a deletion event
• but like screenshots on today’s web, a malicious actor could still retain copies

Media, Videos, and Large Files

The protocol supports blobs for media:

• images
• videos
• other binary data

Records can reference blobs by hash.

That said, media storage raises practical questions:

• video is expensive
• hosts may have different storage policies
• some media may need to live outside the protocol or be handled by extensions

Dan suggests this is flexible: you can use AT Protocol for just identity, or for identity plus content, depending on the app and host.

How It Differs from Mastodon / ActivityPub

Dan gives a clear contrast with Mastodon:

Mastodon / ActivityPub

• each instance is a separate “mini-Twitter”
• your identity lives inside that instance
• federation is message-passing between servers
• fragmentation and instance politics can affect reach

AT Protocol

• identity and data are portable
• the app is separate from the data host
• users can change hosts without losing their identity/content
• apps can interoperate over a shared data layer

His rough mental model:

• Mastodon feels like many disconnected kingdoms
• AT Protocol feels more like the web itself, with open links and shared data

Comparison to RSS and the “Open Web”

Dan repeatedly compares AT Protocol to RSS:

• RSS gave creators ownership of their source
• readers/clients could aggregate content
• Google Reader-style apps could build rich experiences on top

He sees AT Protocol as a modern extension of that idea:

• RSS-like ownership
• but with modern app interactivity and social features
• without requiring everyone to hand data to a single platform

AI, APIs, and Scraping

Dan argues AT Protocol is especially interesting for AI and data tooling because:

• the protocol itself is effectively the API
• you can query public data directly from hosts
• a read-only archive can ingest and expose the network at scale

This means:

• no dependence on a platform’s proprietary API
• better support for analysis, indexing, and cross-app queries
• a more scrape-friendly web by design

He also notes the philosophical shift:

• if content is public, it’s public to everyone
• open systems should assume scraping is happening
• better to design for it than pretend it won’t happen

Moderation, Spam, and Abuse

The hosts raise concerns about bots, spam, and abuse.

Dan’s take:

• open systems can improve shared moderation and detection
• communities can share tooling, indexes, and reputation signals
• protocols can enable things like vouching systems

He mentions that some projects are experimenting with:

• trust/vouch records
• shared moderation data
• community-driven reputation signals

But he also acknowledges the downside: bad signals can harm legitimate users if they’re too blunt.

Notable Examples and Emerging Projects

Dan highlights a few interesting apps and standards already emerging:

• Tangled — GitHub-like app on AT Protocol
• Leaflet / Offprint / Pocket — blogging apps using shared formats
• Standard Site — a shared blog/content schema
• Standard Reader — aggregator of Standard Site content
• Teal.fm — Last.fm-style project with a schema published before the full app exists
• UFOs — a tool that tracks emerging lexicons and trends across the network
• Vouching systems — protocols for users to endorse other users

These examples show the ecosystem is not just theoretical; people are already building interoperable software around shared data models.

Dan’s Current Work

Dan shares that he recently joined Vercel and is working on the Next.js team.

He says he’s focused on improving:

• developer experience
• performance
• memory usage
• navigation speed
• making server app transitions feel instant

He specifically mentions:

• a dev server memory improvement via disk cache eviction
• a feature called Instant Navigations
• better handling of suspense boundaries and shell rendering

Sick Pick and Shameless Plug

Sick Pick

Dan recommends listening to Thelonious Monk, especially:

• solo piano recordings
• Solo Monk

Shameless Plug

Dan plugs the upcoming improvements to Next.js, especially:

• reduced dev server memory usage
• Instant Navigations
• better performance and smoother app transitions

Key Takeaways

• AT Protocol is not just “Bluesky’s protocol” — it’s a general-purpose open web data/identity layer.
• The protocol separates identity, storage, and apps, giving users more control over their content.
• Lexicon lets apps define their own data types while still supporting interoperability.
• The ecosystem is already producing real cross-app standards like Standard Site.
• AT Protocol is designed to be scrape-friendly, portable, and open, which makes it appealing for AI, indexing, and new kinds of apps.
• Compared to Mastodon, it aims to feel much more like the open web and much less like isolated instances.