User:DBrant (WMF)/Gather on Android

The Android team will soon start work on implementing basic Gather functionality in the app, starting with the ability to synchronize our current "Saved Pages" list to the user's account. We've recently realized, however, that Gather is only deployed on enwiki (but they're trying to remove it) and hewiki, and that Gather lists don't support inter-wiki items. By contrast, the Saved Pages list in the app is entirely wiki-agnostic (which is why it was easy for us to forget that Gather is a per-wiki extension).

Ideal scenario

The ideal case would be if the user's collections are independent of which wiki they're browsing. Collections may be composed of any items from any wiki, and the backend underpinnings are entirely transparent to the user.

Asks from the API

It won't be the end of the world if we have to feature-flag the whole thing for en- and hewiki, but I'd like to explore a few options for augmenting the existing API to support what we hope to accomplish. I've broken it down into a few "levels" of involvement. I'd like to solicit some comments on the technical feasibility (and advisability) of each one:

Status quo (no changes to existing API)

The app would automatically create a private list called "Saved pages" for the current user, and continue to refer to this list by name for synchronizing to/from the device.
Con: If the user renames or deletes the list in the mobile web interface, the app will blindly recreate it based on its current state.
Con: We'll need to explicitly tell users that the feature is only available on enwiki (i.e. only articles from enwiki will be synced).
My own preference is for this to be a last resort.

Add a "role id" to lists

Gergő was suggesting that we could add a "role" flag to distinguish different types of lists. This would mean:

We define a "role" of 1 to mean "saved pages in the app", and leave the default role as 0.
- No. Use strings as the interface, not magic numbers. Anomie (talk) 21:03, 19 January 2016 (UTC)
The app would automatically create a private list with a role ID of 1 (of which only one instance would be allowed), and continue to refer to this list by role ID for subsequent syncs.
Pro: No longer dependent on the exact title of the list.
Pro: Extensible to other possible roles in the future.
Con: the rest of cons in the first option still apply.

Add support for inter-wiki items

Add something like an "iw" field to each item, and populate it with the target wiki prefix.
Until mobile web supports interwiki items, they can hide any items that don't point to the eigenwiki (trademark).
Indeed, mobile web can hide lists whose role ID != 0.

Add revision ID to lists

To truly be able to synchronize a list, it would need to carry some sort of revision ID. Otherwise, a client has no way of knowing whose version of the list is more recent.

A bold proposal

If we enable lists to support interwiki items, then all lists can potentially live on enwiki, regardless of which wiki the user is browsing in the app.

Implementation notes

Examples

Given that the user is logged in...

Display a list of all their collections (including watchlist)

https://en.wikipedia.org/w/api.php?action=query&list=lists&lstprop=label%7Cdescription%7Cpublic%7Cimage%7Ccount

Display a list of pages for a given collection

https://en.wikipedia.org/w/api.php?action=query&prop=pageimages&piprop=thumbnail&pithumbsize=120&pilimit=50&generator=listpages&glspid=0&glsplimit=50&lspsort=namespace
// TODO: lspsort=namespace is broken for formatversion=2?