Generally looks good! If you apply the changes in D8391, this should be basically be ready to go

Nice, I think the API has been figured out! Some comments inline, but none of them should require a big refactor

Minor nits

Thanks for explaining! Your explanation gave me some helpful pointers, but I still had to do some investigation on my own to get the whole story.

I still can't tell what makes this case "special", and what justifies this hack. In no other place do we have to manually set closed. Why is this case different? Why can't we continue to rely on the standard mechanism for setting closed?

I skimmed through the last comment, as it's been a lot of back-and-forth recently and I want to move quickly here. Please keep that in mind, as I might've missed something.

2. Pass in all selected options as an array of ConfigurableCommunityPermissionOption, instead of a list of strings representing threadPermissions to the keyserver. Essentially, the keyserver would receive an array of:

[
   {
     title: 'React to messages',
     description: 'Allows members to add reactions to messages'
    },
    {
      title: 'Add members',
      description: 'Allows members to add other members to channels',
    }
]

After our discussion over chat, I think the new conclusion is that the client code for creating / managing roles shouldn't think about threadPermissions at all, and should instead use a new enum that reflects the list of user-facing permissions. The keyserver will handle converting from the new enum of user-facing permissions to threadPermissions... so some version of this data structure will likely still be necessary, but it will probably be keyserver-specific, and the format of the data structure might be different given differing requirements. Does that sound right to you @rohan?

Thanks for explaining!

Looks perfect! Thanks for iterating on this

Looks good, but I want to make sure that constants are kept in sync with CSS. I don't see any comments.

I really want to accept this, but frankly I'm confused about this diff.

Thank you, the types look great now!! I unfortunately haven't had time for a detailed review (just to complain about types 😅), so going to resign here so one of the original reviewers can take a closer look

Thanks @tomek! Would accept if not for the ManagePublicLinkScreen issue... for that, I'd to review the updates before accepting

Thanks Rohan for pointing out those inconsistencies! Would you mind putting up a separate diff to fix up the "Create Community" button too (so it's "Create community")? Figure it should only take a sec

Great work – I think this solution looks almost perfect! Can you make sure to address the inline comments before landing? If there's any ambiguity, or if my suggestion doesn't work for some reason, please feel free to re-request review

Thanks for the update! This is really close, but going to request changes one last time due to the number of comments.

Thanks for pointing to Shape<Media>. I patched this locally and found we can improve things a little bit after fixing that type.

Thanks @rohan! Mostly followed up in D8391, but one other thing I wanted to note here:

I appreciate your response, but I don't think my concern here was addressed:

Will the resultant WASM-compiled SQLite be committed to the repo or no?

Accepting to unblock, but have a couple comments. The title stuff could potentially be handled in a follow-up if that's your preference, as I suspect it might require design changes

After this lands, I can remove identity_auth_token from my production keyserver config, yeah?

Dependency looks good

Copy-pasting my comment from earlier:

Do you mean that it will desync before getting released or later? Because they not being synchronized, is the reason why we are generating static functions and not using validators directly. If at some point in the future, we update the validators we don't want to also update these functions because the migration code shouldn't change. So the CI job would have to be removed after shipping anyway.

This needs a very close review on the types. It looks pretty daunting, and I don't have time for this tonight unfortunately. Hopefully I will have some time tomorrow, but we'll see.

We already use this dependency

Is there anybody else you can ask to help with review? Best to avoid having me as a solo reviewer. I've been getting pulled into a ton of diff reviews lately (more than before) and my time for them is very limited...

This diff is very difficult to review on its own, as the significance of the format of this collection is not clear until you see the callsite in D8391. In general, it's best to include an initial callsite when introducing a utility function / utility collection like this

I am behind on a bunch of things and don't have the time to investigate this further right now, but I strongly suspect that we can do better here

I am accepting this fairly blindly. I don't have a good idea of all the callsites that need to be updated here, or the general data flow. Trusting that @bartek has thought it through and tested it carefully

It would be easier to review this if you included the first usage in the diff. It helps to be able to see the usage alongside the implementation

Also it looks like this fails Flow CI

This is a lot more anys and $FlowFixMes than I expected, and they aren't being immediately cast to a proper type after the any-cast. I'll need to take a closer look and try to type it myself before I can accept this, as I suspect there are better ways to do it. I'm also not sure that every single any-cast and $FlowFixMe is related to the issue that will be solved in the updated version of Flow

Thanks for explaining

Thanks for explaining

I'm not super familiar with the services codebase

I'm not super familiar with the services codebase

Same feedback as in D8343

I'm confused – what was not platform-agnostic about this before? It seems like you still need the state in lib, so I'm not really sure what this diff is achieving

1. Can you annotate every any-cast with an explanation as to why it is needed? Please include the Flow error you're seeing, and the other things you've tried. Going forward, please always include this when using an any-cast (or something comparable, like Object or Function or $FlowFixMe)
2. I worry that the codegenned file might get out of sync with its inputs. Before landing, can you create a Linear task to add a CI job that regenerates the file and confirms there are no changes? We should make sure we complete that task before we ship this project.