Research Brief: A Censorship-Resistant, Local-First Substitutions Database

This is the record of a 2026-08-10 design conversation. It keeps the voice we had the conversation in. The goal is a local substitutions database extracted from The Food Substitutions Bible by Joachim, so a user can ask for a recipe variant that is shelf-stable, vegan, vegetarian, gluten-free, keto, or built from whatever is in the pantry. We covered PDF extraction, the SQLite schema, WASM app options, deployment to all five desktop and mobile platforms without app stores, PWA tradeoffs, remoteStorage, P2P storage architectures, Tor/I2P/Nym anonymity, and the identity-free question. Then we landed on an architecture.

The short version of where we landed: a local-first WASM/PWA app. The immutable reference database goes on Arweave, versioned through the existing ARNS setup. User data lives in the user’s own Google Drive via the remoteStorage protocol. OPFS is the offline working copy. No existing app implements this exact stack. Every layer has a proven reference implementation you can stand on. The real risks are the maturity of remotestorage.js’s Google Drive backend, and, if anonymity is ever a requirement, the gap between hiding the transport and refusing to collect identity in the first place.

1. The book, and what extraction actually looks like

The book is a 700-page A-Z encyclopedia. We tested two PDF libraries on the real file.

• pypdf: unusable. The text layer drops spaces. “IfYouDon’tHaveItSubstitute2tbsp(30mL)advocaatwith:” is a typical line. You would need word-segmentation recovery to fix it.
• PyMuPDF (fitz): clean. Spaces come back correctly.

One extraction quirk survives PyMuPDF. Fractions are mangled in the text layer. 1/2 becomes “V2”, 1/3 becomes “V3”, 1/4 becomes “%”. For example, “to V2 tsP (1 to 2 mL) brandy” is really “to 1/2 tsp (1-2 mL) brandy”. So the pipeline needs a fraction-correction table plus an entry parser.

The structure is consistent:

• INGREDIENT header, description paragraph, then “If You Don’t Have It / Substitute with:” followed by a bulleted list of alternatives.
• Each alternative has an amount, a substitute, and sometimes a parenthetical note (“(more peppery)”).
• Unit-equivalence lines like “40 whole berries = 1 tsp (5 mL) ground”.
• Cross-references (“See X”).
• Claimed content: 6,500+ substitutions.

Extraction plan: PyMuPDF full-text with page tracking, fraction correction, entry parser anchored on the “If You Don’t Have It” blocks, amount normalizer to canonical units (tsp/TBS/cup/mL/g/oz), provenance fields (page, source line). Target 5,000-6,500 rows, with a hand-verified golden set as the quality gate.

2. What’s already out there (we checked first)

Nothing does exactly this – local, book-derived, CRUD-able, queryable substitution DB with a WASM frontend. The nearest neighbors:

• FoodKG (foodkg.github.io): a research knowledge graph with about 2,300 substitution pairs scraped from The Cook’s Thesaurus. It is RDF triples plus parsing scripts (solashirai/FoodSubstitutionDataScripts). It is research data, not an app, and it is Thesaurus-sourced, not this book.
• Mealie: self-hosted recipe manager, FastAPI backend + Vue frontend. Closest in app shape. It manages recipes and meal plans, though. There is no substitution knowledge base and no book import.
• OpenEats / OwnRecipes: recipe managers, no substitution database at all.
• Spoonacular and friends: API consumers, not self-hosted.

Verdict: build it. Borrow the good patterns (FastAPI + swagger from Mealie; sql.js / sqlite-wasm for the WASM layer) and skip reinventing them.

3. The data model

SQLite, normalized, mirroring the master-substitutions.yaml schema you already built (orig/sub grams, ratio), so the two can cross-fertilize:

• ingredients(id, name, description, page) – unique by name
• aliases(ingredient_id, alias) – the book uses many synonyms
• substitutions(id, ingredient_id, substitute_id, orig_amount, sub_amount, orig_grams, sub_grams, ratio, note, priority, page)
• equivalences(id, ingredient_id, amount_text, metric_text)
• tags(id, name) – shelf-stable, vegan, vegetarian, gluten-free, keto, nut-free, dairy-free
• ingredient_tags(ingredient_id, tag_id) – many-to-many

The payoff endpoint: POST /variants with {recipe: [{ingredient, amount}], constraints: [shelf-stable, vegan, keto]} -> per-ingredient substitutes filtered by tags, plus the full variant ingredient list.

4. WASM app and the Rust binding question

• sql.js: SQLite compiled to WASM (Emscripten). It loads the DB into memory and exports on save. Simplest option, fine for a ~5MB DB.
• sqlite-wasm (official sqlite.org build): OPFS persistence, better for bigger DBs in the browser.
• The canonical Rust answer, verified this session: rusqlite now supports wasm32-unknown-unknown by swapping libsqlite3-sys for sqlite-wasm-rs – raw C-style bindings to the official libsqlite3 WASM build. The older route is rusqlite + bundled + wasm32-wasi-vfs for WASI/server-side. Alternatives: wa-sqlite (rhashimoto) with OPFS/IndexedDB VFS, or a 2024 Diesel + OPFS crate if you want an ORM.
• If you go Rust frontend: trunk + rusqlite (wasm swap) + wasm-bindgen.

5. Deployment: WASM engines vs a native shell

Yes, standalone cross-platform WASM engines exist. Wasmtime (Bytecode Alliance, the reference implementation), Wasmer, WasmEdge, wasmi (pure Rust interpreter), Wasm3 (embedded), WAMR (Intel, embedded/mobile).

Two corrections to the “WASM runs everywhere” dream:

1. A WASM module is not an executable the OS runs directly. The engine is a native process. On desktop that is a small binary. On iOS and Android you still need a native app shell. The OS refuses to launch WASM directly, and mobile OSes mandate a shell.
2. No WASM engine gives you a GUI. WASI is a syscall layer (files, network, clock), not a UI toolkit. Your UI is either a canvas-rendered toolkit (egui/Slint) or a webview.

Wasmtime’s own platform-support page says “OS support primarily includes Windows, macOS, and Linux. Other OSes such as iOS, Android, and Illumos are supported but less well tested.” The real-world split:

• Android: viable. JIT is allowed, Cranelift works. People embed Wasmtime or WAMR in Android apps for plugin sandboxes.
• iOS: the hard case. Apple forbids JIT in shipped apps, so Cranelift cannot be used. You are stuck with interpreter mode (slow) or AOT-compiled code. Same policy wall as every WASM-on-iOS story. It is an Apple constraint, not a Wasmtime gap.

When Wasmtime beats Tauri: when the logic is the product, when you need a sandbox boundary for untrusted code, when the same module must also run on servers or the edge, when you cannot rely on a system webview, or when footprint and cold start matter. When Tauri wins: when the UI is the deliverable and you want native integration (filesystem, keychain, dialogs) for free. The hybrid that gets both: a pure WASM-compilable core crate, used by a Tauri shell today and by a future Wasmtime or edge deployment unchanged.

UI under Wasmtime: egui (via eframe, glow/wgpu) is the dominant canvas GUI. Slint is the main retained-mode alternative. In a browser or webview: Leptos, Dioxus, Yew.

6. iOS without the App Store

The paths, in order of how much control Apple keeps:

1. PWA – Apple’s own suggested path. Apple told developers this in March 2021, after Parler’s removal. No approval, no 30% cut, no review. Apple cannot block it without attacking the web itself. Caveats: iOS PWAs lack some native capability. Push is only since 16.4, no badge, no File System Access, no background execution. Parler used this as its interim path and returned to the App Store in May 2021 after capitulating on moderation.
2. EU alternative marketplaces + web distribution (post-DMA, 2024+): approved third-party marketplaces (AltStore PAL, Epic) or direct web distribution. Apple requires notarization for every app even there. Still Apple’s gate, and EU-geofenced.
3. Ad-hoc distribution: up to 100 registered devices per year via a development certificate. Small closed groups only.
4. Enterprise distribution: internal apps, unlimited devices. Apple has revoked certs for public misuse (Facebook Research VPN, Google’s screen-time app, 2019). Not viable for consumer-facing cases.
5. Jailbreak or unsigned sideloading: technically always possible, non-starter for a legitimate business.
6. Give up on iOS (Android + web). Several censored apps effectively did this.

The structure of Apple’s power: the App Store is the only low-friction channel. The web is the escape hatch Apple cannot control but can inconvenience.

7. PWA-everywhere: what it takes, and what it costs

Process: HTTPS (hard dependency – no cert, no PWA) -> manifest (name, icons 192/512/maskable, start_url, display: standalone) -> service worker (precache the app shell incl. the .wasm; cache-first for assets, network-first for data; skipWaiting + clients.claim on update) -> correct application/wasm MIME + instantiateStreaming -> OPFS persistence + export/import -> navigator.storage.persist() -> per-platform install testing.

Per-platform install reality: Android Chrome (beforeinstallprompt, best citizen), desktop Chrome/Edge (install icon, standalone window), macOS Safari Sonoma+ (Add to Dock), iOS Safari (manual Share > Add to Home Screen only – no prompt, weakest capabilities), Firefox (Android install; desktop weaker).

Threading note: SharedArrayBuffer requires COOP/COEP headers. Chrome and desktop support it. Safari does not. Design single-threaded if cross-platform matters.

The honest costs: iOS is the floor (manual install, no badge, no FS Access, no background, WebKit-only). Data is trapped in the browser sandbox (per-origin, per-profile; eviction risk without persist; export/import is mandatory, not optional). Distribution trust is lower (no store badge, you own all marketing). There is no code-signing trust anchor (trust equals the HTTPS origin). Native integration is capped (no tray, no keychain, no file-type association – and an HTTPS page fetching http://localhost is blocked by mixed content, which breaks a localhost preview workflow without HTTPS or a loopback exception). Performance is a ceiling not a floor (DOM/WebKit shell, iOS memory limits). Update control is double-edged (instant ship, but no staged rollout and the service worker’s timing is browser-controlled). Apple policy risk is transformed, not eliminated (Apple controls WebKit and demonstrated in March 2024 it can threaten to degrade web-app functionality; it reversed under EU pressure). The test matrix is permanent (four engines, constant API divergence).

For a substitutions editor specifically: this is exactly the kind of app where the PWA ceiling is acceptable. It is data-light, offline-friendly, with no exotic hardware. The two costs that will bite: data portability (export/import is a must-have feature) and the iOS experience floor. The two you escape are the ones you care about: no store approval, no delisting risk.

8. remoteStorage: user-owned data without you running a server

remoteStorage (remotestorage.io, IETF draft-dejong-remotestorage) is the protocol designed for unhosted apps. The app runs 100% client-side. The user picks their storage server, grants the app a scoped path, and the app does GET/PUT/DELETE on objects under that scope. OAuth2-style bearer tokens. You, the developer, run no database at all.

One correction up front: remoteStorage is not peer-to-peer. It is a star-topology, client-server protocol. An authoritative server holds state, and browsers sync against it over HTTP REST with ETags and JSON-LD directory listings. People discuss it alongside P2P systems, but the topology is a hub. Discovery uses WebFinger ([email protected]). Auth is OAuth 2.0 with scoped access (e.g. documents:rw), and the protocol revisions moved from the Implicit Grant to PKCE (Proof Key for Code Exchange) for hardening.

Ecosystem status (verified via project docs, 2026-08-10):

• Client: remotestorage.js (JS/TS) – IndexedDB cache + offline + cross-device sync. remotestorage.js is the canonical client, in maintenance mode rather than heavy active development.
• Servers: community implementations in Python, Node.js, Go, and Rust. Armadietto (Node.js reference server, v0.6.5, MIT, actively maintained; file/streaming/S3 backends) and mysteryshack (Rust). Self-host via YunoHost, Cloudron, or Caprover.
• Integration: remoteStorage can plug into Nextcloud and ownCloud as storage backends, which matters if you already run Nextcloud. WebDAV sync of a single .db file still gives 80% of the benefit with zero new protocol.
• Hosted: 5apps provides turnkey storage; most usage is self-hosted on personal servers or VPSes.
• Apps: integrated into minimalist privacy-focused unhosted apps (Litewrite, Laverna, markdown editors, task managers). Niche but alive.
• Google Drive: built into remotestorage.js as a first-class backend. Call setApiKeys(‘googledrive’, {clientId}) and the Connect widget offers Drive as an option. No bridge server needed; the app talks to the Drive API directly. Caveats: this backend is old and largely unmaintained (bug reports from 2013, never visibly modernized). The app must be registered with Google. Quotas and revocation apply, and Google can read the data unless you encrypt client-side.
• Rust client: pontus_onyx exists but is explicitly not production-ready until 1.0. For a WASM UI, calling remotestorage.js from Rust via wasm-bindgen/js-sys interop is the pragmatic path. It is a web app anyway.

Tradeoffs: it solves the OPFS single-browser weakness (real cross-device sync, user-owned storage, no central DB). But it is not zero-infrastructure. Someone runs a server – the user’s choice. The data model is files or objects, not a queryable DB (store the .db blob, or per-record JSON). Offline is good but sync conflicts are last-write-wins per object. It is a niche protocol with a small community and an IETF draft that never reached RFC.

9. P2P, serverless, censorship-resistant architectures

Seven families, each answering “who holds the data and who can delete it” differently:

1. Content-addressed storage (IPFS, Arweave, BitTorrent): data addressed by hash, no single host. Arweave is permanent, pay-once, ideal for immutable reference. Weakness: updates are new hashes; you need a mutable pointer (ARNS/IPNS) for “latest.”
2. DHT/P2P (libp2p, Hypercore/Holepunch, IPFS): no central server. NAT traversal is hard, mobile peers churn, and availability depends on always-on nodes.
3. Relay-based pubsub (Nostr): keypair identity, dumb swappable relays, signed content, no relay authoritative. You already use it. Great for identity, discovery, and announcements; awkward for large binaries.
4. Federation (ActivityPub, Matrix): many authorities, not none; moderate resistance.
5. Local-first with CRDT sync (Automerge, Yjs, sqlite-sync): offline is the default state. The sync channel is pluggable (WebRTC, a file, a relay, a server, a friend’s server). The strongest property: the app never depends on a server to function.
6. WebRTC mesh: direct browser-to-browser. It needs a signaling path and fights NAT; it is not a store.
7. Blockchain (Ethereum/Solana): maximal immutability, expensive and slow, with its own gatekeepers (validators, MEV).

Real apps by architecture: Fission/WebNative (WNFS + IPFS + UCAN capability auth, local-first – the closest full-stack example of the pattern), ArDrive (the Arweave reference app), Anytype (local-first encrypted object store, its own protocol), StoryArk (whole-database CRDT social app), Obsidian/AppFlowy/Actual (local-first, but trusted sync), Nostr clients (Damus, Amethyst, Primal – production-proven identity and relay layer).

The gap: no existing app combines all four layers – Arweave reference + local-first CRDT + Nostr identity + pluggable sync. Every layer has a proven reference. The composition is the novel part.

The synthesis for this app: immutable reference data on Arweave/IPFS (versioned via ARNS); personal mutable data local-first SQLite/OPFS + CRDT sync; Nostr keys or a WebAuthn passkey for identity; optional Nostr relays for “my data moved here” announcements.

10. Anonymity: Tor, I2P, Nym

Transport anonymity is achievable on all three. Application-layer anonymity is a design property, not a network property.

• Tor: onion services hide the creator’s IP. Tor hides the user’s IP from creator and third parties. Defeated by traffic and timing correlation for powerful adversaries. IPFS over Tor is still experimental. The project’s own issue tracker (ipfs/kubo #6430) says default mode leaks information (DHT lookups, peer IDs, local discovery), and the anonymous mode was never completed.
• I2P: all traffic stays in-network (no exits by default), garlic routing, stronger against some traffic analysis. Fewer nodes, less bandwidth.
• Nym: strongest metadata-hiding (mixnet + cover traffic, layered encryption). Latency is tunable from milliseconds to minutes. Throughput is fine for sync, poor for streaming. NymConnect gives any app SOCKS5 access.

The critical finding: keypair identity (Nostr) is pseudonymous, not anonymous. Relay operators see your IP without Tor. The keypair is a stable, linkable identifier across all your activity – that is the point of a keypair, and exactly why it links. Full anonymity requires ephemeral keys (which kills cross-device sync) or a routing layer that hides the key-activity/IP link. For “even the creator cannot identify users”: everything client-side, encrypted before upload, no accounts, no stable IDs. Then sync becomes “encrypted blobs pushed to any store,” which Tor/I2P/Nym all handle identically. The hard part is never the network. It is refusing to collect identity in the first place.

11. Privacy-compatible storage backends: CRDTs and Tahoe-LAFS

The Gemini research handoff (gemini_chat.json, 2026-08-10) covered two more storage families for the privacy/anonymity question: CRDT frameworks and Tahoe-LAFS. Both change the answer to “who can see the data.”

CRDTs and the metadata leakage problem

No mainstream CRDT (Automerge, Yjs, Loro) is privacy-first out of the box. They are built for convergence and performance, and that leaks metadata:

• Persistent actor or client IDs. Every edit attaches to a unique random ID. Anyone with the document history can profile writing speed, typing patterns, and active hours against one key.
• Immutable operation history. CRDTs keep deleted text and prior drafts to merge offline edits. The log retains everything, forever.
• Transport leakage. Without end-to-end encryption, the sync server sees full edits, IP addresses, and the real-time interaction graph.

The privacy ranking from the handoff:

1. Earthstar – best for architectural privacy. Instead of raw UUIDs, entries are signed with Ed25519 author keypairs. Data is scoped to secret “share” keys; anyone outside the share cannot read or index it. Replicas sync through untrusted “servers of opportunity” without exposing plaintext or the member identity graph. Authors can cycle keypairs or use single-use pseudonyms per document. Offline-first, SQLite-backed shares. Verified: real project (earthstar-project/earthstar).
2. Jazz (CoValues) – best for encrypted local-first sync. Built on CRDT structures with native end-to-end encryption and group access control. Sync servers act as blind relays; operators cannot inspect state or user metadata.
3. Automerge or Yjs over a custom encrypted transport – workable but the encryption is your job, and the actor-ID history still leaks unless you strip it.

For this app: Earthstar is the strongest fit for the user-delta layer if privacy is a requirement. The share-key model maps directly to “one share per user’s substitutions,” the Ed25519 keypair gives pseudonymous identity without a server account, and the servers-of-opportunity model means the creator runs nothing.

Tahoe-LAFS

Tahoe-LAFS (Least Authority File Store) is a decentralized file store with a different angle: provider-independent security. Storage providers cannot read, modify, or leak data even if they are malicious or compromised.

How it works:

• Client-side encryption and erasure coding. Before data leaves the machine, the client encrypts it and splits it into erasure-coded shares (default 3-of-10). Shares go to distinct storage nodes. Any 3 of 10 online nodes reconstruct the file. Verified: the FAQ confirms the 3-of-10 default, with 3.3x storage overhead.
• Capability-based security. No usernames or ACLs. Access is a cryptographic URI: write-cap grants read and modify, read-cap grants decrypt-and-read, verify-cap lets a node check integrity without reading content.
• Zero-trust grid. Nodes store only encrypted, erasure-coded ciphertext. They have zero visibility into file contents, directory names, or keys.

Privacy profile: content confidentiality is extremely high (zero-knowledge model). Access control is high (a capability string is the access token; no account tied to identity). Network anonymity is variable – nodes see client IPs by default, but Tahoe has native Tor and I2P support so both clients and nodes can run anonymous at the transport level (verified: readthedocs documents Tor/I2P configuration). Metadata leakage remains: nodes can observe upload and download timing, traffic volume, and share size, though they cannot correlate shares to file paths.

Fit for this app: Tahoe-LAFS is heavier than the app needs as a primary store, but it is the right shape for the privacy-hardened variant – a user who wants “even the storage nodes cannot read it” points the delta-layer sync at a Tahoe grid (possibly over Tor) instead of Google Drive. It does not do real-time sync; it is a file store, so the app would push the .db blob or CRDT snapshots rather than stream edits.

12. The identity-free question

What you actually lose without identity (the real costs, in order):

1. Cross-device sync without user effort. The big one. No identity means no way to associate phone data with laptop data. Every no-identity sync design makes the user do something – export a file, scan a code, type a keypair, run a server. Some will; most won’t. The keypair trick recovers most of this. A generated key IS an identity, just not one you collect.
2. Data recovery. No account, no server, no restore. Device lost or browser cleared, the data is gone, and you cannot help because you have nothing to restore from.
3. Abuse control on any shared surface. No rate limiting per user, no bans, no reputation. Invisible if the app only writes to the user’s own device. Painful the moment there is any shared surface – public variant sharing, comments, even a shared sync relay.
4. Monetization and licensing. No accounts, no subscriptions, no tiers, no per-user licensing. Donations or upfront product sales only.

The long tail you technically lose but probably will not miss: analytics, support lookup, named collaboration, per-account notifications, compliance conveniences (selective takedowns, age gates, region restrictions).

What you gain: nothing worth subpoenaing, hacking, or suing you over. No breach. No GDPR data-subject burden in practice. Zero storage ops. Full censorship resistance.

The nuance that dissolves most of the tension: identity is a spectrum, not a binary. The useful middle is pseudonymous, user-held identity. The app generates a keypair, or the user brings their own (Nostr key, passkey). You store nothing. The user gets sync, recovery via re-import, and cross-device continuity. You lose the server-side abuse-control and monetization benefits. You keep the UX.

For a substitutions DB: design no-identity-first (local-first, export/import, encrypted blobs). Make pseudonymous sync an optional layer via user-held keys. The one loss users would feel every day is sync. Everything else is either non-critical or recoverable.

13. The architecture we landed on

• Base DB (the book’s content, the master table) -> Arweave. Immutable, permanent, content-addressed, pay-once; versioned via an ARNS pointer (you already own ARNS and publish CSS there). Any app instance fetches the same base from any gateway (arweave.net, ar-io.net). Multiple gateways, no single host to take down.
• User data (variants, custom substitutions, tags) -> Google Drive via remoteStorage. The user authorizes once. remotestorage.js maps scoped paths onto a Drive folder. You run zero storage infrastructure. Cross-device sync works. The data lives in the user’s own account.
• Local layer -> SQLite/OPFS working copy. Base cached after first fetch, user layer synced through remotestorage.js’s IndexedDB cache. Works offline, syncs when online.

The merge model is what makes this clean: base is read-only reference. User data is a delta layer keyed by stable row IDs. Custom substitutions override or extend base rows. Nothing rewrites the base. The only merge problem is user-data-to-user-data across their own devices – which remoteStorage (or CRDTs on top) handles.

Risks to verify before committing:

1. remotestorage.js’s Google Drive backend maturity. The weak link. Escape hatch: the official Google Drive API client (googleapis JS, actively maintained) implementing the same scoped-folder pattern, or a real remoteStorage server (armadietto).
2. Privacy ceiling. Google can read user data. Client-side encryption before upload is possible but breaks server-side merge. Merge moves client-side, conflict resolution gets harder. Decide early whether “Google can’t read it” is a requirement or a nice-to-have.
3. Base DB updates. ARNS versioning. The app checks the pointer periodically and fetches the new base when it moves. User deltas keyed by stable slug/ID survive base updates. Never key by position.
4. Cold start. First load fetches the base from Arweave (a few MB, a few seconds on a gateway). Cache in OPFS after first fetch. Add a hash check on the base DB – content addressing gives you integrity verification for free.
5. Creator anonymity. The creator is out of the data path entirely. Static app shell anywhere. Base on a public permanent ledger. User data on the user’s own Drive. No identity collected, no data held. The base being public is fine – it is reference data.

14. Anonymous upload to Arweave (verified pattern)

Yes, it works, and it is documented:

1. Route the API call through Tor. arweave-js is plain HTTP. Set a SOCKS proxy and the node sees a Tor exit IP. AR.IO gateways can even run as onion services (dev.to guide).
2. Use a throwaway wallet. Fresh keypair for the upload, never linked, never reused. The on-chain record permanently binds the transaction to that wallet address. So anonymity means the wallet is not otherwise linked to you.
3. Pay through an ANS-104 bundler (Irys/Bundlr, ArDrive Turbo) that accepts ETH/SOL/MATIC/USDC. The bundler pays the AR fee. Your data item sits inside the bundler’s transaction. The bundler arrangement removes both the AR-acquisition problem (KYC exchanges) and the funding link.

The four things that still deanonymize you: the data itself (Arweave is a public permanent ledger – anonymous upload means anonymous attribution, not private content; encrypt client-side if it matters); tags and metadata (permanent and queryable; do not tag identifying info); the payment trail (a KYC’d exchange or linked wallet defeats the whole thing); network correlation (timing and volume against known activity).

For your use case, the anonymity that matters is mostly free. The substitutions base is public reference material, published through your existing ARNS, with nothing identifying in a substitution table. The pattern above is what you would use if you ever want a publish that is not traceable to your personal wallet.

Key References

1. remotestorage.io – Unhosted Architecture, https://remotestorage.io/unhosted.html
2. remoteStorage IETF draft – draft-dejong-remotestorage, https://datatracker.ietf.org/doc/draft-dejong-remotestorage/
3. remotestorage/armadietto – Node.js remoteStorage server, https://github.com/remotestorage/armadietto
4. remotestorage.js – Google Drive backend docs, https://remotestoragejs.readthedocs.io/en/latest/getting-started/dropbox-and-google-drive.html
5. Wasmtime platform support, https://docs.wasmtime.dev/stability-platform-support.html
6. rusqlite GitHub – wasm32-unknown-unknown via ffi-sqlite-wasm-rs/sqlite-wasm-rs, https://github.com/rusqlite/rusqlite
7. crates.io – sqlite-wasm-rs, https://crates.io/crates/sqlite-wasm-rs
8. ipfs/kubo issue #6430 – Anonymous IPFS (DHT leak discussion), https://github.com/ipfs/kubo/issues/6430
9. 9to5Mac (2021-03-25) – Apple suggests PWAs to bypass the App Store, https://9to5mac.com/2021/03/25/bypass-the-app-store-says-apple/
10. USA Today (2021-05-17) – Parler returns to Apple’s App Store, https://www.usatoday.com/story/tech/2021/05/17/parler-returns-apple-app-store-iphone-after-removal/5124921001/
11. Apple Support – About alternative app distribution, https://support.apple.com/en-us/118110
12. FoodKG – https://foodkg.github.io/
13. Mealie – https://github.com/mealie-recipes/mealie
14. Fission / WebNative – https://github.com/fission-codes
15. crdt.tech implementations (StoryArk), https://crdt.tech/implementations
16. Nym Wikipedia – https://en.wikipedia.org/wiki/Nym_(mixnet)
17. dev.to fllstck – Running an Arweave Gateway in the Dark Web, https://dev.to/fllstck/running-an-arweave-gateway-in-the-dark-web-262g
18. Irys docs – Bundlers, https://docs.irys.xyz/onchain-storage/bundlers
19. Earthstar – earthstar-project/earthstar (Ed25519 keypairs, share-scoped data, servers of opportunity), https://github.com/earthstar-project/earthstar
20. Tahoe-LAFS docs – dirnodes and Tor/I2P configuration, https://tahoe-lafs.readthedocs.io/en/tahoe-lafs-1.17.1/specifications/dirnodes.html
21. Tahoe-LAFS FAQ – 3-of-10 default and storage overhead, https://tahoe-lafs.org/trac/tahoe-lafs/wiki/FAQ

Caveats

• This brief records a design discussion. The extraction mechanics and schema are plans, not shipped systems. What was verified live this session: the pypdf space-drop, PyMuPDF recovery, and fraction mangling on the actual book file.
• Wasmtime platform support, IPFS-over-Tor status, the remoteStorage Google Drive backend, Earthstar, and Tahoe-LAFS were verified against primary sources (project docs, GitHub, official FAQs) via web search. The Drive backend’s unmaintained status is inferred from age and lack of modernization, not a formal audit.
• Section 11 synthesizes the Gemini research handoff (~/av/doc/handoffs/gemini_chat.json, 2026-08-10). The CRDT privacy ranking (Earthstar / Jazz / Automerge+Yjs) and Tahoe-LAFS capability model come from that handoff, cross-checked against the projects’ own docs. Jazz/CoValues was not independently verified beyond the handoff.
• Some directional claims (e.g. exact EU alt-marketplace notarization fees) were not verified this session.
• The book itself (Food Substitutions Bible, 2010, ISBN 9780778802457) is the extraction source. Its advice was sanity-checked earlier against The Cook’s Thesaurus in the master-substitutions.yaml work (2026-08-10).
• No credentials, API keys, or tokens appear in this brief or the underlying session.

Compiled 2026-08-10 from the 2026-08-10 session discussion (web-verified where noted).