Saw this on the doc:

1. I don't think SubmitButton is a great name for this. It's used for actions other than submitting.
2. I don't think it makes sense to move this component out by itself. It's tightly coupled to the other visual components in the native/account/registration folder, and now it's pretty weird that some of them are in that folder and some are elsewhere.

It looks like @marcin's investigation has shown that ChatGPT is wrong, and he is pursuing a different theory that perhaps Android is punishing us for sending non-visual notifs (rescind and badge-only) with high priority. I think this is a good direction to explore.

Oh wait, there are updates on Linear I missed. Let me read them first, sorry for missing that

I might be missing something, but doesn't the notif have to include android: { priority: 'high' } }? This is what Chat GPT seemed to indicate (transcript linked on Linear)

Only retry if we get olm_session_creation_failure. Tested with keyserver patch that returns that error (saw two attempts in logs), and keyserver patch that returns different error (saw only one attempt in logs)

Rework following updates in D11845 to avoid showing two alerts

Addressed feedback. Added an alert when deleting the identity account fails

I spoke to @inka in our 1:1 today and it appears that some information was lost in communication between @inka and @kamil. In consultation with @inka, we determined that the order should be the following:

This diff is very confusing. It's doing way too many things at once, and the test plan is insufficient to cover all of these code that's being modified.

Hmm. Thanks for catching this error case and fixing up the diff, but I'm not sure I understand the explanation.

What do you mean by that? After you go with https://www.notion.so/commapp/Running-two-keyservers-0d373941f2494d949846da02752b91db instructions, you can change the client's flags however you want - at least that's what I'm doing and it works reliably. So my keyserver is always configured in a multi-keyserver manner.

I can accept this since I reviewed it closely already, but feel free to set @inka as blocking if you'd like their review as well

Worth reading my comment in the preceding diff before proceeding here. It looks like this diff only moves around calls to mark prekeys as published, which I think should actually stay where they are (after publishing to identity). Might be best to abandon this diff, but let me know if I'm missing something

we want to mark prekeys and one-time keys as published right before calling the identity service to prevent a scenario where the identity service is vending keys that have not been published by the client (e.g. the client crashes right after uploading to identity)

Copy looks okay. Thought about whether we could filter the list of channels before it gets to the keyserver, but we'd probably need a UI to show which ones are already taken, in addition to logic on the client to check each channel with the blob service. Probably too much additional complexity to be worth doing at this time

Discussed this with @ginsu offline and he indicated he wanted to land this now, so I suggested gating the logic so that we're sure that Farcaster channels are not currently tagged in production, so that we can make sure we have no blob holders that need to be cleared from clients later.

Are we storing the backup message and its signature in an encrypted way?

In D11764#338363, @ashoat wrote:

In D11764#338319, @inka wrote:

Should we rename siweAuthActionTypes to legacySiweAuthActionTypes and keyserverRegisterActionTypes to legacyKeyserverRegisterActionTypes?

Good call. I'll do those in separate diffs

Use the name walletLogIn for the result of useWalletLogIn(), and rename attemptIdentityWalletLogIn to attemptWalletLogIn