Notices

Depends on what actual purpose it has. Can apps do something useful with the actual store GUID? E.g., query the pebble store about the watch type? If not, a persistent generated GUID, would suffice. For added privacy, a GUID per app could be generated and used.

I read in the docs that it's unique for every app anyway so you can't be tracked between apps.

Are we sure that apps aren't working because of this?

If the account token is useless beyond recognizing a user, I'd guess it shouldn't matter. The Pebble doc doesn't suggest otherwise. I.e., implementing the account system just for this seems pointless.

There are two ways we can implement it - in the GUI only (make a login handhsake, obtain token, stream it down straight to the daemon via DBus - ugly and silica only.
Or we can do it right way - actually extend appstoreclient to do the login, add simple credentials entry dialog, add accountToken attribute to the pebble object, make it sync downwards via dbus to store in the libpebble/jskit. That way rokwork guys would just need to add their version of the simple credentials dialog. Worth checking with them though if they're planning to add this feature, it's quite an obvious miss.

As per docs accountToken _may_ be used by apps to store user-specific data. It doesn't say it's an OAuth token which could be used by 3d parties to auth user against the store.

What it obviously carries back is user's store interaction: eg. which apps are marked by user as being liked. eg below is what I captured from my android client:
This data fetch doesn't require authentication - any request to the URL with valid accessToken returns my appstore details (I've tried private window fetching and curl). I'm not sure though what would be accountToken - accessToken, id or uid of the user.

To nail down app problem to the wrong usage of the accountToken we need to dump js code and see whether it attempts using it. But I still am thinking we should rather return empty string, since token is returned only when logged in to the store. Proper app then should suggest user to log into the store if it requires certain interaction with it using the token.

The question is really whether they are generated/stored by the appstore (and hence could be valid identifiers when interacting with the store) or they are really just unique per app/user so that if someone uses it - it will persist across phones/watches.

The docs are saying
so it's not per app, it's really per user.

Nope. Just a guess.

oh wait, developer's watchapps, so it seems it's developer specific, has nothing to do with user. Red herring then.

Ok guys, so we need certain extensive testing of the gecko build to prove it worth merging - i.e. that despite fixed known bugs we didn't introduce some other.
Implemented functionality is similar to that of webkit - only itemSelector is implemented.

@abranson - would you prefer me posting it in the own openrepo or you can build and put in your with some tag (eg. gecko-test)?

Whichever is easier - if it's in yours then you can easily make new builds. A tag is probably essential anyway to avoid accidental upgradings.

I should do the same with the qtwebsockets branch. Is it easy to rename packages/rpms like that? How many places do you have to change it?

Oh, I forgot about warehouse, was thinking people are just pulling it down manually in that case simple file renaming would suffice.
I don't know how warehouse is working - whether it uses metadata from inside RPM (parsing) or from the file name. Let me look onto the warehouse code to understand what does it consider as an update and what as a separate side packet.
In general i think worth creating second repo - rockpool-beta with all these packages.