address feedback

making ashoat blocking since we're discussing when to do this deployment on Comm

In D12619#357437, @ashoat wrote:

What is the URL that is printed? Wondering if it's https or some sort of deep link

https://linear.app/comm/issue/ENG-8813/remove-recursive-logic-from-tunnelbroker-websocket-code-in-keyserver

staging is fixed now -- all items in the identity-users table with a username attribute now also have a usernameLower attribute

this solution is pretty neat

In D12704#360102, @will wrote:

Directly synced with Varun. Looks good. Before landing make sure to remove need for unnecessary partition key check and add a comment for changes starting from line 340 in services/identity/src/database.rs

some small fixes

fix onOpen

think i broke something in the latest revision

In D12546#355540, @ginsu wrote:

Looks good, but is there a follow up task/diff to address the janky ui?

address feedback

In D12549#355466, @inka wrote:

Can any other errors be thrown by signer.signMessage? Should we still throw them if so?

In D12547#355413, @bartek wrote:

Why did we introduce it initially? 🤨

In D12545#355460, @inka wrote:

Should the secondary title say "Wallet Connected" on error?

In D12501#355516, @marcin wrote:

I have concern that marking prekeys as published after uploading to identity comes with the risk of delaying next prekey rotation in case app crashes after uploading but before marking as published. I am wondering if letting the prekeys to be in circulation for longer than expected is a security concern. Accepting to unblock identity release. If my reasoning is correct we can just change the order later.

It might be strange if a user sees that registration fails, but after attempting sees that the user already exists because registration worked but marking keys as published failed.

In D12546#355463, @inka wrote:

Why would a user be claiming a username from login screen? Isn't claiming username registration?

i'll try to shorten the message so it fits on one line. looks a little janky rn

In D12501#355136, @kamil wrote:

What if a user is successfully registered/logged in to Identity but for some reason markPrekeysAsPublished fails? Wondering, if shouldn't catch and ignore errors here and make sure later PrekeysHandler re-uploads the same keys and marks as published (since marking as published is used only for rotation).

I think existing logic should handle this because it uploads not published keys and marks as published (not sure about native but logic should match).

It might be strange if a user sees that registration fails, but after attempting sees that the user already exists because registration worked but marking keys as published failed.

Curious for @marcin's perspective.

Accepting to unblock and I don't have a strong opinion on which approach is better, only pointing out something worth considering.