Implement a Firefox-like awesome bar library

[ncalexan]

This ticket tracks implementing a Firefox-like awesome bar library, in Rust, built on top of Mentat. This is pretty open ended. We need to:

• model places and history in Mentat
• store history URLs and history visit data
• query history efficiently, weighting by frecency-like measures
• produce top sites-like materialized views (similar to Firefox for iOS)
• allow to browse history data, like in the library views in Desktop or the home panels in Firefox for Android

This is really about figuring out what functionality we need to support for our browsers, starting with a drop-in for Firefox for Android.

This isn't really a Mentat issue, but I think it makes sense to experiment very close to Mentat while we learn. There's a bunch of different directions this could go: deeply into the product experience, deeply into the details of a future sync, deeply into the performance profile.

[ncalexan]

@rnewman this is very vague, but do you want to link to/try to sketch a worked example about places and history data? Other comments?

[rnewman]

There's a worked example in the Worked Examples doc, actually!

There are some observations that I think are worth calling out:

• Metadata like titles, descriptions, etc. are properties of pages, not URLs. Places conflates pages and places. A row in moz_places is a denormalized, mutable rollup of some observed metadata about pages retrieved from the place's URL.
• The visit is the core concept in history, not the "place"/"history item".
• A visit relates a set of parameters (container, time, geospatial location, available passwords, etc.) to a resulting page. Visiting the same URL from different countries, in different containers, or even at different times of day can result in different pages and thus different titles.
• Really good retrieval requires awareness of past state (e.g., old titles, related pages) and context (e.g., on which device you took the original action).
• Scoring algorithms, consequently, must accommodate context. The containers folks would, I'm sure, like the awesomebar to have one frecency score per container, and perhaps an aggregate frecency for other situations. But many of the product ideas we've heard in the past few years around contextual suggestions need more: what about 'frecolorecency' scores, where we up-weight pages that you visited frequently, in this context (e.g., while you have Reddit open), at this location (e.g., on your couch), with a structured definition of recency (e.g., at this time on an average Thursday evening)? The ultimate goal of predictive systems like this are to offer you exactly the thing you were looking for next, and f(frequency, recency) is a very rough approximation.
• As we touched on with Save vs Star in Tofino, sometimes when a user hits the bookmark button it's because they want to save the page they're on, and sometimes it's because they want to re-visit the URL they visited. When a user complains about a bookmark not opening the page in the same container that they used when they bookmarked it, it's a barebones definition of "re-visit" that they're complaining about. When they screenshot the page, it's the barebones implementation of saving that they're working around. We can quite seamlessly do better at re-visiting by linking a bookmark to a visited page. Wouldn't it be nice if you could find a bookmark in the awesomebar by matching words in both the original page metadata and the current bookmark metadata?

[rnewman]

Once we start to break out the concept of a page, it becomes natural to model media. Here's a sketch of how we might do that for the kinds of real-world video metadata present on the web.

Vimeo.pdf

[rnewman]

I'd recommend starting with similar capabilities to Fennec, but with these normalizations baked in. That will make it trivial to add containers (which is not trivial in Firefox).

The use of materialized views should cut off any performance issues from the normalization in the data model.

[grigoryk]

In my notes, I was thinking about page as a url meta, but otherwise I've largely converged on what Richard outlined above.

For history, something like this might work:

• A visit to url creates an observation about url_meta. visits are segmented by context.
• context answers questions such as "when", "where" and "how" visit was performed (time, deviceId, containerId, physical location, etc). Expressing this as part of visit itself is probably fine.
• url_meta describes a url as observed at a visit within its context.

page: url visit: page, when, deviceRef, containerRef url_meta: visitRef, title, description, etc

This allows our retrieval to trivially query past states (search through url_meta, associate with a url). This structure also allows for segmenting our frecency scores (thanks to captured context).

It also allows us to trivially generate multiple sets of frecency scores (and thus 'top sites') - for a device, for a time of day, for a day of week, etc.

It's compatible with Fennec's history/visits store, and with the sync15 history record model. When syncing this model against sync15 ...

• ... and uploading, latest visit and url_meta for a page are rolled up into a history record, a count of visits is computed, and a visits json array is generated.
• .. and downloading, an url_meta observation is generated from the current history record rollup (if different from the latest observation). A number of visit entries are generated from the visits json array, as necessary.

The two data models are not fully compatible. sync15 doesn't have concepts such as device, for example. At some point, we're going to have to do something lossy - synthesize information (assume a device), or drop it. E.g. sync.next->sync15, reset sync.next, sync15->sync.next will drop real device info and assume a synthesized defaults. I'm not sure this can be avoided though.

This can be expanded in various ways. E.g.

• As part of a visit to a url, user might generate activity. A visit is within a context and has an associated url_meta, and so we can segment activity by any of those.

visit_media_activity: visitRef, when, stoppedVideoAt visit_reader_activity: visitRef, when, stoppedReadingAt

• This lets us store various meta data about user actions on URLs for a better user experience (a visit to an article in reader mode may prompt user if they want to resume where they left off).
• Better yet, this activity data is within a context, and so it's possible to suggest "start reading article X where you left it off on your Android phone" while visiting article X on desktop.
• This structure also allows us to figure that on Friday evenings, a particular user tends to watch a lot of youtube, which lends itself well to various recommender systems.

[grigoryk]

Started pushing some stuff into https://github.com/grigoryk/fenix_profile