Interface IdentityStatus

Whether a key query about this account was answered, and the answer left this library still unable to say whether the account has an identity.

Read it when accountKeysFetched is false, and only then. Those two together say which of two situations a refusal is in, and the remedies are different:

• Both false: nobody has asked yet. The remedy is the documented one. Drain takeOutgoingRequests, send what it hands back, report each with markRequestSent, call again.
• This true: the query was sent, the server answered, the answer was accepted, and the library still does not know. Calling again will do exactly the same thing. Either the answer did not cover this account, which the Matrix specification prescribes for a user a reachable server does not know, or it carried cross-signing keys for the account that could not be assembled into an identity.

The reachable cause is the account id. A homeserver compares the server name half of a user id against its own case-sensitively, so an address a user typed by hand, with @you:Example.org where the server calls itself example.org, is treated as a remote account and federates to itself. Compare the userId passed to createCryptoMachine against the canonical user_id your /login returned, and stop looping.

Nothing is destroyed while this is true and nothing will be: refusing to create a second identity is the safe direction, and this field exists so that the refusal is not also silent.

Whether a key query naming this account has been sent and answered in this process.

Not persisted. A process that has just reopened a store has asked nothing yet, whatever the process before it did, and the account may have gained an identity in between. false is not a claim that the account has no identity; it is a refusal to guess.

Whether this library holds a public signing identity for the account.

Read only alongside accountKeysFetched. A successful createCrossSigningIdentity sets this true as a side effect, so it is also how a caller sees that its own creation took effect. This named bootstrapCrossSigning, which cannot set it: that call refuses with 'identity_not_known' unless it is already true.

Whether this device holds an identity it created and has not yet seen the homeserver accept.

True from createCrossSigningIdentity until a homeserver's own 'keys_query' answer carries that identity back, and it survives a relaunch, because the identity is on disk and the publication was in memory. A process that is killed, offline, or whose upload times out in that window reopens its store in exactly this state.

The remedy is createCrossSigningIdentity again, deliberately. It hands back the same publication that was lost, and bootstrapCrossSigning refuses with 'identity_not_known' while this is true.

That was the other way round for one release and it was wrong. Measured on two homeservers: a device in this state, answered honestly that the account has no identity, published over an identity a second device of the account had legitimately created in the gap before that answer was reported. The launch-time call did it. From inside a device, an identity it holds and has never seen a homeserver accept is indistinguishable from one the account has since replaced, and no answer settles that, because an answer describes the instant the server computed it and nothing later. What you know and this library does not is whether this account is still in sign-up, which is why finishing is a decision.

Read it because this is the one state where identityKnown is true and the account still has no identity. A product that shows "encryption is set up" on identityKnown alone is wrong here.

Whether this device holds the account's complete private signing keys, and can therefore sign with the identity rather than only recognise it.

True does not mean the server agrees. Until accountKeysFetched is also true, these keys may belong to an identity the account has since replaced: a restored backup holds a complete set that is simply out of date. So this field is only trustworthy alongside that one.