Memory Model Design for TinyRustLM

Full report

On this page

1. Executive Recommendation and Terminology

TinyRustLM will use a local-first memory model: by default all AI computation and data reside on the user’s device, with optional cloud sync. In Local-only mode, the model and memories are entirely browser/device-local – “model bytes come only from local files or your paired companion; prompts stay in this browser”. In this mode TinyRustLM continues chatting offline without external servers. In Local-sync mode, users may explicitly export/import or peer-sync their local memory files (e.g. via file sync or P2P), allowing shared context across devices while still owning the data. Tonksy’s local-first approach illustrates that data should “prefer keeping your data local” but can “sync occasionally” via common services like Dropbox (using CRDT merge to avoid conflicts). Finally, Worldwide-sync mode uses MemoryEndpoints.com as a hosted memory endpoint: durable memory is stored remotely for cross-device continuity when online, with a bounded local replica cached for offline use. Importantly, hosted sync is explicit and must not be assumed available offline; users need to invoke an export or maintain a local copy before disconnecting. For terminology: we call the “transient chat context” the current conversation buffer (fed into the model’s prompt/slot), short-term local state any ephemeral knowledge extracted but not yet committed to long-term storage, local durable memory the device’s persistent memory store, and hosted long-term memory the synced memory at MemoryEndpoints. We treat model weights, tokenizers, and templates as immutable baselines, and stress that user instructions (latest request) are authoritative over any memory context. As MultiAgentMemory docs note, “current messages stay separate from durable memory so active coordination does not silently become long-term fact”. In practice this means TinyRustLM will never auto-convert raw chat into persistent memory without explicit user action, and memory updates never implicitly rewrite the model’s parameters.

2. State Taxonomy and Authority

• State lifetime/authority: Model parameters and tokenizers are static under normal use. KV and recurrent states change token by token during inference, but exist only in RAM and vanish on restart (they do not survive process exit). Local short-term and chat context live for the conversation or session; durable memories live as files or database entries. Only explicit user actions (e.g. invoking a “save memory” operation or fine-tune) change persistent state. Hosted memory events are written only when synced, and routines like log/audit entries are ephemeral (e.g. MemoryEndpoints deletes old logs after 7 days).
• Reset behavior: Ephemeral caches are reset on each new session or explicit clear. Local durable memory persists across restarts unless user clears or profile data is wiped. Sync metadata uses monotonic revision vectors (no automatic resets except re-registration).
• Privacy and trust: All local state is kept on-device (trusted by the OS/protected by credentials); hosted memory is an untrusted data source (we treat it as data to be fetched, not instructions). The model treats both local and hosted memories as contextual evidence, not as commands. We never embed credentials or secrets in memory or prompts, per secure design.
• Memory complexity: The largest state is the model weights (billions of parameters). The LFM’s design minimizes context cache: e.g. LFM2 uses recurrent layers (with fixed state) for 75% of layers and only 25% GQA layers with a small KV cache. Thus the runtime cache footprint is modest (a few GB at 32k tokens). Durable memory grows with use, but can be capped or pruned by user. Sync metadata and indexes are relatively small.

3. Adaptation Claims vs Cache vs Durable Memory

Public Liquid AI claims (e.g. “networks that adapt in real time to new data streams”) suggest on-the-fly learning. However, analysis of released LFM checkpoints shows they behave like conventional inference models. What changes token by token? Only the model’s internal state (hidden activations) and any optimizer state (if batch processing)—not the learned weights. For LFM2, 18 of 24 layers use a fixed recurrent state (no KV cache) and 6 use Grouped Query Attention with a reduced KV cache. Each new token updates these caches and recurrent states, but the trained parameters (weights) remain constant. No weight or adapter values change during inference. After a process restart, all KV/recurrent states vanish, so nothing persists besides the original weights. In short, Liquid models do not perform weight updates token-by-token; they simply use continuous-time hidden dynamics to produce output.

To call this “continual learning,” one would need evidence of persistent model updates tied to data (e.g. checkpoint diff before/after running on new text). By contrast, what Liquid shows is “powerful stateful response” under static weights. Cache-like state (KV or recurrent memory) is intrinsic to the architecture’s context handling, not a user memory. As MultiAgentMemory emphasizes, “active coordination does not silently become long-term fact”. In other words, the LFM’s ephemeral state is not a substitute for an explicit memory store. A user’s conversation turns are fed into the model’s hidden state, but unless the system explicitly writes data to a memory store, those inputs do not become durable facts. Thus, claims of real-time adaptation without training are misleading: actual continual learning would require permanent parameter changes, which LFM inference does not do.

4. Three-Mode Product & Storage Architecture

We propose three first-class modes, each with distinct storage and sync semantics:

• Mode 1 – Local-Only: The model and memory are entirely local. The TinyRustLM app operates offline with no cloud sync. Memory stays in the browser/device (e.g. IndexedDB or OPFS file) or is exportable via file. This is akin to TinyRustLM’s default local WASM runtime. No hidden services: users always have control and offline continuity.
• Mode 2 – Local + User-Controlled Sync: Default local memory is available as in Mode 1. The user can manually export/import memory or use peer-to-peer/file syncing for cross-device continuity. For example, each device could keep its own local append-log (like a CRDT op log) and share it via a file-sync service. Conflicts are resolved by design: one strategy is “one file per device” (no file-level sync conflicts) plus CRDT merging inside. We would provide explicit UI/actions for “Sync to file” or “Import memory from file” rather than silently syncing.
• Mode 3 – Worldwide Sync (MemoryEndpoints): The user opts into storing memory in the MemoryEndpoints service for seamless cross-device memory. In this mode, the app maintains a bounded local replica (e.g. recent working set) and continuously syncs with MemoryEndpoints when online. Hosted memory augments local memory but never replaces it. The user is reminded that without an explicit local copy, the model will lose access offline. The service’s contract (via MemoryEndpoints.com) handles storage of semantic memory events with conflict-safe sync protocols (see next sections). Critically, when offline, the app uses only its local replica – no hidden background fetching. In all modes, the user’s latest explicit instructions take precedence over any stored memory context.

The architecture separates “active session” vs “durable memory”. For example, MemoryEndpoints implements a current-message lane (ephemeral) and a durable memory store. We follow that pattern: the agent’s current conversation and short-term context are not merged into memory until explicitly saved. Local memory is locked to the user’s profile (e.g. Web Auth ID) and cannot be accessed by others without permission. In Mode 3, credentials/tokens gate access to the hosted endpoint (see section 8).

5. Offline Transition Protocol

Connectivity detection: The UI monitors online status (e.g. navigator.onLine or network heartbeats). A status indicator shows “Online” or “Offline” at all times, with an accessible label (“Status: Offline” text + aria-label). Explicit Sync: Before going offline, users should click “Sync Now” to flush pending writes. The app also automatically attempts sync when network drops or reconnects, showing progress. Checkpoint completeness: The app keeps a durable journal (IndexedDB or OPFS) of all memory writes. When syncing, it ensures all local writes are acknowledged by the server. If power loss or disconnect occurs mid-sync, on restart the app will resume by comparing local and remote revisions (using vector clocks) and retry missing operations. Pending writes remain in the local outbox journal until confirmed. The UI should show a compact “Sync Status” (e.g. green/✓ synced, amber/! syncing, red/× error), with a text equivalent for screen readers (e.g. aria-live="assertive" notifications). Stale hosted state: When offline, any last-synced memory is used. If server state has advanced in the meantime, the app will reconcile on next sync (see section 6). No silent rollback: user is warned of potential conflicts. Token/session: If credentials expire while offline, local memory can still be used; sync will simply fail until re-login. The app must not auto-send credentials over insecure links. User-visible status: The UI explicitly notes “Offline mode: Chat and local memory available; hosted memory is disabled.” Hover tooltips or help text explain the modes (see section 10). For example, hovering the status icon might say “No internet – using only local memory.” This message must also be in plain text (keyboard/AT accessible). Conflict risk: The app may disable certain operations offline (like inviting collaborators) that require server round-trips. If the user edits shared memories offline, they will be flagged for manual resolution on reconnection. In summary, after network cut the user can still chat and access local memory and limited features, but hosted sync and any workspace-wide features pause. An on-hover or status label indicates “Offline: local memory only”.

6. Sync, Conflict, Tombstone, and Recovery Semantics

We use a CRDT-inspired outbox/inbox sync model with causal versioning. Each device maintains a local monotonic revision counter (lamport/time) and an immutable log of memory operations (adds/updates/deletes). On sync, devices exchange version vectors and only transmit missing operations. We employ tombstones for deletions: when a memory record is deleted or superseded, we mark a tombstone with its original ID and revision. This ensures idempotency and prevents deleted notes from reappearing. Each operation is content-hashed (for deduplication) and tagged with a persistent ID (avoiding repeated application). The authoritative source for any memory record is determined by a workspace/project-level timestamp order, except where we allow field-level merging for truly commutative updates. In general, we avoid simplistic last-writer-wins (LWW) on entire records; instead we apply merge-on-field where safe or fall back to user conflict resolution prompts if automatic merging is ambiguous.

For example, if two devices independently edit different fields of a memory record, the merge keeps both changes. If they edit the same field, the one with the higher logical timestamp (or from the user-authoritative device) may win, or the system may flag a conflict for user review. All sync uses idempotent journals: devices buffer outgoing operations locally, retry until ACK, and apply incoming ops exactly-once via stable IDs. We set a bounded retry window and exponential backoff. Atomic local promotion: when a sync batch fully applies, we commit it as an atomic revision in local storage (e.g. using IndexedDB transactions or OPFS atomic writes).

This approach follows the MemoryEndpoints model: “device epochs, immutable revisions, monotonic checkpoints, authoritative heads, tombstones, and redacted receipts support conflict-safe memory replication”. We compare strategies:

• LWW: simple but risks lost updates if clocks skew. Not preferred for important user memories.
• Operation Logs (CRDT): our chosen approach, since it allows offline edits and ensures eventual consistency.
• Field-level merge: used within operation logs when structurally defined (e.g. updating different attributes of a memory).
• Explicit user resolution: if an irreconcilable conflict arises (same field changed differently), we prompt the user to pick or merge. Because MemoryEndpoints discourages hidden LWW, we will similarly log conflicts for review rather than overwrite silently.

In short, every memory write gets a unique ID and vector timestamp. On sync, we exchange inbox (remote updates) and outbox (local pending), merging based on vector metadata. Deletions emit tombstones. This guarantees no lost writes or resurrected data unless re-added by user. A sync completion criteria is when both sides’ version vectors align. The system reports “Up-to-date” status or surfaces any conflicts needing resolution.

7. Browser & Companion Storage Boundary

On-device memory will leverage browser-managed storage (IndexedDB and the Origin-Private File System) by default, with optional external companion storage if installed.

• IndexedDB: Supported in all major browsers. It offers asynchronous, queryable storage for key/value or objects. It can hold very large data (up to tens of gigabytes by default: 60% of disk on Chrome, 10% on Firefox). It is subject to eviction if space runs low (best-effort mode) unless the origin requests persistent storage. We should use navigator.storage.persist() so that user data isn’t silently purged. Multi-tab access to IndexedDB requires write locks, so we will serialize writes or use a locking scheme (e.g. “leader tab” or IndexedDB’s inherent versionchange blocking). For large binary data (e.g. audio memory), IndexedDB can store Blobs or use OPFS + SQLite on top of OPFS.
• OPFS (Origin-Private File System): Available in Chrome and Safari (not Firefox yet). OPFS provides a sandboxed file system API for an origin, with directories and files. It uses the same storage pool/quota as IndexedDB and Cache. We plan to use OPFS for the bulk memory store (e.g. a SQLite database or JSON files) when available, since it allows streaming large files and simpler atomic commits. We should fall back to IndexedDB if OPFS is unavailable (e.g. on Firefox). OPFS files aren’t directly user-accessible on disk.
• Service Worker Cache API: Not used for our data, since it caches HTTP assets, not arbitrary memory. We rely on explicit API writes instead of passive request caching.
• Companion App (Rust/.NET): On desktop, an optional companion can expose a secure file store or system database. If used, it should be limited to local memory (e.g. write the .uai memory files). We must still encrypt any sensitive data on disk. An external app can overcome browser quotas (writing to user directories) and avoid eviction issues, but introduces another trust boundary.
• Ephemeral Session Memory: In-memory JS variables hold current state, but must be serialized before unloading. We will treat them as ephemeral and not rely on them for persistence (users might close the tab).
• Quotas: Chrome allows ~60% of disk per origin; Safari similar (60% in browser, 15% in WebView); Firefox 10% by default (10GB) with 50% persistent option. We should monitor usage via navigator.storage.estimate() and warn the user if approaching limits.
• Eviction: By default storage is best-effort. Browsers may evict origin data if unused or on low disk. Safari notably prunes unused origin data after ~7 days. To avoid unexpected loss, we request persistent storage and advise users to back up their memory (e.g. export file).
• Profile deletion/backup: We must consider that clearing a browser profile or reinstalling the app will lose IndexedDB/OPFS content. We should offer export/import of memory. For companion apps, we could integrate OS backup (e.g. iCloud, Windows backup) if available.
• Corruption & recovery: We should use transactional writes (IndexedDB transactions or atomic OPFS writes) and checksums. On startup, verify memory store integrity; if corruption is detected, use the last backup or prompt user.
• Multi-tab locking: Only one instance should actively write to local storage. Others can read. We can elect a single “leader” tab or use a mutex (IndexedDB lock or BroadcastChannel elect). Writes from the agent will be queued in IndexedDB and flushed sequentially.
• Crash recovery: On crash, no writes should have been lost thanks to IndexedDB atomicity. On reload, the app will resume from the last committed state (journal-outbox style).
• Large-memory streaming: If using OPFS, we can stream reads/writes (e.g. write memory sequentially without loading whole object). If only IndexedDB is used, large Blobs may still fit due to high quotas, but we should chunk operations.

8. Hosted Sync Credentials and Security

For MemoryEndpoints sync we require an authenticated session token. Best practice is to use short-lived tokens (e.g. OAuth2 access tokens) with explicit “remember me” opt-in if persistence is desired. Tokens should be stored only as HttpOnly Secure cookies (if using a webview) or in memory; never in localStorage or plaintext files. If storing across sessions, we should use the Credential Management API or a secure storage (Web Crypto + IndexedDB encryption) after explicit user consent. The user must explicitly enable “stay signed in”, which triggers storing a refresh token in the OS credential vault if available, rather than the browser’s cleartext storage.

URL/referrer leakage: All API calls must be POST with credentials in headers, never in URL. We should set referrerPolicy: "no-referrer" or use window.fetch to avoid leaking token via referer logs.

Logging/screenshots/traces: The app must scrub tokens from any logs or error reports. If a support snapshot is taken, tokens should not be recorded. Dev logs should mark tokens as “[REDACTED]”.

Clipboard: Do not copy tokens to clipboard or allow memory records to contain them. We will validate memory entries to strip or warn on any content resembling credentials.

Browser extensions: Advise users that malicious extensions could read their tokens if running in the same origin. Encourage only trusted extensions.

Rotation & Revocation: The server API should support token revocation. If a device is lost, the user (or system) can invalidate its token remotely. Our app will detect a revoked token on next sync (401 error) and require re-authentication. We should allow device-specific keys so one device’s compromise doesn’t break all devices.

Session-only vs persistent: By default, use session-only tokens that expire when the browser app is closed; persistent tokens only if user opts-in (with user agent confirmation).

Importantly, credentials are never part of prompts or memory. OWASP warns not to store tokens in localStorage or sessionStorage, and we follow that by using cookies or in-memory JS objects. Any user action that sends credentials (login) should be isolated from the AI context: the model should never see them.

9. Privacy-Preserving Encryption and Identity

We offer a spectrum of privacy modes for memory:

• Local plaintext under OS protection: By default, local memory is stored unencrypted, relying on device OS (e.g. disk encryption) to protect it. This allows full-text search and indexing with no overhead, but risks data exposure if the device is compromised.
• App-level encryption (user passphrase): The user can optionally set a passphrase to encrypt the local memory store (using Web Crypto). Keys can be derived on each session (ask user for passphrase on startup). This means the service itself never sees raw data. However, search will be limited to meta-data or on-device search (no cloud search). Key management: we must offer a recovery or key reset flow if the user forgets (knowing they risk losing all memory). Revocation: user can change passphrase any time, re-encrypting future data (old data is effectively lost if new key).
• End-to-End Encryption (E2EE) with per-device keys: For hosted mode, the ideal is E2EE: memory is encrypted on device and only decrypted on a user’s other devices. This requires a shared key among the user’s devices. We can derive a master key on first sign-in (via passphrase or OS key store). Memory data (and possibly search index) would be stored encrypted on the server. The trade-off is search: we cannot have a server build a text index on encrypted data. One could implement searchable encryption or invert the flow (devices download encrypted memory and search locally). Without a known practical searchable-encryption scheme, we would likely only synchronize encrypted records and leave retrieval/ranking to the client. Recovery: if a user loses all devices, they must have a backup of their key (or a password) otherwise memory is unrecoverable. We caution that claiming full E2EE with rich search is infeasible without complex cryptography.
• Server-readable mode: If the user opts for simpler sync, the server can index and search memory, trading off privacy for convenience. (Not E2EE.)
• We may offer hybrid: e.g. encrypt sensitive fields before sending (so server sees keywords only). Each device could have a unique key (tied to login) or share a user root key.
• Device keys & recovery: We plan per-device key encryption: each device has a local key pair. The public key goes to server; encrypted memory is stored with the user’s public keys. The private keys are on device (optionally in OS keystore). Recovery means either retrieving encrypted backup and decrypting with user’s credentials, or using a recovery phrase.
• Revocation: If a device is lost, we remove its public key from server and refuse to sync memory to it. Memory remains E2E-secure from that device.
• Availability vs security trade-off: If the user prioritizes cross-device search and forgot keys easily, they may accept server-readable data. If privacy is paramount, we offer offline-only mode (no Cloud) or strong encryption with manual backup.

We will not promise true E2EE search without explaining its limits. Our design can allow per-user encryptions, but feature compatibility (global search, ML features) may be reduced. The UI should let users choose their encryption level, with clear warnings about recoverability.

10. Retrieval Precedence and Untrusted Memory

When composing prompts, TinyRustLM will merge memory carefully. We enforce contextual prioritization: the immediate user request always overrides stale profile data. Retrieval logic: we rank candidate memories by relevance, recency, and confidence. We maintain metadata (source, timestamp, confidence) as recommended by best practices. Memories marked “expired” or inconsistent (conflicting with known facts) should not be injected. For example, if a user preference in memory is years old but the user now states the opposite, we prefer the new statement and suppress the old.

Each memory item carries provenance (where/when it was extracted). Before injecting, we check for contradictions: if a fact directly conflicts with the current context (e.g. “My favorite color is blue” vs “I said pink today”), we flag it. We also do freshness filtering: older memory may be downweighted or elided if it conflicts with recent chat. We never delete history silently; instead we treat stale data as untrusted suggestions and ask the user if necessary. For example, if a retrieved memory suggests a step that contradicts the user’s last command, we leave it out. This aligns with the PromptLayer guideline to “filter and order memories by relevance, freshness, permissions, and conflict risk”.

We use a schema for memories (with status fields, created_at, last_seen_at, confidence). Short-term session data (temporary workflow state) has a short TTL; user preferences get longer TTL. When memory is retrieved, we include its metadata as comment or pointer (e.g. “You told me that…”) for transparency. The model always sees “explicit user request” at top of prompt, ensuring user control. If a memory is questionable, the system can prompt “Is this still true?” rather than forcing it as fact. In sum, injection is controlled: “official user commands > high-confidence memories > lower-confidence memories” in that priority order. We never convert memory content into instructions without prompting the user, and we allow them to correct memory via explicit commands (which then update or delete the memory record).

11. User-Facing UI Copy (Hover/Status Text)

We provide clear, reassuring status messages:

• Local-only mode: “Connected locally – all chat and memory stay on this device.” (Hover: “Your AI chat and memories are stored only on this device. Internet is not required.”)
• Local-only offline help: “Offline: chat continues using local memory.” (Hover: “You’re offline. You can keep chatting with your local AI and memory.”)
• Sync-needed: “Sync pending – memory not yet uploaded.” (Hover: “Some recent memories haven’t been synced. Connect to upload.”)
• Mode 2 (Local+manual sync): “Local memory (sync via import/export).” (Hover: “Your memories are on this device. Use Export/Import to move them to another device.”)
• Mode 3 (Hosted): “Worldwide memory enabled.” (Hover: “Your memory is stored on MemoryEndpoints for cross-device use. Connect to sync.”)
• Offline in Hosted mode: “Offline: using local copy; hosted memory unavailable.” (Hover: “No internet. Only local memory is available; connect to sync worldwide memory.”)
• Error/Warning: “Sign in to sync memory” or “Memory sync paused.”

Copy is factual, not alarmist. For example, “Local chat continues offline; hosted memory will resume when back online.” We avoid words like “fail” or “danger”. For each mode:

• Local-only: “Chat and memory live on device only; great privacy.”
• Local w/sync: “You have local memory. Use file-sync or MemoryEndpoints to share memory across devices.”
• Hosted: “Memory synced globally (requires internet).”

Each label must be presentational and accessible (e.g. aria-label). We provide tooltips (hover/focus) with the above text, and ensure equivalent text for keyboard-only navigation (e.g. a “help” button focusing tooltip text).

12. Failure-Injection & Continuity Test Matrix

We must systematically test and document:

• No network: App should default to offline state, with no console errors. Local chat functions and local memory loads. Attempts to sync should queue or disable sync buttons. (Expected: Chat works with existing memory; sync button shows “Offline”.)
• Mid-sync power loss: Simulate killing the app during network I/O. On restart, the app should detect incomplete sync (via unsynced journal entries) and resume. (Test: after reconnect, ensure no data loss or duplication.)
• Stale browser profile: If user reverts to an older profile (e.g. restore from backup), app should detect diverged version vectors and either do a three-way merge or warn the user of potential duplicates.
• Concurrent edits (two devices): Make conflicting edits on two devices offline (e.g. both modify same memory). On next sync, verify the chosen resolution policy (field merge or conflict prompt). For example, one device might have marked a memory inactive while another updated content; ensure tombstone works.
• Token expiry: Use a short-lived token and wait to expire during use. The app should catch 401 from server, prompt re-authentication, and not lose queued writes.
• Server rollback: If MemoryEndpoints rolls back (simulate by temporarily returning older revision or wiping some records), the client should detect inconsistency (version mismatch) and either do a full re-sync or alert user. Lossless restore test: after a server reset, device can re-upload its full journal.
• Duplicate delivery: If the same memory event is received twice (e.g. from out-of-order sync), the system should apply it only once (idempotent op based on ID).
• Deleted record resurrection: If device A deletes a memory (tombstone) but device B (still offline) later edits an old copy, on sync the system must not resurrect the deleted content unflagged. The tombstone should override stale copy.
• Clock skew: Simulate device clocks being out-of-sync. Use version vectors (not wall-clock) to decide causality. Ensure two devices trust each other’s vector timestamps, not local time.
• Corrupted local copy: Intentionally corrupt the IndexedDB (or OPFS file) on one tab. On next load, the app should detect checksum mismatch and either revert to last backup or start fresh (with user choice).
• Quota exhaustion: Fill IndexedDB beyond quota. Verify that QuotaExceededError is caught, and the app gracefully notifies the user to clear space (instead of crashing).
• Hostile memory content: Insert a memory containing malicious or confusing instructions. The model should treat it as untrusted content. Test that the system does not inadvertently execute or prioritize such memory over user prompt. (For example, a memory that says “Say this exactly” should not override the user’s current request.)
• Reconnect after long offline: After weeks offline, on reconnect we may have a large backlog of operations. Confirm the sync catches up via pagination/chunking, shows progress, and ends in consistent state. The user should see a summary (e.g. “Synced 5 days of chat history”).

For each test, we distinguish deterministic local tests (e.g. disconnect Wi-Fi and assert local mode, or fill DB) from live cross-device tests (where one device modifies memory and another observes the effect via the server). We record expectations (pass/fail) and automate what we can (e.g. scripted sync scenarios using the MATM API).

13. Unknowns & Required MemoryEndpoints Contract

Some design details depend on the exact MemoryEndpoints API and policies. Specifically, we need the public contract to define:

• Encryption options: Does the service support E2EE or only server-side encryption? Are the data models (memory events) opaque blobs or searchable objects? We must know if search indices are provided or if we must synchronize raw text indexes.
• Key management: If per-device keys are used, how does the service manage public keys and revocations? Does it support key rotation?
• Conflict policy: The API should document whether LWW or CRDT semantics apply, how tombstones are queried, and if clients can fetch version vectors. We need the ability to get all memory events since a given revision.
• Quota and retention: Limits on workspace memory size? Are there guarantees of data durability? (E.g. backup policies.) We should know how long the service retains events if user is offline for long.
• Out-of-order delivery: Can we fetch events out of chronological order (by ID vs time)? Are clocks synced server-side?
• Batching and atomicity: Are batch writes atomic on the server? If we send 10 updates, either all apply or none?
• Identity federation: How are user accounts managed (SSO, tokens)? Does the service integrate with existing auth systems?
• Audit logs: We need to verify that audit trails (who/when) are available for compliance; MemoryEndpoints purges human logs after 7 days, but what about automated traces?

Until these are specified, we assume a generic sync interface with authenticated endpoints for pushing and pulling memory JSON. Any gaps here are “unknowns” requiring collaboration with the MemoryEndpoints team or running a local compatible instance for testing.

14. Annotated Primary-Source Bibliography

• Liquid AI Research Blog – “From Liquid Neural Networks to Liquid Foundation Models” (Liquid AI, Sep 30 2024) – Describes Liquid networks’ claims of adaptability “even after training”. Useful for auditing marketing vs. technical reality.
• LinkedIn Liquid AI Post (Oct 2024) – States that Liquid models “adapt in real time to new data streams”. Example of public claim to be analyzed.
• TinyRustLM Website – Confirms local-first design: “Model bytes come only from local files or your paired companion; prompts stay in this browser.”.
• MultiAgentMemory.com (MATM) Docs – Explains memory layering, sync, and separation of ephemeral vs durable data. Provides a reference architecture (memory lanes, sync protocol, tombstones) for this design.
• Tonksy, “Local, first, forever” (2020) – Blog on local-first software design. Defines principles (“prefers keeping data local”) and sync approaches (file-per-device + CRDT). Guides our multi-device mode design.
• PromptLayer Blog, “How to Design Memory Context for LLMs” (May 2026) – Best practices for structured memory records, TTLs, and retrieval ranking. Informs our memory schema, freshness, provenance, and conflict handling.
• Patrick Brosset, “(Almost) everything about storing data on the web” (Jan 2023) – Survey of web storage (IndexedDB, OPFS, quotas). Key reference for on-device quotas and storage API differences (OPFS vs IndexedDB).
• MDN Web Docs, “Storage quotas and eviction criteria” – Latest data on browser quotas and persistence rules. Provides details (Chrome 60% disk, Firefox 10%/50%, Safari ~60%) and best-effort vs persistent modes.
• Spheron Blog, “Deploy LFM2 Models on GPU Cloud” (2026) – Technical deep dive on LFM2 architecture. Shows that 75% of layers use no KV cache, illustrating how LFM handles hidden state. Used to quantify cache complexity.
• OWASP Session Management Cheat Sheet – Recommends not storing tokens in localStorage, guiding our credential storage approach.
• Other references: (If needed) The above cover our main citations for memory, storage, sync, and security. Each is linked in text by source.