SONIC: Breaking the Walled Gardens of Social Media with Distributed ID Management

TL;DR

The SONIC project tackles the ultimate "lock-in" of social media: the domain-bound identity. By introducing GlobalIDs—identifiers derived from cryptographic keys rather than platform domains—and a Peer-to-Peer Global Social Lookup System (GSLS), SONIC allows users to migrate their entire social presence between different platforms without changing their handle or losing contact with friends.

Background: The Interoperability Crisis

In the current OSN landscape, your identity is a subset of a corporation's database. If you leave a platform, your "ID" ceases to exist. While protocols like OpenID or WebID attempted to bridge this, they largely depend on the Domain Name System (DNS), which is inherently hierarchical and tied to specific service providers. SONIC positions itself as the foundational layer for an Online Social Network Federation (OSNF), where the user, not the provider, owns the identity.

The Problem: Why Can't We Just Leave?

The paper identifies three critical pain points:

1. Domain Dependency: Identifiers like alice@facebook.com are invalid the moment Alice moves to twitter.com.
2. Centralization: Current lookup systems are controlled by single entities that can revoke access or monetize data.
3. Migration Friction: Moving data is hard, but moving identity—the way people find you—is currently impossible without starting over.

Methodology: The Global Social Lookup System (GSLS)

The core of SONIC is the decoupling of ID Generation from ID Resolution.

1. GlobalID Generation

Instead of a username, a GlobalID is generated locally by the user:

• Mechanism: A 256-bit hash derived from an RSA Public Key and a random 8-byte salt using PBKDF#2.
• Result: A platform-agnostic string (e.g., 2UZCAI...) that serves as a permanent anchor.

2. The Social Record & GSLS

The system uses a Distributed Hash Table (DHT) based on the Kademlia algorithm. When a user joins a platform, they publish a Social Record to this DHT.

• Integrity: Every Social Record is wrapped in a JSON Web Token (JWT) signed by the user's private key. The GSLS nodes verify the signature before storing the data.
• Discovery: To find "Alice," a client queries the DHT with her GlobalID. The DHT returns her current platform URL.

Experiments & Results

The authors implemented the GSLS using TomP2P and evaluated it on a distributed testbed.

• Read Performance: Outstanding. With a median response of 14ms, resolving an ID is nearly instantaneous, making it viable for real-time social applications.
• Write Performance: Moderate. Publishing a new record takes about 1.03s (median). While much slower than reads (due to DHT propagation and cryptographic verification), identity updates are infrequent, so this is a negligible bottleneck.

The study also introduced the SONIC App, an Android-based tool that allows users to manage their keys and scan QR codes to exchange GlobalIDs—bridging the gap between peer-to-peer theory and mobile utility.

Critical Insight: Security and Collisions

A common critique of decentralized IDs is the risk of collisions or "identity squatting." SONIC addresses this by:

1. Iterative Hashing: PBKDF#2 with 10,000 iterations makes brute-forcing IDs computationally expensive.
2. Fixed Salt Length: By limiting the salt to 8 bytes, they prevent attackers from manipulating the salt to create "vanity IDs" or collisions. The math suggests an attacker would need $4.8imes10^{37}$ attempts for a mere 1% chance of a collision.

Summary & Future Outlook

SONIC successfully demonstrates that a domain-independent identity is not only possible but performant. By utilizing DHTs and client-side cryptography, it fulfills the "Single Profile Policy" required for a true federation.

Limitations: The current implementation's reliance on RSA-2048 might be surpassed by Elliptic Curve Cryptography (ECC) for better performance on mobile. Furthermore, while the technology exists, the social challenge remains: convincing dominant platforms to adopt an open API that facilitates their own users' exit.

Future Work: Integrating this into protocols like ActivityPub or Decentralized Identifiers (DIDs) could be the next step in standardizing OSNF.