In 2010, the United States government seized the domain mooo.com—a URL
shortener popular with music fans and file sharers. Without warning, without trial, without due
process, the Department of Homeland Security simply took control of the domain and replaced the site
with a banner: "This domain name has been seized by ICE—Homeland Security
Investigations."
Thousands of links across the internet broke instantly. Blog posts, forum threads, social media shares—all pointed to dead URLs. The content those links pointed to still existed on other servers, but the naming system had been captured. The government didn't need to touch the actual files; they just seized the address that pointed to them.
This wasn't an isolated incident:
Libya (.ly domains, 2010): Shut down
vb.ly (URL shortener) for "violating Islamic
morality"
Kazakhstan (.kz, 2021): Temporarily seized opposition media domains during protests
Ukraine (.ua, 2014): Domains hijacked during Crimea annexation
China (.cn, ongoing): Routine domain seizures for political speech
The lesson: Even if you own your content, if you don't control the infrastructure that makes it accessible, you don't truly have Ground.
This chapter explores the political economy of digital infrastructure—who controls the layers that make the internet work, how that control is exercised, and how we might redesign those layers to resist capture.
We'll introduce the Sovereignty Stack: six layers of digital infrastructure, each with different ownership models and vulnerabilities. Then we'll examine case studies of each layer being captured or contested. Finally, we'll explore alternatives being built to resist centralized control.
Digital sovereignty isn't just about owning a domain or hosting a website. It requires control (or at least resilience) across six interconnected layers:
What it is:
Undersea cables carrying internet traffic between continents
Data centers housing servers
Cell towers and fiber optic lines
Electricity grids powering everything
Who controls it:
Telecom corporations (AT&T, Comcast, China Telecom)
Cloud providers (Amazon AWS, Microsoft Azure, Google Cloud)
Nation-states (can cut cables, seize data centers)
Sovereignty implications:
If you don't own physical hardware, you're renting from someone who can evict you
Governments can surveil traffic at chokepoints (NSA's undersea cable taps)
Interruptions (power outages, cable cuts) can take down entire regions
Vulnerability:
Centralization: Most cloud traffic flows through a few companies' data centers
Geographic concentration: Major cable landing points are in a few cities
State power: Physical infrastructure is ultimately subject to whoever controls territory
Resistance strategies:
Distributed hosting (content on multiple continents)
Peer-to-peer networks (no central servers)
Community-owned ISPs (fiber cooperatives)
Mesh networks (neighborhood-scale wireless networks)
What it is:
TCP/IP (how data packets move across networks)
HTTP/HTTPS (how browsers talk to servers)
DNS (Domain Name System—translates names like google.com to IP addresses)
BGP (Border Gateway Protocol—routes traffic between networks)
Who controls it:
Standards bodies (IETF, W3C—mostly open)
ICANN (manages DNS root servers)
ISPs and network operators (implement protocols)
Sovereignty implications:
Open protocols (like TCP/IP) are more sovereign than proprietary ones
DNS is a single point of failure—if your domain is seized, your site becomes unreachable
BGP hijacking can redirect traffic (happened to YouTube, Amazon, others)
Vulnerability:
DNS centralization: ICANN ultimately controls the root DNS servers
Certificate authorities: HTTPS requires CAs, which can be compromised or coerced
Routing attacks: BGP has no built-in authentication (trust-based)
Resistance strategies:
Alternative DNS (blockchain-based names like ENS, Namecoin)
Onion routing (Tor—routes traffic through multiple nodes to hide destination)
IPFS (content-addressed instead of location-addressed—content hash is the "address")
Mesh routing (packets find paths dynamically, no central routing tables)
What it is:
How you prove you are who you claim to be
Username/password on platforms
Email addresses
Social login ("Sign in with Google/Facebook")
Digital certificates and keys
Who controls it:
Platforms (Facebook, Google, Apple control their login systems)
Federated identity providers (OAuth services)
Individuals (if using self-hosted identity)
Sovereignty implications:
Platform identity is leased (Facebook can delete your account, erasing your identity)
Email is more sovereign (you can change providers, keep your address if you own domain)
Federated identity (like Mastodon's @user@domain.com) gives you control
Vulnerability:
Platform capture: Most people use "Sign in with Google/Facebook" (convenient but gives those companies control)
Real name policies: Platforms requiring legal names harm pseudonymous freedom
Account suspension: Losing your account means losing your identity across all connected services
Resistance strategies:
Self-hosted identity (your own domain, your own email server)
Decentralized identifiers (DIDs—cryptographic identities not tied to any platform)
PGP/GPG keys (cryptographic proof of identity)
Federated identity (ActivityPub, IndieAuth)
What it is:
Where your files, messages, posts, photos actually live
Cloud storage (Google Drive, Dropbox, iCloud)
Platform databases (Facebook's servers storing your posts)
Self-hosted storage (your own hard drive or server)
Who controls it:
Cloud providers (Amazon S3, Google Cloud Storage)
Platforms (Twitter, Instagram, TikTok)
Individuals (if self-hosting)
Sovereignty implications:
If your data lives on someone else's servers, they can delete it, surveil it, or lock you out
Export tools help (you can download your data), but migrating is often hard
Self-hosting gives you control but requires technical skill and maintenance
Vulnerability:
Terms of Service changes: Provider can change terms, delete your data, or raise prices
Platform shutdown: If the company dies, your data dies (unless you exported)
Vendor lock-in: Proprietary formats make it hard to migrate
Resistance strategies:
Self-hosting (Nextcloud, Syncthing)
Distributed storage (IPFS, BitTorrent, Filecoin)
Local-first software (data lives on your device, syncs peer-to-peer)
Regular exports (even if using cloud, keep local backups)
What it is:
The software you actually use: social media apps, email clients, browsers, editors
Web apps (run in browser, on company servers)
Native apps (run on your device, may or may not depend on servers)
Protocols (open standards that any app can implement)
Who controls it:
Platform companies (Facebook, Twitter, TikTok)
Open source communities (Firefox, Linux, WordPress)
Standards bodies (W3C for web standards, IETF for internet protocols)
Sovereignty implications:
Proprietary apps lock you into a platform's ecosystem
Open source apps can be forked if the company sells out
Open protocols allow multiple competing apps (email: Gmail, Outlook, Apple Mail all work together)
Vulnerability:
Platform changes: Twitter can redesign its app, remove features users rely on
API shutdowns: Third-party apps can be killed (Twitter banned third-party clients in 2023)
Dark patterns: Apps designed to be addictive, manipulative (infinite scroll, notification spam)
Resistance strategies:
Use open source apps (can't be taken away)
Use protocol-based tools (email, RSS, ActivityPub)
Support third-party clients (don't let platforms monopolize access)
Build alternatives (if platform sucks, fork it or build competitor)
What it is:
How money flows through digital systems
Payment processors (Visa, PayPal, Stripe)
Platform monetization (ads, subscriptions, cuts of transactions)
Cryptocurrency (Bitcoin, Ethereum)
Creator economy (Patreon, Ko-fi, OnlyFans)
Who controls it:
Payment oligopolies (Visa/Mastercard process ~80% of transactions)
Platform companies (take 30% cuts on app stores, 15-50% on creator platforms)
Banks and regulators (can freeze accounts, block payments)
Sovereignty implications:
If platforms or payment processors can cut off your income, you're not economically sovereign
Deplatforming often includes payment bans (see: sex workers, political dissidents, WikiLeaks)
Creator economy gives some independence, but platforms still take large cuts
Vulnerability:
Payment processor power: Visa/PayPal can ban you, cutting off all income
Platform rent-seeking: App stores take 30%, creator platforms take 15-50%
Regulatory capture: Governments can pressure payment companies to ban disfavored actors
Resistance strategies:
Cryptocurrency (censorship-resistant payments, but volatile and technical barriers)
Direct payments (checks, cash, wire transfers—cumbersome but sovereign)
Cooperatively-owned payment systems (credit unions, payment co-ops)
Multiple revenue streams (don't depend on one platform or processor)
What Happened:
In 2010, Libya (which controls the .ly top-level domain) seized
vb.ly, a popular URL shortener, for "violating Libyan Islamic morality
laws." The site had shortened links to content Libya deemed offensive.
Impact:
Thousands of shortened URLs broke instantly
Blogs, tweets, forum posts—all pointing to dead links
Content wasn't deleted, but became unreachable via those URLs
Sovereignty Stack Analysis:
| Layer | Vulnerability | Lesson |
|---|---|---|
| Physical | Content was fine (on US servers) | Not the issue |
| Network (DNS) | CRITICAL FAILURE | Libya controlled .ly TLD, seized the domain |
| Identity | Vb.ly users lost identity (their short URLs) | Dependent on DNS |
| Storage | Content still existed | But unreachable |
| Application | URL shortener app still worked | But domain gone |
| Economic | Vb.ly lost revenue | Revenue depends on domain access |
Lesson: Even if you control Layers 4-6 (storage, apps, payment), if Layer 2 (DNS) is captured, you're toast.
Resistance: Use domains under TLDs controlled by stable, rights-respecting jurisdictions. Or use alternative naming (onion addresses, IPFS hashes, blockchain names).
What Happened:
In January 2021, Amazon Web Services (AWS) terminated Parler's hosting contract, citing Terms of Service violations (insufficient moderation of violent content). Parler went offline for a month until they found alternative hosting.
Impact:
Entire platform inaccessible (no hosting = no site)
Millions of users locked out
Parler eventually returned via smaller hosting providers, but with degraded performance
Sovereignty Stack Analysis:
| Layer | Vulnerability | Lesson |
|---|---|---|
| Physical | CRITICAL FAILURE | AWS controlled servers, kicked Parler off |
| Network | Parler still had their domain | But no servers to point to |
| Identity | User accounts existed (in database) | But database offline |
| Storage | Data existed (Parler had backups) | But no public access |
| Application | Parler's app still existed | But servers offline |
| Economic | Couldn't run ads or process payments | Business model dead |
Lesson: If you don't own Layer 1 (physical infrastructure), you're vulnerable to hosting providers' decisions. AWS, Google Cloud, and Azure are de facto gatekeepers.
Resistance: Self-host (expensive and technical), use offshore hosting (politically risky), or distribute across multiple providers (complex but resilient).
What Happened:
Facebook required users to use their legal names (2014 policy enforcement wave). Thousands of accounts suspended:
Drag performers using stage names
Native Americans with non-Western naming conventions
Abuse survivors hiding from stalkers
LGBTQ+ people using chosen names
Impact:
Users lost access to years of posts, photos, friend networks
Some lost business pages tied to stage personas
Forced outing for trans people using new names
Sovereignty Stack Analysis:
| Layer | Vulnerability | Lesson |
|---|---|---|
| Physical | Not the issue | Servers worked fine |
| Network | Not the issue | DNS worked fine |
| Identity | CRITICAL FAILURE | Facebook controlled identity, could revoke it |
| Storage | Data existed but locked | Users couldn't access their own content |
| Application | Facebook app worked | But identity removed |
| Economic | Lost business pages | Revenue tied to identity |
Lesson: Platform-controlled identity is leased, not owned. If the platform can delete your identity, you have no Declaration (Pillar 1).
Resistance: Use federated identity (@user@your-domain.com), self-host identity, use cryptographic keys (not platform usernames).
What Happened:
In 2010, after WikiLeaks published classified US documents, Visa, Mastercard, PayPal, and Bank of America all cut off WikiLeaks' payment processing. Donations plummeted 95%.
Impact:
WikiLeaks nearly went bankrupt
Couldn't accept credit card donations
Had to rely on Bitcoin (before it was widely adopted)
Sovereignty Stack Analysis:
| Layer | Vulnerability | Lesson |
|---|---|---|
| Physical | Hosting providers also pressured | But WikiLeaks migrated |
| Network | Domain pressured but survived | DNS remained |
| Identity | Not the issue | WikiLeaks identity intact |
| Storage | Archives remained accessible | Data fine |
| Application | Website worked | Accessible |
| Economic | CRITICAL FAILURE | Payment processors cut off revenue |
Lesson: Economic sovereignty (Layer 6) is essential. If payment processors can deplatform you, you're economically vulnerable no matter how technically sovereign you are.
Resistance: Bitcoin (WikiLeaks adopted it, later profited from appreciation), direct bank transfers (slow, high fees), cash/checks (physical, not scalable).
What Happened:
Mastodon launched in 2016 as a federated alternative to Twitter. Anyone can run a Mastodon instance (server); instances communicate via ActivityPub protocol.
Resilience across layers:
| Layer | How Mastodon Resists Capture |
|---|---|
| Physical | Distributed servers (no single company owns all hosting) |
| Network | Open protocol (ActivityPub—any server can join) |
| Identity | Federated (@user@instance.com—tied to instance, but migratable) |
| Storage | Instance admin controls data (users can export, migrate) |
| Application | Open source (anyone can fork, improve, or run their own version) |
| Economic | Varied models (donations, subscriptions, volunteer-run) |
Advantages:
No single point of failure (if one instance dies, others survive)
No corporate control (community-governed instances)
Portable identity (can migrate between instances)
Challenges:
Instance admin power (can still ban you from that instance)
Fragmentation (instances defederate, creating silos)
Technical barriers (running an instance requires skill)
Economic sustainability (many instances struggle to fund themselves)
Lesson: Federation distributes sovereignty but doesn't eliminate all vulnerabilities. Still better than centralized platforms.
Problem: Cloud oligopoly (AWS, Google Cloud, Azure control most hosting)
Alternatives:
Community-Owned ISPs:
Fiber cooperatives (users own the network)
Examples: Chattanooga's municipal fiber, NYC Mesh
Advantages: Democratic control, no corporate extraction
Challenges: Requires local organizing, capital investment
Peer-to-Peer Hosting:
IPFS (InterPlanetary File System): Content distributed across many nodes
BitTorrent: Files seeded by many users, no central server
Advantages: No single point of failure, censorship-resistant
Challenges: Slow for dynamic content, legal gray areas
Mesh Networks:
Wireless networks where users' devices relay traffic
Example: Freifunk (Germany), NYC Mesh
Advantages: No central ISP, community-controlled
Challenges: Limited range, technical complexity
Problem: DNS centralization (ICANN controls root servers, domain seizures possible)
Alternatives:
Blockchain-Based Naming:
ENS (Ethereum Name Service): Register .eth names on Ethereum blockchain
Advantages: Censorship-resistant (no government can seize), permanent ownership
Challenges: Requires crypto wallet, expensive (gas fees), not browser-native
Namecoin: Bitcoin-based naming system (.bit domains)
Similar trade-offs to ENS
Onion Routing:
Tor hidden services: Sites with .onion addresses (e.g.,
3g2upl4pq6kufc4m.onion for DuckDuckGo)
Advantages: Censorship-resistant, anonymous hosting
Challenges: Slow, not user-friendly (long random addresses), stigma
Content-Addressed Networking:
IPFS: Content identified by hash, not location
Example:
ipfs://QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco (instead
of http://example.com)
Advantages: Content can't be censored by taking down a domain
Challenges: Not human-readable, requires IPFS-enabled browser
Problem: Platform-controlled identity (Facebook, Google can delete your account)
Alternatives:
Federated Identity:
ActivityPub: @user@instance.com (like email addresses)
IndieAuth: Use your own domain as identity
Advantages: Portable (can migrate), not owned by one company
Challenges: Requires domain ownership, instances can still ban you
Decentralized Identifiers (DIDs):
Cryptographic identities (public/private key pairs)
Not tied to any platform or domain
Advantages: Truly sovereign (you control the keys)
Challenges: Hard to remember (long strings of characters), key management risky (lose key = lose identity)
Self-Hosted Email:
Run your own email server (user@yourdomain.com)
Advantages: Full control, federated (can email anyone)
Challenges: Technical (requires sysadmin skills), anti-spam filters often block self-hosted email
Problem: Cloud lock-in (Google, Dropbox, iCloud can delete your data or change terms)
Alternatives:
Self-Hosted Storage:
Nextcloud: Open-source cloud (like Dropbox, but you run it)
Syncthing: Peer-to-peer file sync (no central server)
Advantages: Full control, no surveillance
Challenges: Requires server management, backups are your responsibility
Distributed Storage:
IPFS: Content stored across network, no single server
Filecoin: Pay for distributed storage with cryptocurrency
Arweave: "Permanent" storage (pay once, store forever)
Advantages: Censorship-resistant, redundant
Challenges: Cost, performance, complexity
Local-First Software:
Apps that store data on your device, sync peer-to-peer
Examples: Obsidian (notes), Logseq (knowledge management)
Advantages: Your data, no cloud dependency
Challenges: Syncing across devices is harder
Problem: Proprietary apps (Twitter, Facebook control how you use their platforms)
Alternatives:
Open Source Apps:
Mastodon: Open-source Twitter alternative
Pixelfed: Open-source Instagram alternative
PeerTube: Open-source YouTube alternative
Advantages: Can fork if company sells out, community-governed
Challenges: Often lag in features, smaller user bases
Protocol-Based Tools:
Email: Any client can access any server
RSS: Any reader can subscribe to any feed
ActivityPub: Any app can communicate with any instance
Advantages: No vendor lock-in, interoperability
Challenges: Less shiny than proprietary apps, requires coordination
Problem: Payment processor oligopoly (Visa/PayPal can deplatform you)
Alternatives:
Cryptocurrency:
Bitcoin, Ethereum, etc.: Censorship-resistant payments
Advantages: No bank or processor can block you
Challenges: Volatile, technical barriers, environmental concerns, regulatory uncertainty
Cooperatively-Owned Payment Systems:
Credit unions: Member-owned banks
Payment cooperatives: Users own the payment network
Advantages: Democratic control, aligned incentives
Challenges: Smaller networks, less convenient
Direct Transactions:
Wire transfers, checks, cash: No intermediary
Advantages: Can't be deplatformed
Challenges: Slow, expensive, not scalable online
Platform Cooperatives:
Stocksy: Photographer-owned stock photo agency
Resonate: Musician-owned streaming service
Advantages: Workers own the platform, keep more revenue
Challenges: Hard to scale, less capital for growth
When building new tools, platforms, or institutions, use the Sovereignty Stack as a design checklist:
For each layer, ask:
Layer 1: Physical Infrastructure
Where are the servers? Who owns them?
What happens if the hosting provider kicks us off?
Do we have redundancy (multiple data centers)?
Layer 2: Network Protocols
Are we using open protocols or proprietary ones?
Can we be censored via DNS (domain seizure)?
Do we have fallback addresses (onion, IPFS, etc.)?
Layer 3: Identity
Do users own their identities (domain-based, cryptographic)?
Can we revoke identities (if so, under what conditions)?
Can users migrate identities to other systems?
Layer 4: Storage
Do users own their data legally?
Can users export everything easily?
Is data stored centrally (vulnerable) or distributed?
Layer 5: Application
Is the software open source (can users fork it)?
Does it depend on our servers, or is it peer-to-peer?
Can other apps interoperate with ours (open protocols)?
Layer 6: Economic
How do we make money without surveillance/extraction?
What payment systems do we use (vulnerable to deplatforming)?
Do we have multiple revenue streams?
Ghost (High Sovereignty):
| Layer | Assessment |
|---|---|
| Physical | Self-hosted option (users run their own servers) OR Ghost(Pro) hosting (can migrate away) |
| Network | Custom domains supported (users own their URLs) |
| Identity | Domain-based (you@yourblog.com) |
| Storage | Users own data, full export tools |
| Application | Open source (can fork if Ghost Ltd dies) |
| Economic | Subscriptions (users pay Ghost, or self-host for free), no ads |
Medium (Low Sovereignty):
| Layer | Assessment |
|---|---|
| Physical | Medium's servers only |
| Network | medium.com/@username (don't own domain) |
| Identity | Platform-controlled (Medium can ban you) |
| Storage | Data on Medium's servers (export exists but limited) |
| Application | Proprietary (can't fork, can't self-host) |
| Economic | Ad/subscription-based (users don't control revenue model) |
Result: Ghost embodies more sovereignty across all layers.
Model 1: Corporate Ownership (Status Quo)
Private companies own most infrastructure
Examples: AWS, Cloudflare, Visa, Google
Advantages: Convenient, well-funded, feature-rich
Disadvantages: Extractive, surveillance-based, can deplatform users
Model 2: State Ownership
Governments own critical infrastructure
Examples: Postal service, public utilities, national postal banks
Advantages: Democratic accountability (in theory), public service mandate
Disadvantages: Vulnerable to authoritarianism, bureaucratic, underfunded
Model 3: Commons Ownership
Users collectively own infrastructure
Examples: Wikipedia, cooperatives, federated networks
Advantages: Aligned incentives, democratic, mission-driven
Disadvantages: Coordination challenges, underfunded, slower innovation
We need all three models for different layers and contexts:
Layer 1 (Physical): Mix of corporate, state, and community-owned (diversity prevents single point of failure)
Layer 2 (Network): Open protocols (state/community standards-setting, anyone can implement)
Layer 3 (Identity): Individual ownership (federated or cryptographic)
Layer 4 (Storage): Mix of self-hosted and cooperatively-managed
Layer 5 (Application): Open source (community-owned code)
Layer 6 (Economic): Multiple options (crypto, co-ops, traditional payment—let users choose)
No single model is perfect. The goal is pluralism: multiple ownership structures coexisting, so users aren't dependent on any one.
Attack Vector: Governments compel infrastructure providers to surveil users
Examples:
NSA tapping undersea cables (Layer 1)
Forcing DNS providers to log queries (Layer 2)
Demanding user identity records (Layer 3)
Accessing cloud storage without warrants (Layer 4)
Installing backdoors in apps (Layer 5)
Tracking financial transactions (Layer 6)
Defenses:
End-to-end encryption (can't surveil what you can't read)
Jurisdiction shopping (host in privacy-respecting countries)
Onion routing (obscure who's talking to whom)
Decentralization (harder to compel many actors than one)
Attack Vector: Companies monetize user data and attention
Examples:
Surveillance advertising (Layer 4: data mining)
Algorithmic manipulation (Layer 5: addictive app design)
Platform rent (Layer 6: taking 30% cuts)
Defenses:
Business models that don't require surveillance (subscriptions, donations)
Open source alternatives (no company owns the app)
Data ownership (users control, export, delete)
Attack Vector: Dominant platforms use network effects to lock in users
Examples:
Identity capture (can't leave Facebook without losing social graph)
Data lock-in (hard to export and migrate)
API restrictions (third-party apps banned)
Defenses:
Interoperability (force platforms to allow data portability)
Federation (multiple providers, users can migrate)
Open protocols (anyone can build competing apps)
Attack Vector: Physical infrastructure fails or is attacked
Examples:
Undersea cable cuts (accidental or sabotage)
Data center fires (OVH fire in 2021 destroyed thousands of sites)
Power grid failures (take down entire regions)
Defenses:
Redundancy (multiple data centers, geographic distribution)
Peer-to-peer architectures (no single server to attack)
Regular backups (distributed across locations)
You cannot achieve digital sovereignty by fixing one layer. Even if you:
Own your domain (Layer 2)
Use open source software (Layer 5)
Self-host your data (Layer 4)
...you're still vulnerable if:
Your hosting provider kicks you off (Layer 1)
Payment processors deplatform you (Layer 6)
Your identity depends on a platform (Layer 3)
Sovereignty requires thinking across all six layers. It's not enough to own one part of the stack; you need resilience at every level.
This is hard. Full-stack sovereignty is expensive, technical, and time-consuming. Most people will accept some vulnerability in exchange for convenience. That's okay—sovereignty is a spectrum, not binary.
But the Sovereignty Stack helps you:
Diagnose vulnerabilities: Where are you most at risk?
Prioritize fixes: Which layer matters most for your use case?
Design resilient systems: How do you build across all layers?
Evaluate tools: Does this app/platform embody sovereignty?
In the next chapter, we'll explore movement building—how to turn individual sovereignty into collective power. Because infrastructure isn't just technical; it's political. Changing who controls the stack requires organizing, advocacy, and policy change.
The political economy of Ground isn't just about building alternatives. It's about fighting for a different kind of internet—one where users, not corporations or states, have power.
That fight begins with understanding the Stack. Now you do.
Personal Sovereignty Audit: Use the Sovereignty Stack to audit your own digital life. Which layers are you most vulnerable on? Which are you most secure on?
Trade-offs: Would you accept less convenience for more sovereignty? Where's your breaking point? (e.g., Would you run your own email server?)
Threat Prioritization: Which threat is most dangerous: state surveillance, corporate extraction, platform capture, or infrastructure fragility? Does it depend on your context?
Ownership Models: Should critical infrastructure (DNS, payment systems, cloud hosting) be owned by corporations, governments, or commons? What's best for sovereignty?
Layer Interdependence: If you could only secure ONE layer of the stack, which would you choose? Why?
Future Scenario: Imagine 2040. What does digital infrastructure look like if Archaeobytology succeeds? What if it fails?
Task: Choose one layer of the Sovereignty Stack. Redesign it to maximize sovereignty while remaining practically viable.
Part 1: Critique Current State (500 words)
How does the current system work?
Who controls it?
What are the sovereignty failures?
What specific harms result from current design?
Part 2: Design Alternative (1000 words)
How would you redesign this layer?
What technologies enable your design?
How does it resist capture (corporate, state, platform)?
How does it balance sovereignty with usability?
Part 3: Adoption Strategy (500 words)
How do you get people to switch?
What's the transition path from current system to yours?
What are the obstacles (technical, economic, political)?
Part 4: Threat Model (500 words)
How would each threat actor attack your system?
State surveillance
Corporate extraction
Platform capture
Infrastructure failure
What defenses have you built in?
What vulnerabilities remain?
Part 5: Reflect (300 words)
What surprised you about this design exercise?
What compromises did you have to make?
Would you personally use the system you designed?
Lessig, Lawrence. Code: Version 2.0. Basic Books, 2006.
Classic on how digital architecture encodes power
Star, Susan Leigh. "The Ethnography of Infrastructure." American Behavioral Scientist 43, no. 3 (1999): 377-391.
Infrastructure is political, not neutral
Winner, Langdon. "Do Artifacts Have Politics?" Daedalus 109, no. 1 (1980): 121-136.
Technologies embody political choices
Mueller, Milton. Networks and States: The Global Politics of Internet Governance. MIT Press, 2010.
On DNS, ICANN, and network governance
Schneier, Bruce. Data and Goliath. W.W. Norton, 2015.
On surveillance at every layer
DeNardis, Laura. The Global War for Internet Governance. Yale, 2014.
Who controls protocols and standards
Doctorow, Cory. The Internet Con: How to Seize the Means of Computation. Verso, 2023.
On interoperability and adversarial compat
Bauwens, Michel, and Vasilis Kostakis. Network Society and Future Scenarios for a Collaborative Economy. Palgrave, 2014.
On commons-based alternatives
Schneider, Nathan. "Cryptoeconomics as a Limitation on Governance." COALA Workshop, 2017.
On blockchain governance and limitations
Tor Project. "How Tor Works." https://www.torproject.org/about/history/
IPFS Documentation. https://docs.ipfs.tech/
ENS Documentation. https://docs.ens.domains/
Mastodon Documentation. https://docs.joinmastodon.org/
End of Chapter 15
Next: Chapter 16 — From Practice to Discipline: Movement Building