| Memories.sys.mjs |
This module defines functions to generate, filter, and merge memories.
The primary method is `runSessionMemoryPipeline`, which orchestrates the
pipeline over a batch of unified session bundles (see `buildSessions`):
1. Generates initial memories, one LLM call per chunk of <=MAX_SESSIONS_PER_BATCH sessions
2. Filters out low-quality (generic/ephemeral) AND sensitive memories (one global call)
3. Returns the final memory objects plus the watermark the caller should advance to
`runSessionMemoryPipeline` requires:
1. `conversation`: a Conversation instance, reused across every LLM call (each step clears messages before setSystemMessage / addUserMessage)
2. `sessions`: gate-filtered session bundles from `buildSessions`
|
32323 |
- |
| MemoriesChatSource.sys.mjs |
This module handles the user message extraction from chat store
|
5195 |
- |
| MemoriesConstants.sys.mjs |
Memory types
|
7990 |
- |
| MemoriesHistorySource.sys.mjs |
This module handles the visit extraction data from browsing history
|
37234 |
- |
| MemoriesManager.sys.mjs |
Keeps at most `maxSessions` sessions, selecting the most recent ones.
Selection is newest-first so that a backlog contributes its most recent
activity rather than an arbitrary prefix. The result is returned in
chronological order because the pipeline batches sessions in array order and
advances `processedThroughMs` monotonically as batches complete, so an
ascending run keeps that watermark contiguous with the work actually done.
@param {Array<object>} sessions Gated session bundles from `buildSessions`
@param {number} maxSessions Hard cap on sessions handed to the pipeline
@returns {Array<object>}
At most `maxSessions` sessions, ascending by `session_end_ms`.
|
30734 |
- |
| MemoriesSchedulers.sys.mjs |
Unified scheduler for memory generation from browsing AND chat activity.
A single 2-minute interval evaluates one combined trigger: run the unified
session pipeline ({@link MemoriesManager.generateMemoriesFromSessions}) when
the cooldown has elapsed and EITHER enough new pages have been visited
(browsing, if enabled) OR enough new chat messages have accumulated
(conversation, if enabled). Each trigger is gated by its enablement pref, so
a chat-only or browsing-only user fires only on the relevant signal.
The cooldown is keyed off when generation last ran (`last_generation_run_ts`),
which is persisted, so restarting the browser inside the cooldown window cannot
buy an extra round of LLM calls.
Memory maintenance ({@link MemoriesManager.runMemoryMaintenance}) runs on the
same tick but its own clock, so ageing and decay deletion keep their cadence
even when nothing new is worth generating from.
Public entry points are the static {@link maybeRunAndSchedule} and
{@link stop}; they manage a single instance.
|
15559 |
- |
| MemoriesSessionGate.sys.mjs |
Heuristic gate for session bundles produced by `buildSessions`.
`runHeuristicGate(session)` returns a binary decision (`KEEP` or `SKIP`)
so the orchestrator can drop sessions that are structurally guaranteed
to have no extractable content.
This gate intentionally only rejects sessions where structure alone
proves there is nothing to extract (no queries, no usable titles, no
meaningful chat). Anything with even a single query or a meaningful
title is handed to the downstream LLM step, which is far better at
judging whether the content is worth remembering.
Cross-modal policy is permissive: for a session that has both browse
activity and chat messages, the gate keeps the session if either
modality individually passes its checks. The intuition is that
cross-modal sessions are by construction more contextual than
single-modal, so a substantive chat carries an otherwise-trivial browse
session and vice versa.
|
4227 |
- |
| MemoriesSessions.sys.mjs |
Cross-source sessionization for memory generation.
`buildSessions` merges history visits, searches, and chat messages into a
single timestamped event stream and groups them into sessions by gap and
maximum session length. A downstream LLM step processes one session at a
time, so the model sees browsing context and chat context that occurred
together in time as one bundle.
Source IDs are tracked separately by sources (`history_source_ids` for
`url_hash` values, `conversation_source_ids` for `convId` values) so a
revocation hook can match the right kind of ID when the user deletes
history or a conversation.
This function is pure: it does not read prefs. Callers gate via
`MemoriesManager.shouldEnableMemoriesFromSchedulers` and pass `[]` for
any disabled source:
- both enabled → cross-source sessions
- history only → history-only sessions
- chat only → chat-only sessions, time-bucketed by message timestamp
- neither → caller short-circuits before calling
|
6253 |
- |
| moz.build |
|
595 |
- |
| SensitiveInfoDetector.sys.mjs |
Detects and filters sensitive personal information from text
Detects:
- Government IDs (SSN, SIN)
- Financual information (credit cards, bank accounts, routing numbers)
- Contact information (email, phone number)
- Network Identifiers (IP addresses, MAC addresses)
- Physical addresses
|
11332 |
- |