Slashtags

What Slashtags was

Slashtags (2019–2024) was a JavaScript implementation of a key-rooted P2P identity and data layer built on top of Hyperdrives (personal append-only file drives) and Hyperswarm (a Kademlia-based DHT with UDP holepunching). The same team (Synonym) later reworked the core idea into PKARR (signed DNS records on the Mainline DHT) and Pubky Core (a production protocol suite with SDKs, homeservers, mobile key custody, and a social graph). The current Slashtags transition to Pubky Core website now redirects to Pubky Core and states:

"Slashtags is now Pubky Core, which provides infrastructure for decentralized identity management, data routing, and hosting."

So Slashtags as a standalone product is winding down. The historical value of studying it is the design pattern: the same architectural choices that Slashtags made in 2019 — BIP-39 mnemonics, Ed25519 keypair, hyperdrive-backed data, Hyperswarm for discovery — reappear in modern PKARR/Pubky in a more focused, less ambitious form.

Architecture

The Slashtag

A Slashtag is an Ed25519 keypair derived from a BIP-39 mnemonic seed (the same as a Bitcoin wallet's seed phrase). The user controls one Slashtag (one identity); within that Slashtag, the user can derive multiple hyperdrives by name (a "drive name" + the master key).

Discovery

The discovery key is blake2b(public_key). A Slashtag's discovery key is published into the Hyperswarm DHT, which is a Kademlia-like network with UDP holepunching. Peers interested in the Slashtag (e.g., contacts) listen on the discovery key, get connected to peers that have the data, and exchange.

This is conceptually similar to PKARR — both publish a public-key-derived identifier into a DHT and resolve it to peers — but the underlying DHT is Hyperswarm rather than the Mainline DHT, and the data model is hyperdrives (file drives) rather than signed DNS records.

Hyperdrives

A hyperdrive is an append-only log of blocks, similar to a content-addressed log. Slashtags uses hyperdrives for:

• Profile data: name, avatar, contact info, payment preferences.
• Public / private feeds: social media style.
• Contacts lists: who the user has added.
• Account metadata: per-service data for Slashtag-enabled services.

The hyperdrive is signed: only the Slashtag's private key can add a new block. Other peers need the drive’s public key to open and verify it. A discovery key identifies the swarm but does not by itself grant read access. Sharing means handing over the public key (or its URI form).

Access control

This is a simple read-public / write-private model. Public writes mean the Slashtag operator's signature is required for any update; any peer can mirror and distribute.

Data integrity

Each block added to a hyperdrive is committed via a Merkle root. The Slashtag owner signs the root; the signature is verified before the block is added. This is the same Merkle-anchored commit pattern that hyperdrives use in their own protocol, and it ensures that a drive's content history is consistent and tamper-evident.

The historical progression: Slashtags → PKARR → Pubky Core

The conceptual through-line is unbroken: key-rooted identity, signed data, DHT discovery, no registrar, no chain, no fees. What changed between Slashtags and Pubky Core was the choice of DHT (Hyperswarm → Mainline), the data model (hyperdrive → signed DNS records + homeserver KV), and the platform support (JS only → multi-language SDKs + mobile + social app + indexing).

Why the Slashtags design is still worth studying

1. BIP-39 mnemonics as identity seed. A Slashtag's key is derived from the same 12/24-word seed a Bitcoin wallet uses. The user has one mnemonic, multiple Slashtags (different keypairs derived from different BIP-39 derivation paths). This is the same pattern FROST and threshold-custody schemes often use.
2. Hyperdrives as a content model. Append-only logs with Merkle-anchored commits are exactly the structure that social applications need (immutable history, signed by the user, replicated by peers).
3. Read-public / write-private. Slashtags made this default; the same idea persists in Nostr (events are public, signed by the user) and PKARR (records are public, signed by the key).
4. No chain, no token, no registrar. A consistent philosophy across all three generations.

Slashtags in production: Bitkit

The primary production use of Slashtags was the Bitkit wallet (formerly Synonym's P2P Bitcoin wallet). Bitkit used Slashtags to power:

• User profile (avatar, display name, contact info).
• Contacts list (P2P, no central server).
• Payment preferences (Lightning address book).
• Authentication (signed in to Slashtags-aware services with the wallet key).
• Private / public feeds (encrypted to contacts).

With the move to Pubky Core, Bitkit is one of the early wallets that will integrate PKARR-based discovery. The conceptual compatibility makes the migration straightforward.

What was harder about Slashtags

1. Limited language support. JavaScript only at the protocol layer. Rust SDKs came later via PKARR, and even later for full Pubky Core (Rust / JS / Swift / Kotlin).
2. Hyperswarm DHT scale. Hyperswarm is excellent for small-to-medium-scale P2P apps but not as ambient as the Mainline DHT (which has ~10M nodes and 15+ years of uptime).
3. Hyperdrive storage overhead. A hyperdrive is heavier than a signed DNS record; mobile devices and low-resource peers struggled to maintain full hyperdrive replicas.
4. DHT reachability in hostile networks. Both Hyperswarm discovery and the BitTorrent Mainline DHT use UDP. UDP restrictions can affect either network.

These four issues are the technical reasons for the move to Mainline DHT + signed DNS records in PKARR. The lessons carried forward; the engineering substrate changed.

Trade-offs (historical snapshot)

Strengths of Slashtags

• Single mnemonic, multiple Slashtags — clean key-derivation story.
• Hyperdrives gave a familiar file-system-like mental model.
• No chain, no token, no fees.
• Read-public / write-private was a natural privacy model for social apps.
• DHT discovery worked without any server-side infrastructure.

Limitations of Slashtags (relative to modern Pubky Core)

• JS-only SDKs; no first-party mobile or Rust.
• Hyperswarm DHT is less ambient than Mainline.
• Hyperdrives are heavy for mobile and small devices.
• No production homeserver; data lived in P2P networks.
• Limited tooling for indexing / social-graph queries.

Use cases (then and now)

Evidence at a glance

Recent developments (2023–2026)

• Slashtags → Pubky Core transition (2024–2025): Synonym formally redirected Slashtags branding to Pubky Core. The Slashtags npm packages still exist for backwards compatibility, but new work is on Pubky.
• Bitkit wallet integration with Pubky Core (2025): Bitkit is one of the early wallets building PKARR-backed identity.
• Community history in PKARR/Pubky docs: Slashtags is cited as the conceptual predecessor in PKARR's design notes.

Primary sources

• Pubky Core: current project
• Slashtags implementation
• Slashtag package source
• Slashtags key derivation specification
• Bitkit source
• Slashtags authentication example
• Hyperswarm implementation
• Hyperdrive implementation
• Maymounkov and Mazières: Kademlia
• BEP 5: BitTorrent DHT over UDP
• Slashtags transition to Pubky Core

Also in Identity, Social and Trust