Headjack vs the competition

This chapter focuses on the disadvantages of some of the more high-profile competing solutions in the space. Most of the issues are solved in Headjack due to its guiding principles & design goals. This page doesn't list any of their positives as it would be too long (so not exhaustive by any means) but many of them have served as an inspiration for Headjack in one way or another.

Comparison table

Some of this is a subjective estimation - many of the claims lack official sources.

Headjack Farcaster DSNP & Frequency Bluesky & AT Protocol TBD web5
slides & tweet		 Ceramic & CyberConnect Lens
Protocol
blockchain-related properties
Scalability & potential scope can handle billions of users (proof) & underpin the entire web perhaps up to ~10 million - could move to its own rollup perhaps up to a few million graph changes are on-chain centralized consortium of servers perhaps up to
a few million - lots of reliance on IPFS, DHTs, hashes & keys		 perhaps up to
a few million - lots of reliance on IPFS, DHTs, hashes & keys		 actions are on-chain as NFTs (follow, post's hash) - even a dedicated EVM chain will be futile
Users paying for TX fees & linking identity to financial accounts by default all blockchain costs are paid for by services by default Ethereum L1 costs initially planned for subsidy by services all blockchain costs are paid for by services by default centralized consortium of servers - no TXs the anchors (on-chain Merkle roots) get batched with others only the stream anchors to Ethereum L1 have to be paid for occasionally yes
Blockchain TX fee stability & predictability as scalable as necessary => no congestion Ethereum L1 - may need to migrate to its own rollup in the future their notion of capacity is probably good enough centralized consortium of servers - no TXs Bitcoin TX fees are low due to low economic activity Ethereum L1 for stream anchors Polygon PoS
Block time for anchoring key operations Ethereum ZK validium with multiple blocks in one L1 slot Ethereum Polkadot centralized consortium of servers Bitcoin Ethereum, but the anchors are occasional Polygon PoS
Time to finality for key operations Ethereum Ethereum Polkadot centralized consortium of servers Bitcoin Ethereum Polygon PoS
Contains a name registry for easy discoverability & can replace DNS yes - & tightly integrated with addressability - URIs aren't broken even if names change ownership yes, also works with ENS no, but might introduce it no - uses email-like usernames resolved with Webfinger to a DID & relies on DNS (centralized) no no, maybe works with ENS no, maybe works with ENS
Decentralization for the most important parts (keys & registries) Ethereum ZK validium with external data availability (validium) - EigenDA? Ethereum Polkadot - not big enough set of validators centralized consortium of servers Bitcoin, but DID operations are only anchored Ethereum, but only the stream anchors go there Polygon PoS
Incentive layer & data availability for the most important (keys & registries) Ethereum ZK Validium Ethereum Polkadot centralized consortium of servers DID operations are stored in a network on IPFS without incentives the actual streams are in a network w/o incentives Polygon PoS
Data availability, storage, retrievability & addressing
Human-readable & persistent URIs for data without any hashes URIs full of hashes (probably) URIs full of hashes URIs full of hashes - CIDs for IPLD objects URIs full of hashes (probably) URIs full of hashes URIs full of hashes
Multiple ways to ask for a URI's document
(in addition to caches/archives)		  multiple ways:
 1) user's IDM
 2) source app identifiable from the URI
 3) IPFS blob from the block
 4) p2p network		  1) user's Hub
 2) p2p network		 URIs contain only user id & content hash without user Hubs (yet) & p2p network  1) user's PDR
 2) maybe p2p network with the content CID		  probably
 1) user's DWN
 2) p2p network		 only p2p network as Ceramic streams are an abstraction over IPFS unsure - maybe the on-chain NFT post
Big reliance on a p2p network for delivering fine-grained messages using a p2p network for specific URIs is the last resort using a gossip-based pubsub protocol between peers & Hubs not sure: their URIs contain only user id & content hash but they don't have an IDM/Hub/ PDR/DWN as a concept (yet) no - talk directly to a user's PDR not sure: perhaps could directly talk to a user's DWN yes - IPFS, Ceramic Network & global DHTs
Push (broadcast) vs pull (polling) for fetching new content both - event batches are broadcasted & new/individual documents can be requested pull only - requires polling a user's Hub for anything new both - event batches are broadcasted & new/individual documents can be requested pull only - requires polling a user's PDR for anything newpull only - requires polling a user's DWN for anything new both - events are broadcasted & new/individual documents can be requested
Self-authenticating documents proofs are validated by the blockchain need to talk to Ethereum AND the host-certified user directory which can disappear OR change merkle roots not present proofs are validated by the transparency log
Ease of use for developers & users
Can leverage existing Web2 authenticating infrastructure Can leverage all existing OAuth / SAML code
Easy to work with mental model vs high cognitive load & complexity A bit more complexity compared to Web2
Can use "custodial" hosted services while retaining ultimate control
Ease of indexing & building responsive UI can be as performant as Web2 and not constrained by block time

[1] [2]

1. X. ↩
2. X. ↩

What other projects get wrong

A list of problems with the contenders in the decentralized identity/media space:

  • No credible path to web-scale - some will hit a wall even at 1 million users. Most are vague around their scalability & data structures and don't put it front and center - obfuscating the most important bit. Instead of focusing on NFTs & developer APIs, start with the data and work up from that.

  • Complexity & lack of clarity - distributed systems engineers should easily figure out how they work & what the limitations are. Why build on something that others are probably having a hard time understanding as well and may not be around in the future?

    "Developers care about risk." - Haseeb

    "For the simplicity on this side of complexity, I wouldn't give you a fig. But for the simplicity on the other side of complexity, for that I would give you anything I have." - Oliver Wendell Holmes

  • Too financialized & trying to do too much - profiles & posts as NFTs, microtransactions, marketplaces, fan coins, tipping, content creator incentives.

    "However, a downside I’ve observed in social networks where content is monetized is that user behavior becomes transparently driven by monetary incentives in ways that feel less genuine. This applies to influencer culture on Instagram as well, but cryptocurrency social networks bake it in from the start." - Jay Gerber

    "The question remains: is the future of social media truly intrinsically linked to NFTs or is it a red herring?" - @mattigags

  • Users shouldn't need to use a token, use a wallet, or self-host to benefit from decentralized identity & an open social graph. Most people will always use custodial services.

    "People don’t want to run their own servers, and never will." - Moxie

  • Linking online identity to public financial accounts on Ethereum/Solana/etc will have unintended consequences - a bad default.

  • Federated ones lack logical centralization which leads to fragmentation and no discoverability.

  • Some are solving just identity & the graph - without easy & persistent content addressing.

  • Social media is about aggregated views at scale - not p2p and direct comms.

    "The emphasis of a social network is on "propagation" aka, propaganda." - didibus

  • Some use chains such as Ethereum for logical centralization & store vector commitments (Merkle roots) for events around key management (rotations, authorizations, sessions & revocations) but the data availability problem for whatever is committed is unsolved.

    • The complexity is not encapsulated - there are many open questions, edge cases & failure scenarios and it would inevitably lead to assumptions & trust.
    • Some anchor to Bitcoin but the time to finality matters a lot for UX - 10-minute block times with probabilistic finality is horrendous.

  • Some lack an economic incentive layer.

    "Show me the incentive and I will show you the outcome." - Charlie Munger

Farcaster

Their architecture: link. The account registry is on a blockchain and everything else is off-chain.

  • Registry on Ethereum L1 - for new accounts, name/host changes & key management.

    • No plans on moving to an L2 or their own chain. Also, state rent could eventually be introduced to Ethereum which would lead to further costs & complexity.

  • Keypairs & wallets required - harder mass adoption. Authorizations still require a signature from the root key.

  • Revocations invalidate all prior activity from a delegate:

    "Unfortunately, this means that all messages signed by that signer will be lost since we cannot tell which ones were signed by the attacker." - source

  • The p2p network's ability to scale by passing around granular casts is questionable - they are already discussing possible flooding and nodes having to shadow ban and flag accounts based on behavior.

  • Focus is on partial views of the network as opposed to mass scale aggregation & indexing - although that could easily be implemented.

  • Cast URIs will look something like farcaster://id:8789213729/cast:0xf00b4r which is less readable than what Headjack will be offering with its addressing.

Overall good intuition about the concept of sufficient decentralization (putting only what is absolutely necessary on a blockchain) but the p2p node implementation takes on too much responsibility, complexity & assumptions (consensus, CRDTs, trees, ordering, flooding & replay attacks, etc.) and is lacking in other areas.

DSNP, Frequency & Project Liberty

Frequency (a Polkadot parachain) is the first implementation of DSNP (Decentralized Social Networking Protocol - whitepaper) as a standalone blockchain and has had the most influence over Headjack's design but the two have diverged in some key respects - the biggest of which are scalability, content addressability, UX & choosing Polkadot. Some of the problems with them:

  • No names within the project - just integer IDs for accounts. Content addressing URIs are based on hashes without connection to the batch # / service that published it - example: dsnp://78187493520/0x1234567890abcdef0123456789abcdef0123456789abcdef (source). Addressing content is much worse compared to Headjack's human-readable & persistent URIs.

  • Delegating applications to be able to post on behalf of users (analogous to authorization in Headjack) happens on-chain but requires a signature from the user (bulky - limiting throughput). New applications (& revocation) require the user to have access to their keys. Hierarchical delegation would allow for UX comparable to Web2 and would even allow for users without keypairs at all but DSNP doesn't have that - Headjack does.

  • 100m$ of funding (so far) from just 1 person - Frank McCourt - no other capital & connections to reputable investors & influencers from either the crypto or tech space - generating hype & booting up the network effect might be very hard. They've been around since 2019.

TBD

Jack Dorsey's new "web5" project - slides, announcement.

  • Only anchors DID events to Bitcoin with vector commitments (Merkle roots) using ION & the Sidetree protocol.
    • 10-minute block times with probabilistic finality. Factor in the loading times for the anchored content around key management that's on IPFS - not great at all if you want to log in/authorize a service or revoke access quickly.

  • Doesn't have a human-readable global name registry - lacks discoverability.

  • Doesn't have human-readable content addressing.

  • Focus is on users self-hosting their own data, running software locally & handling keypairs.

  • Developing their own Decentralized Web Nodes (DWN) software that would be relaying messages p2p - can't handle web-scale on such a granular level and aggregation is not even in the picture.

CyberConnect

Built on the Ceramic protocol & network.

TODO: working on incentives for pinning https://twitter.com/joelthorst/status/1588863780301156352

  • Requires the use of keypairs & wallets.

  • Every user has their own Ceramic data stream on top of IPFS - it is yet to be proven that the DHT & p2p layers can scale to hundreds of millions or billions of people.

  • The persistence of the social graph is handled by pinning IPFS data on nodes operated by them without any cryptoeconomic incentive for the data availability - it will grow into the tens/hundreds of terabytes for web-scale (Twitter scale: 400M users with 700 connections on average) - especially because they don't have a compact integer-based representation and everything is based on big individually signed actions. The upcoming Ceramic blockchain does not seem to be geared towards storage incentivization and will not be the solution to that.

    "Long-term data retention on CyberConnect is guaranteed through Ceramic’s blockchain anchoring and a custom data pinning service." - source

DeSo

  • It requires wallets & users to pay for every interaction.

  • It puts everything on-chain and their plans to scale are with bigger blocks & sharding (see "Phase 4: Sharding") which is simply not practical for the true scale of the public web.

  • It financializes as much as possible (creator coins, etc.).

  • Their initial growth was fueled by huge sums of VC money but by now it has flatlined. It did reach 1.66$ billion market cap on the 2nd of October 2021 shortly after being listed.

Others

For details about ActivityPub, Matrix, Diaspora, Mastodon, Secure Scuttlebutt, Solid & others please refer to the excellent ecosystem review by the Bluesky project. Other good resources include: