Notices

Saera uses libjulius for voice recognition. It can take in data in two ways: via pulseaudio (what Saera uses by default) or reading from a wav file. So, either it needs some sort of pulseaudio bridge (not sure how that would work), or something to transcode from speex to wav. If there's a simple way to do the latter, I can add dbus signals to do recognition on it.

Edit: Saera does not have any api or dbus interface, yet, mainly because up til now nothing needed to communicate with it. I should probably make some sort of plan for how it will work.

Been killing this day by cracking on various flavours of tokens used in pebble terminology, so while it's all fresh in my head will try to put it here (at least my current understanding of it)

Watch Token - Watch/App specific unique token. Watch/App means it is unique per hardware piece (watch) and software piece (app) - i.e. each app will get own version of the token, but the token will be the same if you install/remove/install app. To put it simple - it's hash of the app UUID and HW Serial.

OAuthToken - this is simple. This is authentication token generated once user logged in. Pebble uses long-living (not expiring) tokens so one may safely stash it and use whenever needed. As an example - Pebble SDK uses it this way. Can be obtained at https://auth.getpebble.com/oauth or https://auth-client.getpebble.com/en_US/ with appropriate pebble:// schema handler (eg. gecko in rockpool)

Account token - this is more tricky and more simple. This is unique user ID. It will be the same whatever number of times you generate new OAuthToken. Really - just pebble account id. Can be obtained from https://auth.getpebble.com/api/v1/me.json with proper OAuthToken.

Timeline Token or User Token - this is a User/App specific unique identifier. It is available via locker API when installed app is registered at the locker (with proper OAuthToken). The token is required to manage Timeline subscriptions. Can be obtained at https://api2.getpebble.com/v2/locker/<AppUUID>

Timeline Token or Sandbox Token - this was the most confusing. It appears to be same as above but for apps which are not yet published to the store, rather just hanging at the dev portal. So the function is the same, usage is the same, principle is the same - just allows one (developer that is) to use timeline without publishing the app to the store (but still publishing at devs.portal). Can be obtained at https://timeline-sync.getpebble.com/v1/tokens/sandbox/<AppUUID>

phew. gone sleeping.

Still itching regarding canned messages.

So basically to confirm - telepathy works and works as I described (leaving sent message in comhistory)

both elements - gabble/jabber/google_2dtalk_6 & dev.null@gmail.com are part of notification, so are available in platform stashed notification for canned reply.
Now just need to compile that alltogether

Found a conflict in documentation. So here's excerpt from JSkit API docs:
while here it states which contradicts a bit with the above. Even though later is not official documentation it sill hints that accountToken is anonymized.
In the end I think the truth is in the middle and it should be safe to make accountToken a hash of the me.json->id + appinfo.json->companyName. That should match both statements more or less. Unique for user per all developer's apps and cannot be used to track users across *developers*.
But to make it really identical across devices we need to use same hash function. Or - again fetch this token from some other - yet unknown - API.

I suspect it should be fetched from somewhere, and that way it will be consistent with other platforms. I'll ask Katharine when the opportunity next arises.

Just found out that the new Pebble 2 watches on the Kickstarter only support Bluetooth LE, so it looks like it won't be possible to use them with the Jolla phone at all. Hopefully Sailfish will support BLE on newer devices and ports at some point though, then we can adapt Rockpool accordingly.

HW seems to be 4.0, it's just sailfish (mer?) which lacks proper BT stack implementation. So we can follow javispedro's suggestion and bring-our-own-stack - as we did with websockets

I got the impression from that thread that LE won't work without a 3.5 or newer kernel, which the Jolla phone will never have. Anyway, I'm hoping that the Jolla C, and any subsequent phones, will support it.

As I understand from this - you can speak to LE peripheral via gatt client api

While I agree with you, maybe it would be possible to implement it first with a cloud based service and letting the user choose to activate it or not and then when a more elegant solution is found, remove the cloud-based part.

I miss the voice service