Status: pre-launch. This page describes target design; this document does not establish a deployed service.
Membrane — Feeds and Grants
Not a wall. A filter. The membrane is the boundary between your DAV and the world. It has two directions: Feeds (inbound data you allow in) and Grants (outbound proofs you allow out). You control every channel. The organism cannot override your membrane.
The Biological Model
A cell membrane is selectively permeable. It admits nutrients and signals while blocking toxins and pathogens. It exports waste products and chemical signals while retaining DNA and organelles. The selectivity IS the intelligence. A membrane that admits everything is not a membrane — it is an open wound. A membrane that blocks everything is not a membrane — it is a coffin.
Your DAV membrane works identically. It filters what enters (data about you and the world) and what exits (proofs about you to the world).
Feeds (Inbound)
Feeds are data channels that bring information into your DAV. Each feed is a Nostr subscription that you explicitly enable. No feed activates without your consent.
| Feed Category | Examples | Data Type | Frequency |
|---|---|---|---|
| Wearable biometrics | Heart rate variability, sleep quality, glucose, SpO2, steps | Continuous sensor data | Real-time to hourly |
| Bank feeds | Account balances, transaction history, income/expense patterns | Financial data | Daily (PSD2/Open Banking API) |
| OSINT | Circle Watchman Scores, news alerts, entity tracking | Intelligence signals | Per-event |
| Market prices | Crypto prices, commodity prices, FX rates, equity indices | Price feeds | Real-time |
| Social graph | Nostr follows/followers, reputation scores, EigenTrust vectors | Relationship data | Per-event |
| Environmental | Weather, air quality, UV index, pollen count, noise level | Sensor data | Hourly |
Security model: Design intent: feed data would be stored on your device, encrypted with your Layer 3 key, and shared only through grants you sign. This is not built. Feeds that arrive through Nostr relays would expose subscription timing and IP addresses to those relays, and encryption on the device does not protect data from someone who controls it while unlocked.
Grants (Outbound)
Grants are zero-knowledge proofs that your DAV publishes to the outside world. A grant reveals a PROPERTY without revealing the DATA.
| Grant Category | What It Proves | What It Does NOT Reveal |
|---|---|---|
| Health grants | "My HRV is above 50ms" (healthy range) | Your actual HRV value, your health history, your wearable brand |
| Solvency proofs | "My net worth exceeds $10,000" | Your actual net worth, your asset composition, your bank name |
| Commerce per-tx | "I am authorized to spend up to $500" | Your total balance, your income, your transaction history |
| Age verification | "I am over 18" | Your actual age, your birthday, your ID number |
| Credential proofs | "I hold credential X from issuer Y" | The credential details and your other credentials (the signing key stays visible) |
ZK proof construction: Design intent: each grant would be a zero-knowledge proof made on your device, revealing a property rather than the data. Publishing it as a signed event would still link it to the key that signed it and expose timing to relays; which proof system is used is not yet chosen.
The Selective Permeability Principle
The membrane is not binary (open/closed). It is selective. You can:
- Enable a feed but restrict its scope. Example: enable bank feed for account balance only, not transaction history.
- Enable a grant but restrict its audience. Example: grant solvency proof only to entities with EigenTrust score > 0.7.
- Condition a grant on a feed. Example: grant health proof only when wearable feed confirms data is < 1 hour old.
- Set temporal limits. Example: grant commerce authorization for 24 hours, then auto-revoke.
- Set conditional revocation. Example: revoke all grants if Circle Watchman Score for your jurisdiction drops below 50.
The Five Receptor Types
The membrane has five receptor types that process inbound feeds:
| Receptor | Function | Analogy |
|---|---|---|
| Sensory | Raw data ingestion (biometrics, prices, environmental) | Nerve endings |
| Financial | Balance and transaction data (bank feeds, portfolio) | Nutrient channels |
| Intelligence | OSINT and Watchman Scores (Circle feeds) | Pattern receptors |
| Social | Reputation and relationship data (Nostr graph) | Immune receptors |
| Constitutional | K-invariant status updates (organism health) | Hormonal receptors |
The Three Gates (Outbound)
The membrane has three gates that control outbound grants:
| Gate | Function | Requirement |
|---|---|---|
| Identity gate | Releases identity proofs (age, credential, membership) | Layer 1 or 2 key signature |
| Financial gate | Releases financial proofs (solvency, authorization, history) | Layer 3 key signature |
| Health gate | Releases health proofs (biometric ranges, wellness scores) | Layer 3 key + temporal freshness check |
Each gate requires an explicit cryptographic signature from the appropriate layer key. No gate opens automatically. No grant publishes without your signature.
Implementation
Membrane configuration lives in Nexus Settings (see Nexus). Toggle feeds on/off. Configure grant parameters. Set conditional rules. All changes require your Layer 2 key (configuration key) signature.
Design intent: the membrane settings would be stored as a Nostr event (kind 30078) signed by your configuration key, with the content encrypted to your own keys. Relays holding it would still see your public key, the event type and when it changed, and because Nostr encryption (NIP-44) has no forward secrecy, anyone who later obtains the key could read every stored version. Specific grants become public only if you choose.
Five receptors in. Three gates out. Every channel under your key. Not a wall — a living filter.
Membrane Permission Model
Membrane is a programmable boundary. Every grant must be explicit.
Grant dimensions
- Subject: who is requesting
- Scope: which data/claims are visible
- Duration: time-bounded vs persistent
- Purpose: declared use context
- Revocation: immediate cancellation path
Audit requirements
- Immutable grant/revoke history
- Diff view of permission changes over time
- Alerting for anomalous grant expansion
Default policy
Least privilege by default. Temporary grants over permanent grants unless strong justification exists.