Technology

The web succeeded because it was open. Anyone could publish. Anyone could link. No gatekeeper decided what was allowed. But openness without ownership created a vacuum. HTTP had no native concept of identity. No access control. No data portability. These were not oversights -- they were deliberate simplifications that made the protocol adoptable. Companies filled that vacuum with user accounts, cookies, and databases they controlled.

Two decades of this produced a specific economic structure. Your reading history, your bookmarks, your search queries, your social graph -- all stored on servers you do not control, governed by terms you did not negotiate, monetized in ways you cannot audit. Shoshana Zuboff named it surveillance capitalism: the unilateral extraction of human experience as raw material for prediction products.

There are two categories of data loss here, and the distinction matters. The first is data you gave willingly -- account signups, saved preferences, reading lists. You consented because there was no alternative architecture that let you own those things yourself. The second is data collected without your knowledge or meaningful consent -- cross-site tracking, browser fingerprinting, behavioral profiles assembled from metadata you never intended to share. Both feed the same machine.

Even the tools that appear to respect users -- Pocket, Notion, Raindrop, Instapaper -- hold your data on their servers, in their format, under their terms. They are better landlords, but they are still landlords. You cannot take your data and walk away without their permission. You cannot grant your own AI agent access to your own reading history without going through their API, if they offer one at all.

The problem is not bad actors. The problem is that the architecture of the web made data extraction the path of least resistance, and data ownership an afterthought that nobody built into the protocols.

The Blogmarks architecture has four runtime components with strict separation of concerns. The ingestion pipeline writes. The MCP server reads. The Solid Pod stores. The browser extension triggers. They never cross boundaries.

A URL enters the system through the browser extension or mobile share sheet. The ingestion pipeline fetches the bytes, detects the content-type, runs the appropriate extractor (HTML, PDF, and more to come), and stores both the raw bytes and the extracted Markdown in the user's Solid Pod. It then indexes semantic chunks in a local vector store.

The MCP server -- a hosted Node.js Lambda -- queries the bookmark store on behalf of AI agents. It reads from DynamoDB for retrieval and applies per-connection scope rules. It never runs extraction logic. The ingestion pipeline never handles queries. The bookmark store is the only shared state between them.

This boundary is sacred. It means each component can be replaced, upgraded, or audited independently. It means the MCP server has no write path to your data. It means your knowledge base is never one monolithic system -- it is a pipeline with clean interfaces.

A local MCP server shifts operational burden to the user: they must install a binary, keep it running, and handle updates. A hosted Lambda shifts that burden to infrastructure — the server is always on, always current, and requires no process management on the client side.

This is a deliberate trade-off. The original design called for a self-contained Rust binary (ADR-004, ADR-005). That approach offered zero data egress and no cloud dependency. After validating the architecture, we chose the hosted path for the v1 product because the installation barrier of a local binary is too high for the target user — someone who wants AI-enriched bookmarks, not a runtime environment to manage.

The hosted Lambda does mean queries pass through AWS infrastructure. We mitigate the privacy impact through scoped tokens: each AI client gets a connection with the minimum data access it needs, independently revocable. Write access is opt-in and off by default.

The architectural boundary remains intact. The MCP server (Lambda) never runs extraction logic. The ingestion pipeline (Lambda + CrewAI) never handles queries. They share only the DynamoDB bookmark store. Each component can be audited, replaced, or upgraded independently.

For users who need local-first operation or direct DynamoDB access, the companion mcp-bookmarks project provides an alternative that can run entirely on-device.