If we're not ready to sync the state when the keyserver asks us to, do we make sure to respond to it once we're ready? Or do we have to wait for the keyserver to initiate again?

For this one and for usersStateSyncSpec, it seems like you're using canSyncState to block user state sync with non-authoritative keyservers. But the non-authoritative keyserver will still attempt to initiate the sync for that data by sending it inside serverRequest.hashesToCheck, right? Is there a task that tracks updating the keyserver code so that non-authoritative keyserver stop trying to sync these fields with clients?

Do we not pre-compute hashes for entry sync?

The way this function is named, it feels like it's commenting on whether this type of state can be synced, rather than whether we're ready to perform a sync.

Maybe you can add a comment above this explaining what this function really does, and how it's used? (In some cases to block non-authoritative keyservers, and in other cases to block sending state until our hashes are ready.)

Do we not pre-compute hashes for user sync?

We're waiting for the keyserver to try again. The preparation of integrity store hashes could take up to 10 minutes, so the keyserver can try multiple times during that period and it shouldn't make the experience significantly worse by waiting another up to 3 minutes of inactivity (our state sync frequency). We could consider initiating the state sync from the client side when the hashes are ready, but not sure if it is worth it.

But the non-authoritative keyserver will still attempt to initiate the sync for that data by sending it inside serverRequest.hashesToCheck, right?

Yes, that's correct.

Is there a task that tracks updating the keyserver code so that non-authoritative keyserver stop trying to sync these fields with clients?

We don't have a dedicated task, because we believed that the whole goal of syncing user infos without a keyserver will require this change. But I guess we can consider making this simple change as a part of e.g. https://linear.app/comm/issue/ENG-7741/userstore-syncing-in-multi-keyserver-environment and its subtask https://linear.app/comm/issue/ENG-7798/stop-sending-userinfos-from-non-auth-keyservers.

Yes, we compute all the hashes from scratch on every request. The performance was investigated in https://linear.app/comm/issue/ENG-4883/improve-performance-of-id-conversion and the improvement was implemented in https://linear.app/comm/issue/ENG-4959/integritystore-compute-thread-hashes-greedily#comment-15cf1147. I don't see a comment summarising how long the computation takes for the entry store, but I somehow remember that it was orders of magnitude faster than threads (because entries are really simple and threads have multiple levels of props with IDs to convert).

The way this function is named, it feels like it's commenting on whether this type of state can be synced, rather than whether we're ready to perform a sync.

Yes, for one case it tells if we're ready, and for two other cases if we can sync at all. I'll add a comment explaining this.

Yes, we're pre-computing only the threads' hashes.