what's not working?

In D10403#301009, @varun wrote:

what's not working?

I've fetched the token on native using D10327 which gave me

{"accessToken": "qYpfzfksj4rDWKSPwewFGH0v5vXAyf5T9pc4CSwLMl7QjRh0l52dvTkinbQohrjQStJAedHXFf9ZtxyZPUqZlZdxKGFdgW7No4yh62o4ts8iXEWzd5RxHL9I7MJbKWQZu0DxCrEVkcNbcZ1tG90wjowNb1K9EVxsNbcqvANJD1gDnc7eLXgfiUTHnAnHVGdnF987KNGDQeAOCizqaFJfJkUXNlBhutECAjnZhEdVJIekC94fmnvD6nwDzRVUud4rZMlAWcC2zQn1uTRXxJ5pRlH9708Z474TVzuR25WFzwzfagcJoDjJPBYzHDpHH9hZFbPJcBzNQ0BwFtS8zWagjeyvyMeQ06TXxipFZmKsna7juGW9XIhMKtoygTxdzCXJsoHkruvt7ZbEpOY3hIWcvZGWRNtbwQVvmOhYDfbJOcNd4uEtJPcfG1uhgIbIFXKs02Nm4sd6RshbjswlxWQm4m98gXtlBgeIr8KwGxtxLS1R3MdLHmJ6ChMZMNPCuR2f", "deviceID": "59WaR60E9uVlC/5KUuFTuq6XQfTTwgbh1BCQDct7GeQ", "userID": "4D33A7F6-0DB7-4652-BAC3-1B086C2E5D66"}

then tried to use that on the web to auth and fetch keys for Ashoat's keyserver. The auth seems to be successful, but fetching fails with a quite useless error

On Identity service, there's a log corresponding to the call

2023-12-21T10:29:34.333161Z ERROR identity::client_service: Encountered an unexpected error: MissingItem

but it also doesn't tell too much.

Debugged it a bit and figured out what's going on. It seems like the Identity service doesn't recognize ashoatKeyserverID to be an ID of Ashoat's user. Instead, in identity-users table there's an entry for the user whose value is some UUID (different for staging and prod). After using the ID from the table, this code works correctly.

But it opens up a question of how to handle the keyserver - when interacting with the Identity service it is no longer correct to use ashoatKeyserverID as an ID. Ultimately, we won't need a hardcoded ID, but for some time it will be causing issues.

when interacting with the Identity service it is no longer correct to use ashoatKeyserverID as an ID

Identity service should be using the userIDs we already have set on the keyserver. We made this decision back in August on this thread.

I'm worried that this is another case of something not being tracked that is critical for identity service launch...

@varun and @bartek, some questions:

1. What this supposed to be already solved, or is it still in progress?
2. If it's still in progress, what task is it tracked in?
3. If it's supposed to already be solved, can you create a new task to investigate why @tomek is seeing this behavior?

In D10403#301561, @ashoat wrote:

when interacting with the Identity service it is no longer correct to use ashoatKeyserverID as an ID

Identity service should be using the userIDs we already have set on the keyserver. We made this decision back in August on this thread.

I'm worried that this is another case of something not being tracked that is critical for identity service launch...

@varun and @bartek, some questions:

1. What this supposed to be already solved, or is it still in progress?
2. If it's still in progress, what task is it tracked in?
3. If it's supposed to already be solved, can you create a new task to investigate why @tomek is seeing this behavior?

This discussion happened long before I touched Identity Service at all, but now I briefly looked at the code/RPCs and the RegisterReservedUserStart RPC should have the userID encrypted inside the "keyserver message+signature" payload (link to the code).

The problem is that keyserver's registerOrLogin() JS function doesn't call the "reserved username" RPC but rather a normal registration, so the keyserver is registered as a new user.

Edit: created ENG-6277