Social SoftwareSoftware as forkable user-generated content

Steven Gerson · April 2026

1. The Problem

Today's software ecosystem has a fundamental tension.

Open source gave us code sharing but not economics. Contributors build for free; value accrues to platforms that host and distribute their work. App stores gave us economics but not composability. Every app is a walled garden — you cannot take a piece of one and remix it into something new. And AI code generation is making writing code trivial, but there is no shared infrastructure for what gets built. Every AI-generated app is an island.

The result: millions of developers building variations of the same thing in isolation, with no way to compose, attribute, or share in the value they create.

2. The Model

Social media already made content forkable and attributable. Anyone can remix a video, and the remix links back to the original. But attribution alone does not reward effort. Social Software takes this one step further: it traces the full lineage of every fork and ensures that effort is rewarded over time, not just acknowledged.

You find an app you like, fork it with one click, describe a change to an AI, and publish your version — all in under a minute. When people use your fork, revenue flows backwards through the entire lineage: you earn, and so does every creator who came before you.

Every app in the ecosystem has three things:

• A lineage — a cryptographic record of its entire ancestry, proving who forked what from whom
• An economic stake — revenue automatically splits backwards through the fork tree
• A safety sandbox — apps run entirely in the browser, verified by an AI linter before compilation

3. Four Tiers

An app is not a monolith. It is a composition of four independent tiers, each with strict boundaries about what it is allowed to do.

This separation is what makes the model work. One hundred people can fork the experience layer while sharing the same connectors and business logic. Network effects compound instead of fragmenting.

Tier 1 lives entirely outside the ecosystem — it is the deployer's own database. Tiers 2–4 are forkable, versioned, and revenue-tracked within the ecosystem. In standard open source, ten forks means ten competing backends. Here, all forks compose the same connectors and APIs. The lower tiers grow more valuable as more forks build on them, and no single fork can fragment the shared state.

When revenue is generated, the four-tier structure makes distribution clean. A tip on an assembled app splits: 40% to the UI creator, 35% to the Business API creator, 25% to the Connector creator. Tier 1 gets nothing — it is the deployer's own system. Each tier is independently attributable.

4. Composition

Forking creates variations. Composition creates new things from existing pieces. The system supports both.

Manifests assemble an app from existing layers: pick a connector, a business API, and a UI layer. The result is a published, runnable app. Manifests are themselves forkable — you can take an existing composition, swap out just the UI layer for a different one, and publish a new version without rebuilding anything else. This is how the ecosystem moves beyond forking individual apps towards assembling new software from a shared library of components.

Embedding lets any app render another app inline. A bounty board could embed a leaderboard. A dashboard could embed a visualisation someone else built. The embedded app runs in an isolated iframe with its own sandbox, and the host app needs to declare an embed scope to access it. The system tracks which apps embed which, so revenue and attribution can flow across composition boundaries, not just within a single fork chain.

Forking is how individuals improve software. Composition is how the ecosystem assembles it into something larger than any one person would build.

5. Lineage and Revenue

Every fork records its full ancestry as a cryptographic path. Fork B knows it came from A. Fork C knows it came from B, which came from A. The entire provenance chain is encoded in a single database column, using PostgreSQL's ltree extension.

This lineage is not just a record. It is the economic backbone of the system.

When someone tips an app, revenue cascades backwards through the lineage using logarithmic decay: 50% to the current maintainer, 25% to their parent, 12.5% to the grandparent, and so on — halving at each generation.

This creates an incentive structure where both creating original work and remixing it well are rewarded. The original creator earns from every successful derivative. The remixer earns from the attention their improvement generates. The system is not zero-sum.

Every piece of code is SHA-256 hashed on publish, creating cryptographic proof of origin. When a remote node imports a layer, the hash verifies it was not tampered with in transit. When two developers independently make identical changes, the system recognises them as the same code.

6. The Fork IDE

The fork experience is designed to be near-instant. A user clicks “Fork & Remix”, and a browser-based IDE opens with the app's code and an AI chat panel. They describe what they want (“add dark mode”, “turn this into a kanban board”) and Claude modifies the code live. The user reviews, clicks publish, and their fork joins the lineage tree.

Sandpack, CodeSandbox's lightweight sandbox, powers the execution. It instantiates in under two seconds, runs React components entirely in the browser, and has no filesystem, no server-side execution, and no network access except what is explicitly injected through a read-only API client.

Safety as architecture, not policy

Between the AI generating code and the sandbox compiling it sits an AI Verification Engine — a purpose-built, eight-rule semantic linter. It is not ESLint. It is a domain-specific safety gate.

The rules are:

• No external fetch — apps may only call relative /api/* endpoints
• No eval — eval() is blocked structurally
• No Function constructor — new Function() is blocked structurally
• No infinite loops — while(true) and for(;;) patterns are caught
• No cookie access — document.cookie is flagged
• No navigation redirection — window.location assignment is blocked
• No direct storage — localStorage and sessionStorage access is flagged as a warning
• Scope enforcement — the most important rule. Apps declare their API scopes (e.g. “read bounties”, “write bounties”, “embed apps”). The linter detects the HTTP method in each fetch call and blocks compilation if the code attempts an API call beyond its declared permissions. Write scope implies read access; embed scope implies read for apps; read scope does not imply write.

The linter catches accidental and naive violations. The Sandpack Content Security Policy enforces the network boundary structurally. Defence in depth: if one layer misses something, the next catches it.

7. Governance

The experience layer is fluid — anyone can fork anything. But the connector layer is shared state, and shared state needs governance.

Schema changes to connectors go through a proposal and voting process. Voting power is not one-person-one-vote, and it is not token-based. It is weighted by actual ecosystem participation:

weight = sessions in the last 30 days + (distributions received × 10)

Developers whose forks are actively used get more say. Developers whose code generates revenue for others — meaning others are successfully building on their work — get the most say. This prevents plutocratic capture while ensuring the people with the most skin in the game have proportional influence.

Community moderation follows a similar principle. Users can flag apps. Five unique flags auto-remove an app from the discovery feed. Flagged apps remain accessible by direct hash — they lose platform-driven attention, not existence.

8. The Platform Is the Product

One of the more interesting decisions in the system: the platform's own UI pages are registered as apps in the database, with their own lineage paths.

The discovery feed is an app. The fork IDE is an app. The governance page is an app. The compositor (“app store”) is an app. Each one can be forked, improved, and republished by anyone.

A shell_config table maps routes to which fork of each core page is currently live. An ecosystem operator can swap any page for a community-contributed alternative. The system eats its own tail — the same mechanism that allows users to fork bounty boards also allows them to fork the platform that hosts the bounty boards.

9. Federation

Independent ecosystem nodes can discover and import layers from each other, like email or Mastodon. Each node runs its own PostgreSQL instance, exposes federation endpoints, and can query remote registries. Imported layers become local roots — they can be forked, built upon, and generate their own lineage within the importing node.

AI coding tools (Cursor, Claude Desktop, Windsurf) connect to the ecosystem through a Model Context Protocol (MCP) server. An AI agent can discover available layers, fork them, modify the code locally, and publish the result — all without leaving the IDE. The pitch is not “abandon your setup and learn our UI.” It is “point your AI agent at this server. Now it has access to a global library of composable layers.”

10. How It Was Built

The entire codebase was built using Claude as a compiler, not as an architect. The human role was to define the constraints, choose the primitives, and enforce separation. The AI's role was execution within those constraints: generating SQL that matched a defined schema, writing API routes that conformed to typed interfaces, building React components that only called declared API scopes.

This is the thesis of the project made recursive. The same way the platform constrains AI-generated forks to be safe and composable, the build process constrained AI-generated code to be architecturally coherent.

The build sequence mirrored the layer architecture:

1. SQL schema first. Every table, RLS policy, and RPC function was defined before any application code. This forced the AI to write code that conformed to real types, not imagined ones.
2. TypeScript types second. The type definitions mirror the SQL schema exactly, creating a compile-time contract between the database and the application.
3. Business logic third. Revenue calculation, lineage traversal, and the linter are pure functions with no UI dependencies.
4. API routes fourth. Each route is a thin orchestration layer: validate, call business logic, return response.
5. MCP server fifth. The MCP tools wrap the same business logic the API routes call. There is no separate backend.
6. Frontend last. The UI was the last thing built because it has the most dependencies and changes the most frequently — exactly the layer the platform is designed to make forkable.

The ordering proved the architecture's premise: you can build the UI last, swap it out, and nothing else changes.

11. What Exists Now

This is a minimum viable ecosystem, not a production platform. It proves the structural ideas — lineage-based economics, four-tier separation, AI-native forking, and self-hosting recursion — within a working codebase that can be run locally against a free Supabase instance.

Working now

• Fork DAG with PostgreSQL ltree lineage tracking
• Revenue settlement with logarithmic decay (50/25/12.5…)
• AI-powered fork IDE with Sandpack and Claude
• Eight-rule safety linter with read/write/embed scope enforcement
• Event-sourced immutable audit trail
• Optimistic concurrency control on bounties
• App composition: manifest forking with layer swapping, cross-app embedding via EcosystemEmbed
• MCP server with dual transport (stdio + HTTP) and 9 tools
• Federation discovery and layer import
• Core platform pages registered as forkable apps
• Stake-weighted governance with community flagging
• 14 frontend pages covering the full user journey
• 18 API endpoints across apps, bounties, revenue, governance, layers, manifests, embedding, and federation

Code-complete, needs real keys

• Stripe Connect payouts (compiles, never tested against live keys)

Planned but not yet built

• WebContainers for full-stack forks (not just React)
• IPFS/Arweave blob storage
• AST blast-radius engine (simulate schema changes against active forks)
• Behavioural Sybil resistance (entropy scoring)
• Automated schema deployment on governance passage