I think we will also likely need to update docs to mention /webapp/ instead of /comm/ for loading the web app

Perhaps the URL that the keyserver expects for the web app should be something configurable via getCommConfig? We could preload / cache it similar to how we do with the URL facts today.

Do we retire the use of the commAppRouter and squadCalRouter names in a later diff?

CREATE_SUB_THREAD does work that way, but it's very special-cased...

@atul can you make a Linear task to track refactoring this to use the new update specs approach, and link the task here before landing?

After landing this diff, please send a message in the Releases channel to make sure I'm aware that the "bump version" commit will have to be changed. For now I'll continue to bump these versions in tandem

Overall I agree with the renaming – this makes a lot more sense.

Will this require some sort of synced rollout between keyserver and identity service?

In D9430#277058, @ashoat wrote:

There is perhaps a design question here around how to handle more than two tabs in ThreadMembersModalContent. Can you create a DES task on Linear and assign it to @ted to take a look? It might also be good to send a message to the Design Team chat in case there's some discussion to be had.

I think one of the conditions in the existing code had a mistake and was accidentally reversed

This looks right to me

@varun's suggestion

I checked nixpkgs and I couldn't find protoc-gen-js in the repo:

Sorry, I should have clarified earlier... I think it's actually okay for admins to have this permission. I just wanted to make sure members didn't have it!

In a meeting with @kamil today, he indicated that MessageStore.threads was in the process of being moved to SQLite. Have you synced with @kamil to make sure this won't conflict with that work? (Figure it would be a good idea for him to review this diff as well.)

Accepting since my requested change is "obvious" and shouldn't need further review. That said, if you disagree can you re-request review?

@ashoat are you sure we don't want silent fails also on production?

Might be good for @tomek to meet with @atul to share more context about the update syncing specs. Or potentially could be a subject for a teamwide "office hours" this Wednesday (although not sure of the impact of blocking this diff until then... maybe could be a follow-up task?)

Yeahhhh I considered that sort of approach but I personally find it less readable with all the special characters at the end

Is this new IntegrityStore persisted via redux-persist? If so, it's very unfortunate that we're adding more O(n) data to redux-persist... this decision has set back our efforts to move all O(n) data to SQLite.

This fixes my perf issues!

Thanks @kamil, your explanation makes sense. Let's keep validateAccountPrekey for log-in/register (but skip the upload step), and rename revalidateAccountPrekey to validateAndUploadAccountPrekeys

There is perhaps a design question here around how to handle more than two tabs in ThreadMembersModalContent. Can you create a DES task on Linear and assign it to @ted to take a look? It might also be good to send a message to the Design Team chat in case there's some discussion to be had.

It looks like ThreadMembersModalContent is still determining its tabs differently from how the pills are being determined. The fact that this code is different is what got us into this mess, and I'd like to make sure it's unified.

Rather than a script, it would make my life a little easier if we could put this is in keyserver/src/database/migration-config.js – that way it should automatically run when I deploy the keyserver next

I agree we do not need to call revalidateAccountPrekeys anymore from getOlmSessionInitializationDataResponder. However, I think we still need to do it in registerOrLogin, so that we make sure the prekey that we pass when calling the identity service is initialized (in case it is the first call) and not expired (in case the keyserver has not been touched in some time).

I noticed that when Jon was first working on this, he copy-pasted some of @marcin's functions and kept the same name. Since that point, it appears that the copy-pasted functions have diverged. I think we should look to deduplicate them, or maybe have one call the other. We should certainly rename them to have different names if we are going to keep both.