The migration goes through this function. It seems that the result of this is that we would assume the user is a member of all thick threads they can see, but that's not accurate, right?

When we pass true as an argument to getThickThreadRolePermissionsBlob we get exactly the same behavior we had before this diff. But to make it correct, from the migration's point of view, we would need to extend getRolePermissionBlobs to also take the flag. (assuming we want to keep the approach from this diff, which is unlikely). And yes, we would assume that the user is a member, exactly as before this diff.

About the deprecatedUpdateRolesAndPermissions function, it seems it was used in migrations on both native and web, in migration 78.

When a user isn't a member of a sidebar, they should be able to join it, so they should have permission to do so. But I have to check how this mechanism works on keyserver and how to migrate it to the client.

We don't have a mechanism for permission inheritance for thick threads on clients. Migrating this whole mechanism to a client sounds like a project on its own, and should be scoped. With the limited time to launch, this sounds like something too ambitious, but we will know better after the scoping.

createThickRawThreadInfo is used for both sidebars and threads.

I think they should have no role permissions

Yes, that's correct

For thick threads, we have at most two levels of threads, so child and descendant should be equal, but I wanted to keep this consistent with thin threads.

I was wondering whether we should take a similar approach also when 1. the viewer is a member or when 2. creating membership permissions for non-viewer members. It would be more correct, but wouldn't change anything now, because the resulting permissions would be equal.

Makes sense!