I just realized my first reply did very little to answer your questions, so I'll take a look at them one by one here:
> Are there any websites or services actually using this?
To my knowledge, there are not many (if any, besides the SQRL forums) working, live implementations out there. I played around with it and got it working on a couple of hobby projects over a weekend and it showed a lot of promise.
> The problem with the solution chosen here is that this requires yet another app for authentication and yet another account for synchronisation of credentials. If this were to be built into browsers, it might replace traditional passwords in time.
This is very true, but I believe SQRL as an open protocol will have long tail legs over time.
> How does SQRL work when it comes to apps? Does the Android app natively support other applications calling it to authenticate? What about authenticating devices that can't run the client application (smart TVs, for example), can they still access the accounts authenticated by SQRL?
At its core, SQRL is essentially a Challenge/Response mechanism. It would be possible for a device connected to a TV present a QR Code and have its session be authenticated by a device using the out of band HTTP request from the SQRL client scanning the QR Code (there are problems with this, like forwarding the QR code via a MITM attack to gain an authenticated session, however, the attacker only has a single logged in session instead of having access to a password that now needs to be changed, and any problems related to this MITM attack would also affect other user credentials like the email and password).
> Right now, SQRL seems to be competing with Webauthn, which has been built into browsers already, but does so through an external daemon running alongside the browser. I'm not optimistic about its chances here, to be honest.
Short term, I agree with this. However, long term I think WebAuthN is going to suffer from other problems which do not affect SQRL (user adoption of 2FA keys and user inconvenience in managing those 2FA items) SQRL provides some really nifty ways to transfer an identity safely to a host of other devices as well as rekeying an identity with the rescue code in the event an identity is compromised. It also doesn't require the management of those devices on any third party site.
> Are there any websites or services actually using this?
To my knowledge, there are not many (if any, besides the SQRL forums) working, live implementations out there. I played around with it and got it working on a couple of hobby projects over a weekend and it showed a lot of promise.
> The problem with the solution chosen here is that this requires yet another app for authentication and yet another account for synchronisation of credentials. If this were to be built into browsers, it might replace traditional passwords in time.
This is very true, but I believe SQRL as an open protocol will have long tail legs over time.
> How does SQRL work when it comes to apps? Does the Android app natively support other applications calling it to authenticate? What about authenticating devices that can't run the client application (smart TVs, for example), can they still access the accounts authenticated by SQRL?
At its core, SQRL is essentially a Challenge/Response mechanism. It would be possible for a device connected to a TV present a QR Code and have its session be authenticated by a device using the out of band HTTP request from the SQRL client scanning the QR Code (there are problems with this, like forwarding the QR code via a MITM attack to gain an authenticated session, however, the attacker only has a single logged in session instead of having access to a password that now needs to be changed, and any problems related to this MITM attack would also affect other user credentials like the email and password).
> Right now, SQRL seems to be competing with Webauthn, which has been built into browsers already, but does so through an external daemon running alongside the browser. I'm not optimistic about its chances here, to be honest.
Short term, I agree with this. However, long term I think WebAuthN is going to suffer from other problems which do not affect SQRL (user adoption of 2FA keys and user inconvenience in managing those 2FA items) SQRL provides some really nifty ways to transfer an identity safely to a host of other devices as well as rekeying an identity with the rescue code in the event an identity is compromised. It also doesn't require the management of those devices on any third party site.