Open Bug 1302797 Opened 8 years ago Updated 1 year ago

Device Origin of Sync Data


(Firefox :: Sync, defect, P3)





(Reporter: adavis, Unassigned)


(Depends on 2 open bugs, Blocks 2 open bugs, )


(Whiteboard: [sync-activity-stream])

Activity Stream team would like to know from which device and type of device data was Synced so that they can display the proper visual cues in the Activity Stream. 

This would also enable them to attribute more importance to one type of device or another or to optimize Activity Stream content differently on desktop vs on mobile.
This is a relatively large metabug.

Main issues:

* How do we identify a device? We could use the Sync client ID, but that fades away. We could use the device registration system, but I don't know how stable that identifier is, either.

* What happens for devices that no longer exist? I created the bookmarks in my account on a bunch of devices that no longer exist. Do we need to keep some kind of device metadata around forever so that new devices can find out the names of old devices that are referenced from old data?

* The Sync object formats don't include this data, and neither do the stores on each platform.

That means at least six pieces of work ((storage + sync) x 3) to make this happen for each data type, plus one slightly thorny device metadata piece on each platform. The storage changes will have knock-on work: Places bookmark and Refresh Firefox being two notable places.

For some formats (bookmarks, for example), adding a creator to the record format itself is straightforward and backward-compatible, assuming it's OK for it to occasionally disappear.

For history, this gets a little challenging.

It mostly only makes sense for the device to be an annotation on a *visit*, not on the URL itself (or an ever-growing set of devices per URL, but that has its own problems), so we're basically where we were when planning (and being unable to execute) Sync 2.0.

Interestingly, Tanvi and folks are hitting the same problem in Bug 1283320/Bug 1288858: they want to annotate visits with container (Work, Personal, …), and that needs to be stored and synced somehow.

If you really want this, then it might be time for a proper rework of history sync, but be aware that making this work at all, let alone well, is a lot of work.

More context: Bug 1302797, Bug 734930, Bug 717136.
Depends on: 717136
Would it make sense to approach "originating device type" problem separately from "originating device"?

If I understand A.S. use cases correctly, having a device type ("desktop", "android phone", "android tablet", "iphone", "ipad"...) available for any given bookmark/history visit is already a decent win. Having this data available should support some amount of UX planned for A.S., I think? You will be able to filter/sort/prioritize based on originating types, at the very least, as well as indicate them to a user. If a user has only a few connected devices, and no more than one per type, that's probably enough.

Grouping different origins over time by device type might or might not be desirable from the UX/product point of view, I'm not sure.

If we don't worry about tying our data formats to originating device, life seems to get easier. We don't need to worry about maintaining device metadata, and any device lifecycle events. Devices appear, re-appear, they're all just one of a handful of "types". You have a continuation of sorts after switching from one phone to another. We still have to do (storage+sync)x3, albeit the work seems somewhat simpler. I think this approach doesn't corner us either, and provides a path forward if/when we do want to identify a particular device itself, and not just its type.

Some questions to ask/answer about this:
- is this approach going to be sufficient to support A.S. for "long enough" to justify investment of time?
- is this approach significantly simpler than going all the way and tracking originating device across the Sync world? Or should we just "bite the bullet", so to speak?
(In reply to :Grisha Kruglov from comment #2)

> If we don't worry about tying our data formats to originating device, life
> seems to get easier. We don't need to worry about maintaining device
> metadata, and any device lifecycle events. Devices appear, re-appear,
> they're all just one of a handful of "types".

Yup, and you could do the same thing with device names, if you were willing to pay the cost in bytes.

Issues with that approach would be:

* Are types an open set or a closed set? (Do I need to include the string "desktop" each time, or can I use '3'?)
* What if a device sees a type it doesn't know about? It'll happen. Localization is a concern.
* As you note, does this suffice for product needs? You could no longer limit history down to things you did on your desktop, because your Surface's history is mixed in (they're both desktop Firefox). You can no longer clear the history for this device and have it sync correctly. Etc.

One could potentially split the difference by defining generic default devices with no name: tablet, desktop, unknown, etc. That way we're tracking individual devices in the data model, but we're only using that capability in a simpler fashion.
Assignee: nobody → adavis
Priority: -- → P3
Flags: needinfo?(adavis)
Summary: Add Device Type Origin to Sync Data → Device Origin to Sync Data
Flags: needinfo?(adavis)
Summary: Device Origin to Sync Data → Device Origin of Sync Data
I just want to confirm if you needed device type, device name or both?
Are bookmarks the priority here or does this apply to history too?
Flags: needinfo?(nchapman)
Here's a little more information on how we're using these labels in Activity Stream...

Throughout Activity Stream, and specifically on new tab, we're showing users highlights from their history. When we do this we are trying to give us much context as possible so that they clearly understand what it is we're showing them and why. This means highlighted items can be labeled as: "Visited", "Bookmarked", "Shared", etc.

A really cool side effect of this is that you often see content from your other devices. The downside is that they're missing a key bit of context about the originating device. So you see "Visited" rather than "Visited on Nick's iPhone 7". This is important because people might otherwise be confused where it came from or, maybe more importantly, miss out on the fact that they're getting some really cool value from Sync.

So :adavis, to answer your question specifically: we'd like to have this information for history and bookmarks. We're using it primarily as a visual label, although we'd also like to be able to filter on this in the future e.g. "show me everything from Nick's iPhone 7". I believe the device type would also be very useful for us to have so that we could weight the results that we show you based on the device type. For example: desktop things on desktop; mobile things on mobile. We don't have this in our roadmap currently but do imagine that it would be very useful.
Flags: needinfo?(nchapman)
Depends on: 1151336
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
Blocks: 1516329
Blocks: 1531224

The bug assignee didn't login in Bugzilla in the last 7 months.
:markh, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: alex → nobody
Flags: needinfo?(markh)
Flags: needinfo?(markh)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.