However, the demo didn't return a steem:// URI that would be opened in the desktop app, I guess it's not possible to detect if a desktop app is installed, is it?
AFAIK there isn't any proper way to detect if user support a custom URI scheme, there is some tricks to do it but from what i've tested it was not working on all scenarios so we've not been implemented it.
However when you are on the beta website for login or sign a transaction there is on the top of the page a button to open that page on the desktop app.
If the release is one month away, I guess it would probably best to launch the @travelfeed beta with v2 and only deploy v3 in a month, or is v3 safe to be used in production already?
You should be using the latest version of the SDK so your app will be compatible with the Chrome extensions. The last version of the SDK will still redirect your users to the main domain with the v2 for a month, you should not redirect your users to the v3 now, this is something we will do us when the beta end, this will not require changes on your side.
Excellent! I have migrated most functions already, love the new error messages btw! But I was wondering about one thing: With v2 and
getLoginURL, the steemconnect oauth token is sent to our API once upon login where it is then verified with theme()call (if valid, our API returns our own JWT, signing of Steem transactions is always done client-side only). The JWT received when logging in with Keychain or the Steemconnect returns a signed message instead, so I have to change our API implementation - is there any tool in the Steemconnect module to verify that the signature is valid and belongs to the correct Steem account or would I have to write my own implementation, e.g. by obtaining the account's public keys with dSteem? Is the Universal log in safe to be used in production already (our beta goes public next week) or should we usegetLoginURLuntil the release?