summaryrefslogtreecommitdiffstats
path: root/toolkit/components/contentrelevancy/docs/index.md
blob: e7f68024958994cc8e6ea5bab324a88ae6d9972c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
# Content Relevancy

This is the home for the project: Interest-based Content Relevance Ranking & Personalization for Firefox,
a client-based privacy preserving approach to enhancing content experience of Firefox.

```{toctree}
:titlesonly:
:maxdepth: 1
:glob:

telemetry.md
```

## Overview

The following diagram illustrates the system overview of the component.
The system consists of three main parts: the relevancy manager, the relevancy store,
and the internal & external data sources.
The cross-platform component [`relevancy`][relevancy-component] serves as the backbone
that is responsible for interest classification, persistence, and ranking.

```{mermaid}
graph TB
subgraph Firefox
  direction LR
  subgraph rmgr[Relevancy Manager]
    subgraph rcmp[Rust Component]
      classify[Perform Interest Classification]
      manage[Manage]
      query[Query & Rank]
    end
    iic[Initiate Interest Classification]
    rtuc[Respond to User Commands]
    irt[Input Retriever]
  end

  subgraph places[Places]
    direction TB
    tfv[(Top Frecent Visits)]
    mrv[(Most Recent Visits)]
    others[(Other Inputs)]
  end

  subgraph rstore[Relevancy Store]
    direction TB
    iui[Inferred User Interests]
    icm[Ingested Classifier Metadata]
  end
end

subgraph settings[Remote Settings]
  rs[("content-relevancy")]
end

iic --> |call| classify
classify --> |write| rstore
query --> |"query (read-only)"| rstore
manage --> |update| rstore
places --> |input| irt --> iic
rs --- |fetch<br/> classification<br/> data| classify
rtuc --> |call| manage
```

### Relevancy Manager

The relevancy manager manages the following tasks for the relevancy component:
- Start a browser update timer to periodically perform interest classifications
- Listen and respond to user commands such as enable / disable the component,
  update / reset the relevancy store upon Places changes, etc.
- Nimbus integration
- Telemetry

The interest classification is fulfilled by the `relevancy` Rust component.
The `relevancy` component downloads & ingests interest data (e.g. "small classifiers")
from Remote Settings and then applies those classifiers to the chosen inputs.
Classification results are persisted in the relevancy store for future uses.

### Relevancy Store

The relevancy store, an SQLite database, serves as the storage for both
the user interests and the ingested classifier metadata. It's managed by the
`relevancy` Rust component, which provides consumers (e.g. the relevancy manager)
with a series of APIs for ingestion, querying, ranking, and updating.

### Data Sources

Interest classification relies on various internal & external data sources to function.
- Interest classifiers and metadata are prepared offline and served through
  Remote Settings. The download and ingestion are handled by the Rust component
- Classification inputs (e.g. top frecent visits and most recent visits) are retrieved
  from Places. An input utility module is provided to facilitate the input retrieval

## Working on the Code

### Component Structure

- `ContentRelevancyManager.sys.mjs` implements the relevancy manager. A singleton
  relevancy manager is initialized as a background task in `BrowserGlue.sys.mjs`
- Modules defined in `private` should be treated as internal artifacts for the
  component and should not be consumed by other browser components.
  `InputUtils.sys.mjs` defines several utility functions for input retrieval

### Telemetry

Please reference the [telemetry](./telemetry.md) section.

### Testing

Since the component is relatively small and does not have any user facing interfaces,
XPCShell tests are recommended for general testing. Mochitests can be used if you're
testing functionalities that would require a more complete browser environment. Only
the Nimbus tests are written as Mochitests at the moment.

Notes:
- The component requires a browser profile for both Places and the relevancy store,
  `do_get_profile()` is called in `head.js`
- Most XPCShell tests are skipped for Android as some test dependencies (`PlacesTestUtils`)
  are not available on Android

[relevancy-component]: https://github.com/mozilla/application-services/tree/main/components/relevancy