Memory Transfer & Access Protocol (MTAP)
A standardized approach for secure memory capture, storage, and retrieval across distributed systems
IETF Working Group Draft Standard
Table of Contents
  1. Abstract & Status - Protocol overview and standardization progress
  1. Motivation & Scope - Problem definition and protocol boundaries
  1. Architecture Overview - Five-layer protocol stack and design principles
  1. Core Message Types - Standard operations and payload formats
  1. Security Model - Threat analysis and cryptographic implementations
  1. Extensions & Registry - IANA considerations and protocol extensibility
  1. Example Flows - Implementation scenarios with sequence diagrams
  1. Compliance & Governance - Certification tiers and standardization process
  1. References - Normative and informative citations
Abstract
The Memory Transfer and Access Protocol (MTAP) is a five-layer data protocol standard for capturing, transmitting, and accessing human memories across devices and platforms in an interoperable, secure manner. MTAP defines a common architecture for treating personal memories (structured as multimedia data with metadata) as first-class, portable digital objects. By providing standardized transport bindings, session management, memory semantics (capture, append, search, revoke, audit, monetize), privacy/consent enforcement, and extensibility, MTAP enables a global ecosystem where memories can flow seamlessly yet remain under individual control. This protocol is motivated by the urgent need to preserve human experiences – for example, to assist those with memory loss – and addresses the fragmentation of personal data across services . MTAP aims to be the “HTTP of human memory”, fostering innovation in applications that augment and protect memory for millions of users.
Document Status
This document is an Internet-Draft of the IETF MTAP Working Group. It is expected to be considered for publication as an RFC. Distribution is unlimited.
Publication Timeline
Draft 0.3 (May 2025)
Expected RFC publication: Q4 2025
Motivation and Scope
Preservation
Enabling authentic capture of experiences
Privacy & Control
Ensuring individuals maintain ownership
Protection
Providing robust security
Interoperability
Establishing a common "language"
Augmentation & Monetization
Enabling new experiences and research
Human memory is fundamental to identity and humanity’s collective experience . However, memories today are often siloed across devices, apps, and cloud services, making it difficult to preserve and recall life’s important moments when needed . Those facing cognitive challenges (e.g. dementia patients) are especially vulnerable to memory loss . A globally standardized protocol for memories can ensure that personal experiences are captured before they fade, remain accessible over time, and can be shared or monetized under user-directed terms. MTAP’s design is driven by:
  • Preservation: Enabling authentic capture of experiences (photos, videos, audio, sensor data, context) in a durable, future-proof format .
  • Privacy & Control: Ensuring individuals maintain complete ownership and control over their personal memory data . This includes fine-grained consent management and the ability to revoke or restrict access at any time.
  • Protection: Providing robust security (encryption, integrity, audit trails) to guard memories against loss, corruption, or unauthorized access .
  • Interoperability: Establishing a common “language” for any device, application, or AI agent to communicate about memories . This addresses today’s fragmentation by making memories portable across platforms .
  • Augmentation: Laying the groundwork for new experiences (e.g. AR/VR memory replay, AI memory assistants) by exposing standardized APIs for memory operations.
  • Monetization & Research: Allowing individuals to optionally share or sell access to their memories (fully or in privacy-preserving aggregate forms) for research or commercial use, under strict consent and compensation terms.
By meeting these goals, MTAP serves as foundational memory infrastructure for the digital age. The personal story of a founder witnessing a parent’s dementia journey – a heartbreak shared by millions – underscores the importance of this mission . Research indicates that technologies like MTAP could greatly benefit those with cognitive decline by unifying scattered memories into an accessible whole . Memory is not a luxury or mere feature; it is the bedrock of human existence , and MTAP is designed to preserve it for generations to come.
Requirements and Conventions
Key Words Interpretation
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", etc., in this document are to be interpreted as described in RFC 2119 (with the normative force updated by RFC 8174).
Notation Conventions
This specification uses JSON-like pseudocode for clarity in examples. All multi-byte integers are in network byte order.
Architecture Overview
MTAP is structured as a five-layer architecture, inspired by the Internet protocol suite, to separate concerns from physical transport up to application governance. Each layer builds on the lower layers and defines specific responsibilities and interfaces.
Layer 1 – Transport Bindings
Transport Agnostic
MTAP MUST be transport-agnostic, supporting multiple binding options: for example, an HTTP/3 REST API, a gRPC interface over HTTP/2 or HTTP/3, or a WebSocket event stream.
Required Support
An MTAP implementation MUST support at least one of the standardized bindings (HTTP/3 and JSON over QUIC for web interoperability) and SHOULD support others (such as gRPC/Protobuf for efficiency, or WebSockets for real-time streaming).
Layer Responsibilities
Layer 1 concerns itself with bytes-on-the-wire framing, message delivery reliability, and ordering as provided by the chosen underlying protocol (e.g., HTTP/3 on QUIC for low-latency streams).
Layer 2 – Session Management & Identity
Authentication
Identify who is communicating
Authorization
Determine permitted actions
Delegation
Allow third-party access
Validation
Enforce security policies
This layer handles authentication, authorization, and session context for MTAP interactions. It establishes who is communicating (user, device, or agent identity) and how they are permitted to act. MTAP SHOULD use strong client authentication (e.g., mutual TLS or signed tokens) for devices, and delegated OAuth2-style access tokens for third-party apps acting on a user's behalf.
Standard OAuth 2.0 flows MAY be used to obtain an access token granting limited memory access rights (scoped by user consent). Identity may be tied to existing systems (e.g., a user's account or a DID). Session management ensures continuity of interactions: for example, maintaining an open gRPC or WebSocket session for streaming memory data.
Every MTAP request MUST be authenticated and authorized at this layer before processing at higher layers. If authentication fails or the session is not valid, the service MUST reject the request (e.g., HTTP 401 Unauthorized or 403 Forbidden as appropriate).
Layer 3 – Memory Semantics (Core Protocol)
CAPTURE
Ingest a new memory into the system
APPEND
Attach additional data to existing memory
GET
Retrieve memory contents and metadata
SEARCH
Query memories matching criteria
REVOKE
Revoke or delete a memory
AUDIT
Retrieve verifiable operation logs
Memory Semantics (Core Protocol): Defines the core verbs and data models for memory operations. This is the heart of MTAP’s application logic, specifying how memories are created, modified, retrieved, and managed. MTAP treats a Memory as a fundamental resource: a memory is a discrete unit of personal data (e.g., a photo, video, audio recording, text note, or composite “experience” with multiple modalities) along with associated metadata (timestamp, location, tags, etc.). The core operations (verbs) in MTAP include:
  • CAPTURE: Ingest a new memory into the system (e.g., saving a photo or recording along with context). This operation is typically invoked by an edge device or agent at the moment of capture. On successful capture, a unique memory_id (canonical identifier) and a commit_hash (integrity tag for the memory record) are returned.
  • APPEND: Attach additional data or metadata to an existing memory record. For example, an application might append a text annotation or an AI-generated summary to a memory. The request specifies a Parent-Memory-ID (the memory being extended) and includes the new content/metadata. A new revision_id or commit hash is returned for the updated memory version. MTAP uses an append-only model – memories are never overwritten, only new revisions chained – to preserve history and support auditability.
  • GET: Retrieve a memory’s contents and metadata by ID. The client can specify an Accept format (to request raw blob vs. structured data) and an optional Range for partial retrieval (useful for large media). The response includes the memory binary data (or a link to it) and a Memory-Meta section with metadata. This is analogous to an HTTP GET on a resource and returns 200 OK (or 206 Partial Content for ranged video/audio) on success.
  • SEARCH: Query memories matching certain criteria. This allows retrieval of memories by keyword, tags, people, location, or even by semantic similarity (vector search). The request may include an X-Query-Expr header with a query DSL or an embedded vector representation. The response is a paginated result set of matching memory IDs or summaries. Search can be executed by user agents or authorized analytic agents. Advanced usage includes embedding vectors for context-based search (e.g., “find memories similar to this image”).
  • REVOKE: Revoke or delete a memory, or revoke a granted access to a memory. The semantics depend on context: if the target is a memory ID, this operation marks that memory as revoked (rendering it inaccessible to normal queries) and returns a revocation receipt. If the target is an access grant or consent token, it revokes that consent (more on consent in Layer 4). A Reason-Code header can be provided to indicate why the revocation was performed (e.g., “user_request”, “retention_expired”, “policy_violation”). The protocol MUST ensure that revocations are propagated to all relevant systems (e.g., search indexes updated to exclude revoked content).
  • AUDIT: Retrieve a verifiable log of memory operations for audit or transparency. This is typically used by the user (to audit their own data usage) or by regulators. The request may specify a Scope (e.g., user ID or dataset) and a Since timestamp or log sequence number. The response is an append-only log slice containing records of operations (captures, accesses, sharing events) signed or hashed for integrity. An AUDIT response allows an auditor to verify that the system’s usage of memories complies with policies (for example, that no access occurred without consent).
In addition to these core verbs, MTAP’s semantics include the concept of monetization of memory data. While not a single verb, monetization is enabled through the combination of SEARCH and controlled access with usage policies. A memory owner or authorized broker can allow third-party queries on certain memories or aggregated datasets in exchange for value. The protocol supports this by: (a) allowing queries that return differentially private results (see privacy in Layer 4) so that only statistical insights are shared, and (b) providing a way to meter and charge for data access via extensions (see Layer 5, e.g., a “pricing schema” extension). For instance, an extension could define that a SEARCH request with an X-DP-Budget header (denoting an epsilon privacy budget) has an associated cost, debited from the querying party’s account. Such monetization flows are out-of-band from MTAP core, but MTAP provides the hooks (headers, extension points, audit logs) to make them possible.
The core semantics layer is analogous to the “application layer” in classic protocols, defining the grammar of operations (similar to HTTP methods or SMTP commands). Response codes in MTAP deliberately mirror HTTP status codes when using an HTTP binding (e.g., 201 Created for a new memory, 206 Partial Content for ranged GET, 401 Unauthorized, 429 Too Many Requests, etc.) for familiarity.
Layer 4 – Consent and Governance
This layer embeds privacy, consent, and policy enforcement into the protocol. Every memory captured and accessed through MTAP is accompanied by cryptographic proofs and metadata that enforce the user’s consent and privacy preferences. Key features of Layer 4 include:
Consent Artifacts & Proofs
Cryptographic verification of permissions
Consent Receipts and Logging
Record of granted access for auditing
Policy Snapshot
Immutable record of terms at capture time
Revocation Trees
Efficient tracking of withdrawn consent
Privacy Budgeting
Control information exposure with differential privacy
  • Consent Artifacts & Proofs: When a user grants another entity access to certain memories or when they agree to share data (e.g., for research), a consent artifact (digitally signed token or certificate) is generated. MTAP uses zero-knowledge proof (ZKP) techniques to avoid exposing sensitive details of these artifacts on each request. Instead of sending the raw consent token, a client must present an X-Consent-Proof header containing a ZK proof that the caller holds a valid and unrevoked consent for the requested operation. For example, a delegate accessing a memory on a user’s behalf includes a proof that “I have consent from user X for memory Y with scope Z”, without revealing the consent document itself. This prevents leaked tokens and preserves privacy.
  • Consent Receipts and Logging: Successful operations that used a consent artifact generate a consent receipt recorded in the audit log (Layer 3 AUDIT). This receipt can later be inspected to prove that access was granted with proper consent (useful for compliance or dispute resolution).
  • Policy Snapshot: To handle evolving privacy policies, each memory capture operation includes an immutable snapshot of the relevant policy at the time of capture. An X-Policy-Snapshot header (often an ETag or hash of the policy document) is attached when a memory is stored. This allows future auditors or services to know under what terms the data was collected. If policies change later, the original terms of collection remain auditable.
  • Revocation Trees: The protocol maintains a revocation list or tree for consent artifacts and possibly for memories. When any consent is withdrawn (via a REVOKE operation on a consent token or globally by user action), its identifier is added to a cryptographic revocation structure (e.g., a Merkle tree or accumulator). Subsequent X-Consent-Proof presentations must prove that the consent artifact is not in the revoked set. This can be done with a zero-knowledge proof that incorporates the latest revocation tree root. The use of a tree allows efficient batch updates and privacy-preserving proof of non-revocation. Implementations MUST ensure that revocation information is promptly propagated (e.g., by updating a globally visible tree or list) and that proofs presented reflect the latest state.
  • Privacy Budgeting: For queries that can potentially leak information (especially analytics or SEARCH operations on multiple memories), MTAP supports differential privacy budgets. The X-DP-Budget header can be included by servers in responses to indicate how much of the user’s configured privacy budget was consumed by fulfilling the query. For example, a memory owner may allow an external data analyst to run queries up to a certain ε (epsilon) value of differential privacy. This mechanism, combined with monetization at Layer 5, ties consent tightly to controlled data exposure.
  • Governance and Compliance: Layer 4 also outlines how legal and policy frameworks map into the protocol. For instance, capturing a memory may require a “Consent-Context” indicating if the capture took place under explicit user action (“manual” vs. “ambient” capture, with different legal requirements). The protocol defines standard Consent Headers to carry such context or regulatory flags (e.g., marking data as containing personal health info, requiring HIPAA safeguards – see extension examples below). Implementers MUST comply with all relevant privacy laws (GDPR, etc.), but MTAP facilitates compliance via these standardized fields and proofs.
By embedding these features, Layer 4 ensures that “privacy is not an afterthought, but a core protocol feature”, using cryptography and structured metadata to enforce consent at a technical level. The approach is aligned with a zero-knowledge architecture and user-first privacy philosophy .
Layer 5 – Ecosystem Extension Layer
The top layer of MTAP provides for extensibility and ecosystem-specific features. Not all deployments will need or use all extensions, but this layer defines how new capabilities integrate into MTAP in a compatible way. It includes:
  • MTAP Extension Registry: A global registry of MTAP extensions, similar in spirit to IANA registries for MIME types or TCP option numbers. Each extension is identified by a unique Extension ID, which has a naming convention such as ext.<name>-v<version>. For example, the Memora project defines extensions like ext.dpve-v1, ext.emo-v1, ext.hipaab-v1. Each registered extension entry includes: an identifier, a category (descriptive grouping), the owner or authority maintaining it, and a URI to the extension’s specification. Implementations SHOULD consult this registry to recognize and properly handle extensions. The process for registering a new extension involves a submission to the governing body (see Governance section) or IANA if this becomes an IANA-managed registry. Conflicts in naming are avoided via the centralized registry and required documentation for each extension.
  • Media Types and Schemas: MTAP doesn’t reinvent file formats for content; instead it builds on MIME media types for memory blobs (images, video, audio, etc.). However, at the semantic level, MTAP can introduce standardized memory schemas – structured metadata formats for certain kinds of memories. For example, an extension might define a schema for an “Emotion metadata” track (ext.emo-v1 which could add fields for emotional tags detected in a memory), or an extension for a “HIPAA compliance pack” (ext.hipaab-v1 which ensures certain health data fields are included or redacted). These act analogous to MIME subtypes or file format profiles. The extension registry records the schema URL, so any platform encountering a memory with X-Memory-Schema: ext.hipaab-v1 can fetch the spec if needed to understand those fields.
  • Pricing and Monetization Schemas: To facilitate a data economy around memories, MTAP extensions can define standard ways to attach pricing and usage rules to memory access. The ext.dpve-v1 (Data Pricing & Value Exchange, as an example) defines how a data provider can publish a “pricing feed” or contract for queries. This might include a formula for cost per query or cost per epsilon of privacy budget consumed. A buyer’s application can use this extension to understand how to compensate the data owner for a given query (potentially via cryptocurrency or any agreed payment channel, but that transaction happens outside MTAP). The important aspect is that both sides interpret the pricing rules consistently. In effect, these schemas standardize the negotiation of value for memory data.
  • Plugin Handlers: The extension layer also supports pluggable functionality. For instance, a “memory analysis plugin” could be an extension where third-party modules (such as vision or NLP analyzers) register a handler for new memories. An example is an AI service that generates a text summary every time a new memory is captured. MTAP might not execute the plugin code itself, but it can define a message (or event via WebSocket) that gets emitted, following a known schema, which triggers these external plugins. Similarly, an extension might define a webhook or function interface for processing memory data in custom ways. By formalizing how plugins are registered and triggered (perhaps via an MTAP Registry entry that includes a hook URL or function signature), MTAP ensures ecosystem innovation without altering the core.
The extension layer’s design is such that all extensions MUST NOT break core interoperability. Unknown extensions should be safely ignorable or result in a graceful error if they are critical. Extension identifiers in messages (headers, schemas, etc.) allow for discovery and negotiation. For example, during a session initiation, a client and server might exchange the list of extension IDs they support (capability negotiation) so they can agree on optional features (similar to HTTP/2 settings or MIME Accept parameters). Over time, popular extensions may be incorporated into the core or remain optional based on adoption.
Summary
MTAP's layered architecture ensures a clear separation of concerns: transport independence, secure sessions, rich memory operations, built-in privacy/consent, and open extensibility. This is akin to how the Internet hourglass model separates network, transport, and application, with a narrow waist for universal interoperability.
MTAP's "waist" could be viewed as the core semantics (Layer 3) plus the consent enforcement (Layer 4) which every implementation honors, while Layers 1–2 and 5 allow flexibility and evolution.
Core Message Types & Formats
MTAP defines a set of core message types (or "methods") corresponding to the operations in Layer 3. Each message type has an associated expected request/response structure and semantics as described above. This section formalizes the message definitions, including their typical uses and required fields.
In an HTTP binding, these correspond to specific HTTP request paths or methods with custom headers; in a gRPC binding, they would be RPC calls; in WebSockets, they might be event types. This specification is abstract of transport, but we will illustrate with an HTTP/JSON binding for concreteness.
Message Overview
MTAP defines a set of core message types (or “methods”) corresponding to the operations in Layer 3. Each message type has an associated expected request/response structure and semantics as described above. This section formalizes the message definitions, including their typical uses and required fields. In an HTTP binding, these correspond to specific HTTP request paths or methods with custom headers; in a gRPC binding, they would be RPC calls; in WebSockets, they might be event types. This specification is abstract of transport, but we will illustrate with an HTTP/JSON binding for concreteness.
Each message type above is considered an operation in the MTAP API. In HTTP terms, these could be mapped to distinct endpoints or methods under a common base path (e.g., POST /v1/memories with a body could indicate CAPTURE by including X-MTAP-Verb: CAPTURE or a similar mechanism, or simply inferred from context). In gRPC, these would be separate RPC methods.
The exact mapping is left to the binding specification (see Layer 1), but normative requirements about headers and behavior apply regardless of transport.
Message Payloads & Schema
The payload structure for MTAP messages is typically a JSON object when using a text-based binding. For example:
CAPTURE Request Payload: includes either the raw memory content in the request body (for small items) or a reference to it. In many cases, large media (photos, videos) will be uploaded to a blob store (maybe via a pre-signed URL) and the CAPTURE request contains a blob_ref (URI to the content) along with the rich metadata.
CAPTURE Request Example
POST /v1/memories CAPTURE HTTP/3
Host: api.example.org
Authorization: Bearer 
Content-Type: application/json; charset=utf-8
Content-Digest: sha-256=:f0ae...=:
X-Moment-Type: image/jpeg
X-Consent-Proof: zkpv1:0x9af3…

{
  "blob_ref": "ipfs://bafybe.../photo.jpg",
  "metadata": {
    "timestamp": "2026-02-14T18:09:33Z",
    "device_id": "glasses-v4",
    "location": { "lat": 37.48, "lon": -122.15 },
    "tags": ["valentines", "sunset", "travel"]
  }
}
In this example (an HTTP/JSON binding), the CAPTURE request is an HTTP POST with a JSON body. The headers indicate the content's hash (for integrity), the type of content (JPEG image in this case), and a consent proof that the device is allowed to capture (perhaps proving user's consent for capturing at this moment).
The JSON includes a reference to the binary blob (which might have been separately uploaded to IPFS or cloud storage) and some metadata. The server would respond with 201 Created and a JSON body containing the memory_id and commit_hash for the new memory. The commit_hash might be a hash that covers both the content and metadata, possibly anchored in a ledger for audit immutability.
APPEND Request Payload
Parent Reference
Must specify the parent memory it's attaching to (via header or path)
Content Addition
Contains either an inline piece of content or reference, plus any new metadata
Response
200 OK with new revision info or 202 Accepted if processed asynchronously
The APPEND operation allows for adding annotations, relationships, or additional content to an existing memory. This creates a new version while preserving the original, maintaining an append-only model for auditability.
GET Response Payload
Raw Data Response
If the Accept header indicates a desire for raw data (e.g. image), the response can be the raw binary (with appropriate Content-Type).
Metadata Response
If metadata or a composite is requested, the response could be a multipart (binary + JSON metadata) or a JSON that includes a link to the binary.
Partial Content
For a video memory, might be a 206 Partial Content with a chunk if range was specified.
Memory-Meta
Includes fields like original timestamp, tags, owner, and possibly a pointer to a consent policy or classification.
SEARCH Request/Payload
Simple Text Search
{
  "query": "birthday party 2023"
}
The server interprets with full-text search and returns matching memory IDs with relevance scores.
Vector Search
The client provides a vector embedding (perhaps of some reference image or text) that the server will compare with memory embeddings.
The X-Query-Expr header might be used to differentiate the query type or to carry a compact encoded form.
Result Format
{
  "results": [
    {
      "memory_id": "...",
      "score": 0.95,
      "snippet": "…"
    },
    ...
  ]
}
Pagination uses standard methods (e.g., ?page=2 or continuation tokens in the result).
REVOKE Request Payload
Memory Revocation
If revoking a memory, the payload might simply confirm the action (the primary identifier is already in the header or URL).
Consent Revocation
If revoking a consent, it might include details like which delegate or which consent artifact is being revoked.
Server Response
The server on success returns a 200 OK with a revocation receipt JSON, e.g.:
{
  "revoked": "",
  "status": "confirmed",
  "timestamp": "...",
  "log_ref": ""
}
After this, any attempt to access the revoked memory (or using the revoked token) MUST be denied.
AUDIT Response Payload
1
Log Entry Structure
Each entry might include fields like event_time, event_type (e.g., CAPTURE, GET, SHARE), actor (which identity performed it), target (memory or consent id), result (success/failure code), and cryptographic fields like event_hash and possibly a Merkle proof linking it to a global log root for integrity.
2
Response Format
The response may stream this as NDJSON (newline-delimited JSON) or another format if large. The client can verify the hashes against a known root or ask the server for the latest signed root of the log.
3
Tamper Evidence
This provides tamper-evidence: if an event were removed or altered, the hashes wouldn't match.
Standard Headers & Metadata
X-Moment-Type
The media type of the memory content (e.g., image/jpeg, text/plain, video/mp4). This guides how the content is processed or stored.
Content-Digest
A strong hash of the content (and possibly metadata) being sent. Follows the HTTP Content-Digest header format (e.g., sha-256=<base64> as per RFC 3230 for instance).
User-KeyID
An identifier for the user's key or identity used in capturing or signing this request.
X-Consent-Proof
A proof that the requester holds a valid consent artifact. Format could be zkpv1:<proof-bytes> or a reference to an external proof.
X-Policy-Snapshot
An identifier (e.g., hash or version tag) of the privacy policy in effect.
X-Memory-Tags
A comma-delimited set of tags or labels assigned to the memory.
MTAP standardizes several HTTP-like headers to convey protocol-specific metadata, especially for privacy and governance. These headers are used across the core messages as needed and form an essential part of the MTAP specification.
Cryptographic Techniques
End-to-End Encryption
All memory content MUST be encrypted in transit (TLS 1.3 or better for HTTP/gRPC, which is typically mandatory on the Internet). Additionally, at rest, it is RECOMMENDED that memory blobs are stored encrypted with keys under user control (server-side encryption at a minimum, or client-side encryption for zero-knowledge scenarios).
Metadata may be stored in plaintext on the server to allow indexing, but sensitive fields (faces detected, personal identifiers) should be encrypted or redacted unless needed.
Digital Signatures and Integrity
Each memory captured generates a content hash (commit hash). This hash can be digitally signed by the capturing device or user's private key (if a device has a trusted hardware module, for instance). Doing so provides non-repudiation (proof that a certain user/device captured that exact content).
At minimum, the server will store the hash to detect any tampering. Optionally, a Merkle tree can be built from successive memory hashes to create a tamper-evident log (similar to Certificate Transparency logs).
Zero-Knowledge Proofs (ZKPs)
MTAP uses ZKPs for consent verification (and potentially other privacy features). The design does not prescribe a single ZKP system, but it envisions something like: each consent artifact is represented as a token or credential that the user (or an identity provider) signs.
The server keeps a root of a Merkle tree of valid consents (or revoked consents). The client can then prove knowledge of a path in that tree without revealing which one, thus proving they have some consent in the valid set.
Security Model & Considerations
This section outlines the security model for MTAP, including assumed threats and how the protocol mitigates them. MTAP is designed for a high-stakes context (sensitive personal data), so the security model is robust and multilayered.
Threats & Mitigations
Eavesdropping
An attacker on the network might try to intercept memory data (which could include private images or recordings).
Mitigation: All communications are encrypted via TLS. Additionally, memory content can be encrypted end-to-end so that even the server can't see it without a key (if using a zero-knowledge architecture where possible).
Unauthorized Access
A malicious application or user may attempt to fetch someone else's memories without consent.
Mitigation: Strict authentication (Layer 2) and authorization checks on every request. By default, no user can access another's data unless a valid consent proof is provided (Layer 4). Even with consent, access can be scoped (a delegate token might only allow certain operations).
Tampering
A malicious party might try to alter a memory's content or metadata (e.g., change timestamps, edit the photo) either in transit or after storage.
Mitigation: The content digest and commit hash provide cryptographic verification. The commit hash is stored and possibly publicly anchored, so the server (or any verifier) can always recompute the hash of the content+metadata and compare.
Assumed Environment: MTAP operates over the Internet (or local networks) with potentially untrusted clients and servers. It assumes the transport layer (TLS/QUIC) provides confidentiality and basic integrity against network attackers. However, we consider threats from malicious clients, malicious servers, insider abuse, and external attackers trying to access memory data.
Extension Mechanism & IANA Registry
MTAP's extension mechanism (Layer 5) warrants additional specification. Extensions can define new headers, message types, metadata schemas, or protocols that work within the MTAP framework. To ensure interoperability, MTAP will use an open registry approach for extensions, similar to how MIME types and HTTP headers are registered with IANA.
Registry for MTAP Extensions
This specification requests the creation of a new registry called the "MTAP Extension Registry" (to be maintained by IANA or the designated MTAP governing body).
When an extension defines new headers or message fields, those should be clearly outlined in its spec. Optionally, the registry could cross-reference any IANA sub-registries (for example, if an extension defines new HTTP headers, registering those headers with IANA's HTTP Field Name registry might be appropriate too).
Clients and servers should handle unknown extensions gracefully. A client receiving an unknown extension identifier in a message (say, an unknown field in metadata or an unrecognized header) MUST NOT break or discard the entire message; it should ignore what it doesn't know, possibly logging a warning.
Example Flows
To illustrate how MTAP works end-to-end, this section walks through two sample use-case scenarios: (1) memory ingestion from an edge device, and (2) a consent-restricted memory search performed by a third-party (data buyer or researcher). These examples are not normative but help clarify the interplay of the layers and protocol elements described above.
Example 1: Memory Ingestion via Edge Device
Capture Initiation
Alice says "Remember that" to her smart glasses at a family reunion. The device captures an image of an old photograph, ambient audio, time, location, and context.
Transport and Session
The glasses connect to Alice's personal MTAP server over HTTPS (HTTP/3) using TLS. The device authenticates using a device certificate or OAuth token.
Memory Semantics
The device sends a CAPTURE request with appropriate headers and metadata. The photo is uploaded to a content-addressable store with an IPFS URI reference.
Consent & Privacy
The device attaches Alice's default "Personal memories" policy. Since this is her own memory, no special consent proof is needed.
Server Processing
The server authenticates the request, verifies the content digest, creates a new memory record, and possibly performs analysis if extensions are enabled.
Response & Confirmation
The server responds with 201 Created and a JSON body containing the memory_id and commit_hash. Alice's device gives a notification that the memory was captured.
Example 2: Consent-Restricted Memory Search by a Third-Party
Consent Onboarding
Bob opts into a research program for Alzheimer's study. He grants consent for the university to analyze his voice journals under strict privacy conditions.
Search Request
A researcher queries Bob's data for speech patterns indicating memory lapses. The request includes a zero-knowledge proof of consent and specifies a differential privacy budget.
Authentication & Verification
Bob's MTAP server verifies the consent proof and checks that the requested privacy budget is within allowed limits.
Privacy-Preserving Processing
The server executes the query but only returns aggregated statistics with differential privacy noise applied, not raw memory data.
Response Delivery
The server responds with anonymized results and headers indicating how much privacy budget remains.
Audit and Accountability
The transaction is logged in Bob's audit trail, allowing him to verify how his data was used.
This scenario demonstrates how MTAP can facilitate a data sharing economy where individuals can safely contribute their personal data for collective benefits (like research) without losing control. The combination of consent management, differential privacy, and audit logging ensures that even third-party access can be tightly regulated in line with the user's wishes.
Compliance Levels and Certification
Not all implementations of MTAP will support every feature from day one. To encourage broad adoption and a minimum baseline of interoperability, this specification defines Compliance Tiers (Level 1–3) for MTAP implementations, along with guidelines for certification at each level. These tiers provide a path for implementers (especially new entrants or constrained devices) to incrementally adopt MTAP while still being recognized as compliant, and signal to users what capabilities to expect.
Compliance Tiers
Level 1 – Basic Compliance
At Level 1, an implementation supports the fundamental core of MTAP for personal use. This includes at least one transport binding, core CAPTURE/GET/REVOKE operations, basic authentication, and simple consent model. Suitable for personal memory devices or apps without sharing capabilities.
Level 2 – Standard Compliance
Level 2 adds full interoperability and sharing features. Implementations must support all six core verbs, delegated access, consent artifacts with revocation, and should implement differential privacy. Suitable for fully functional MTAP services supporting personal and small-scale multi-user deployments.
Level 3 – Advanced/Enterprise Compliance
Level 3 is the highest tier for enterprise or cross-industry use. It requires support for all transport bindings, full cryptographic suite with ZKPs, comprehensive privacy controls, numerous extensions, and alignment with regulatory compliance frameworks. Suitable for cloud providers, large platforms, or specialized services like memory banks for medical use.
An industry consortium will oversee a certification program ("MTAP Certified") to verify and badge implementations. The program would provide a test suite and interoperability tests, with those passing receiving an appropriate certification seal.
The tiered approach balances inclusivity (even small projects can implement Level 1) with aspiration (to reach Level 3 for full capability). Over time, as technology matures, the bar for each level can rise as features become more common.
Governance and Standardization
To ensure MTAP's longevity, neutrality, and global adoption, a strong governance model is proposed. MTAP is more than just a technical spec; it aims to be an open standard supported by industry and community, much like HTTP, with formal and informal structures guiding its evolution.
Open Memory Foundation (OMF)
A dual-structure foundation is being established to steward MTAP and related initiatives. It consists of a U.S. 501(c)(6) non-profit (an industry consortium) and an EU AISBL (international non-profit association).
The OMF's mission is to maintain the MTAP standard, promote interoperability, and certify implementations. It will likely own trademarks and possibly manage the extension registry if not delegated to IANA.
IETF Standard Track
MTAP is being brought to the IETF for standardization. The plan is to form an IETF Working Group in the Applications and Real-Time (ART) area, with a "Birds-of-a-Feather" (BOF) session anticipated at IETF 118 in late 2025.
By standardizing through IETF, MTAP gains the benefits of open process, expert review (especially on security), and formal recognition which aids adoption in enterprise and government.
Hybrid Approach
During standardization, MTAP developers are pursuing a hybrid approach: maintaining an open source reference implementation via the foundation, while simultaneously working within IETF.
This ensures that running code informs the spec ("rough consensus and running code" philosophy). The reference implementation is already at Draft-03 alignment, with plans for a 1.0 release by Q4 2025.
The governance model is designed to balance innovation with stability, ensuring rapid progress through community collaboration while solidifying the standard through IETF and formal bodies for the decades to come. The personal and societal importance of memory data drives a high responsibility to get governance right: no single company should control the standard, and users' interests must remain central.
Security Considerations
Privacy-First Design
This protocol is designed with privacy and security as first-order goals, given the sensitive nature of personal memories.
Cryptographic Requirements
Implementers should pay particular attention to the cryptographic requirements and consent enforcement mechanisms.
Implementation Risks
Any deviation or incorrect implementation of these could seriously undermine user trust and safety.
Evolving Security
Security is an evolving target; as new vulnerabilities are discovered, the MTAP community MUST adapt and update the standards accordingly.
See "Security Model and Considerations" section above for a detailed threat analysis and mitigations.
IANA Considerations
MTAP Extension Registry
This document will require the establishment of the MTAP Extension Registry as described.
Header Registrations
Potentially new registrations for specific headers (if they move to standard header names without the X- prefix in a future revision).
Future Details
A future version of this draft will include the exact registration templates for the initial extensions and any HTTP headers or other protocol constants introduced by MTAP.
References
Normative References:
  • Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997.
  • Fielding, R., et al., "Hypertext Transfer Protocol Version 1.1 (HTTP/1.1)," RFC 7231, June 2014.
  • Thomson, M., et al., "HTTP/3," RFC 9114, June 2022.
  • Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3," RFC 8446, August 2018.
  • Fette, I. and A. Melnikov, "The WebSocket Protocol," RFC 6455, Dec 2011.
Informative References:
  • Memora Project, "Memora Documentation (MTAP Draft-03 Excerpts)," 2025. (Examples and context used in this document)
  • GDPR, EU Regulation 2016/679, April 2016. (Regulatory backdrop for consent and data protection)
  • Diffie, W. and Hellman, M., "New Directions in Cryptography," IEEE Transactions on Information Theory, 1976. (Foundational work inspiring MTAP's cryptographic approach to consent).