How Web5 and Bluesky are Building the Next Layer of the Web - A Comparative Analysis

Rizèl Scarlett - Aug 27 - - Dev Community

As companies increasingly commodify our personal data and privacy breaches make headlines, many technologists are creating user-centered frameworks that empower individuals to control their digital identities and personal information. This concept, known as Self-Sovereign Identity (SSI), enables users to decide what data they share and with whom. While blockchain technology is a popular choice for implementing SSI, companies like TBD are exploring (and even creating) alternative technologies to achieve these goals.

My Perspective on the State of SSI

Our efforts at TBD are part of a larger movement. In fact, there’s a consortium of tech giants and startups working together through the Decentralized Identity Foundation to establish open standards and best practices for SSI, focusing on:

  • Digital Identity
  • Interoperability
  • Data Ownership
  • Reliable digital verification methods

The SSI industry is making tangible progress, especially in government sectors, as our technological solutions support the advent of Mobile Driver's Licenses.

However, one of my concerns with our industry is every company is implementing varied proprietary methods. Despite aiming to solve similar problems, companies are developing their own unique DID methods, wallets, and tooling. This fragmentation raises questions for me:

  • Can we achieve widespread adoption with disparate systems?
  • Will the multitude of competing mechanisms overwhelm both users and developers?
  • Will our various systems eventually work in tandem?

In November 2023, I began investigating the answers to these questions through a livestream series where I interviewed SSI experts from different companies. After conducting approximately 30 interviews, these questions remain unanswered. However, I’ve gained more in-depth knowledge about:

  • Key players in the SSI space
  • Various technical approaches to implementing SSI
  • Real-world applications of SSI

Interviewing Bluesky

I most recently interviewed Dan Abramov, creator of Redux and React core team member, about his work at Bluesky and the development of Bluesky's underlying technology – Authenticated Transfer Protocol, or AT Proto for short. I learned that while TBD’s Web5 and Bluesky’s AT Proto share the vision of a decentralized and user-centric web, their approaches and underlying technologies offer a fascinating contrast. I'll examine these parallel approaches in hopes that TBD, Bluesky, and the broader community can gain valuable insights into building infrastructure for the decentralized web.

Building the Next Layer of the Web

Similarities

The web as we know it today consists of physical, network, transport, application, and data layers. Instead of replacing the existing architecture altogether, AT Proto and Web5 aim to add a new layer enabling data to exist beyond individual applications. Both provide tools for developers to build apps within their respective ecosystems.

Bluesky actually serves as a reference implementation to inspire developers and showcase AT Proto's potential.

Differences

AT Proto focuses on decentralized social media, while Web5 enables developers to build any type of application, from financial tools to social media to health management. For example, I developed a fertility tracking app during a hackathon to demonstrate personal health data ownership. Additionally, at TBD, we use components of the Web5 SDK to build the tbDEX SDK, an open financial protocol that can move value anywhere around the world more efficiently and cost-effectively than traditional financial systems.

Data Portability

Similarities

A common frustration with traditional web applications is that users often lose access to their data when a platform shuts down. Even if a user can export their data—say as a CSV file—it becomes static, no longer live or interactive.This data is essentially lost for most users, especially non-technical ones, as it's difficult to rebuild the ecosystem that once surrounded it. For example, moving from one social media app to another means users lose their followers, viral posts, and reputation and have to start from scratch.

Web5 and AT Proto enable users to take their data from one application to another. For example, if a user leaves Bluesky, which operates on AT Proto, they can migrate their data to another AT Proto-compatible app without losing their social connections or posts. Similarly, if an app built with Web5 were to shut down, a user could bring their data to another Web5 app.

Differences

Data portability on these platforms varies due to different data management approaches. AT Proto uses a federated model where each app operates a Personal Data Server (PDS). The PDS, typically managed by the app provider, stores all user data in a repository tied to the user’s identity. Users can move their repository—containing posts, social graphs, and more—between apps within the AT Proto ecosystem by connecting it to another PDS.

In contrast, Web5 depends on Decentralized Web Nodes (DWNs), which are personal data stores fully controlled by the user. To switch apps, users point the new application to their DWN and specify the types of data users of the app can access.

Use of W3C Standards for Authentication

Similarities

Both AT Proto and Web5 leverage the W3C standard called Decentralized Identifiers (DIDs), which are globally unique alphanumeric identifiers that can move with you across different applications. This enables users to maintain their identities consistently across platforms.

While DIDs are often associated with blockchain technology, both Web5 and AT Proto implement a blockchain-less approach. For instance, Bluesky uses a custom DID method called did:plc (DID Placeholder), while Web5 employs did:dht (DID Distributed Hash Table), which anchors DIDs on BitTorrent instead of a blockchain. Learn more about TBD’s DID method here.

Differences

Many developers have told me that the way AT Proto handles authentication is what attracted them to the Bluesky, but many of them don’t even realize that they’re using DIDs under the hood. On Bluesky, users can use one of their existing domain names as their username. Bluesky verifies ownership by performing a DNS lookup to make sure the domain belongs to the user. Once verified, the domain is linked to a DID, and the user is marked as verified on their account.

Web5 also uses DIDs for authentication but in a different way. DIDs eliminate the need for usernames and passwords. Instead, you can log in directly with your DID. This is possible because, in the Web5 ecosystem, every DID has cryptographic keys that securely prove ownership.

Permission Management

Similarities

Both AT Proto and Web5 offer permission management systems, but there are key differences in who can manage these permissions.

Differences

AT Proto takes an application-centric approach to permission management. Permissions are defined by applications using schemas called lexicons, which dictate the rules that the PDS follows. As a result, the extent of control users have over their data depends on the permissions set by the application.

Permission management is where Web5 shines. Users define access controls through JSON schemas called Protocols, specifying who can access specific data stored in their DWN. This is why building a fertility tracking app with Web5 was ideal for me: I could explicitly deny social media apps, marketing platforms, and retailers access to my personal health data, while allowing only my healthcare provider and partner to access it.

Special URLs for Data Access

Similarities

Most web users are familiar with URLs, which serve as web addresses to retrieve data online. Similarly, AT Proto and Web5 use their specialized URLs to access data within their ecosystems.

Differences

In AT Proto, special URLs start with the prefix at:// and point to data in a user's PDS.

Example: at://alice.com/app.bsky.feed.post/1234 might reference a specific post in a user's social media feed.

In Web5, Decentralized Resource Locators (DRLs) start with the prefix https://dweb and link to data stored in a DWN.

Example: https://dweb/${did}/read/records/${recordId} allows a user to fetch a specific record from a DWN.

Learn More

While I've described some core differences between Web5 and AT Proto, there are more interesting features to explore, including how Bluesky implements algorithmic choice, how Web5 uses W3C's Verifiable Credentials to prove digital identity, and how both platforms refer to individual data pieces as "records." These topics deserve their own deep dives. For now, I encourage you to continue exploring via:

🎥 Watch: My interview with Dan Abramov explaining Bluesky’s implementation

📚 Learn: Check out my SSI expert interview series called tbdTV

🤝 Join: Build with us and join our discussions on Discord.

. . . . . . . . . . . . . . . . . . . . . . . . . . . .