Very much comment here on this subject, unfortunately very much of it references out of date or incorrect sources or even misses the point entirely possibly due to the posters not understanding the underlying concepts.

I partly blame myself for the first part as I am a contributor to SQRL and have been lax in keeping my part of the documentation current as things progress, Steve has had similar problems.

As to the second, SQRL is not a 2FA succinctly it is a:-

Single factor (1FA), 2-party, Zero knowledge, pseudonymous proof of identity.

The use of QR-Codes was an early feature but is mostly relegated in favour of same device authentication, with I hope a brand new feature (Client Provided Session) that will effectively detect & then eject a MITM attempting a session hijack from the connection.

The nature of the 2-party relationship is such that no site can determine without the collusion of the user themselves if that user has an SQRL authenticated account on any other site, hence pseudonymous.

Reference implementations require that the Master Identity file is stored in an encrypted form and only decrypted at point of use by a key derived from something only the valid user can provide (passphrase, biometric), thus user to identity is confirmed.

Loss of an unprotected Master Identity File exposing the Master Key is not fatal because although the master key will provide the means of access it does not allow an attacker to update site specific keys. There is effectively a Super-Master Key that is never exposed but protected with an exported system generated encryption key that is held offline for such an eventuality.

Finally because this is a protocol cooked up by a group of enthusiasts we always welcome constructive input and entities willing to offer support in getting SQRL more widely understood.