Safe to land out of order since it's purely rename

resequence

Safe to land out of order since it's purely rename

resequence

In D12598#357378, @ashoat wrote:

Is the idea here that we'll never need to decode the permissions on RawThreadInfo again, since we don't store the permissions on the client?

address comments

address comments

In D12683#359698, @ashoat wrote:

In D12683#359547, @ginsu wrote:

Don't we now need to consider NO_FID_METADATA in all places we fetch the FID? It seems like it would need to be checked at every place the FID is fetched.

In the linear task we said:

Don't prompt if the FID in Redux is null NONE

Based off this I was under the impression that we only want to keep NO_FID_METADATA something that is only in redux/sqlite and not in the identity service. By keeping NO_FID_METADATA only in redux/sqlite, we would re-show the farcaster prompt to the user if they ever logged out + logged back in on native, and my thinking was that this would act as another one time nudge to the user that they should connect their farcaster account to comm.

It seems like I may have misinterpreted this point. If I did I should be able to easily update this diff so that we also have NO_FID_METADATA stored in the identity service if the user decides not to connect their farcaster account

I think there's some confusion here. I'm not suggesting storing NO_FID_METADATA on identity.

Rather, I'm concerned that we don't have any updates to code that fetches/checks syncedMetadataNames.CURRENT_USER_FID here.

We are storing a new special value in that field, that should be treated equivalently to null/undefined. Don't we need to update the code that fetches/checks syncedMetadataNames.CURRENT_USER_FID so that it knows to treat this special value as null/undefined?

Let me know if I'm missing something!

localeCompare

I don't feel qualified to review this diff... @will, could you maybe take a look?

Didn't review the code closely since it's marked as a move diff

resolve merge conflicts

resolve merge conflict

resolve merge conflicts

resolve merge conflict

resolve merge conflict

Looking at uploadInviteLinkBlob, this appears to be the same thing we do there

In D12683#359547, @ginsu wrote:

Don't we now need to consider NO_FID_METADATA in all places we fetch the FID? It seems like it would need to be checked at every place the FID is fetched.

In the linear task we said:

Don't prompt if the FID in Redux is null NONE

Based off this I was under the impression that we only want to keep NO_FID_METADATA something that is only in redux/sqlite and not in the identity service. By keeping NO_FID_METADATA only in redux/sqlite, we would re-show the farcaster prompt to the user if they ever logged out + logged back in on native, and my thinking was that this would act as another one time nudge to the user that they should connect their farcaster account to comm.

It seems like I may have misinterpreted this point. If I did I should be able to easily update this diff so that we also have NO_FID_METADATA stored in the identity service if the user decides not to connect their farcaster account

Both of my pieces of feedback below are also mentioned in D12685, so feel free to just address them there if it's easier

Sorry for another round, but I'm concerned that we'll never query identity for an FID if the user dismisses the Farcaster prompt.

rebase and land

rebase and land

We wouldn't want to (for instance) result in a thread being created with no messages, or an account being created with no chats.

Therefore if the database result set is malformed and we aren't able to properly check if there's a member that's an admin in community root, shouldn't we opt to include the threadID in threadIDsWithDisabledPermissions rather than exclude it? Think it'd make sense to err on the side of narrower vs. more expansive permissions if there's an error case?

I think I'm misunderstanding the error scenarios and the logic needed to handle them. Personal instinct would be to throw some sort of error if there's malformed data vs. having to add logic to try to account for scenarios that shouldn't(?) occur?

Check the IDs in state sync specs

Addressed all feedback. Decided to create a separate create_sidebar spec

Don't we now need to consider NO_FID_METADATA in all places we fetch the FID? It seems like it would need to be checked at every place the FID is fetched.

JK, this should be the correct logic. Think I got thrown off by

forgot to save/commit changes

address comments

Just jotting down my understanding

update

Planning changes to do another read through logic

If the network issue gets triggered by the keyserver connection status cycling, then we'll want to add some condition to eg. make sure it only runs once per app start / foreground event. If that's the case, please re-request review. Otherwise it looks good to land!

fix network call getting triggered when client disconnect with the keyserver socket

Passing back to figure out what to do if communityMembersToRole isn't present.