Hidden channels leaked via Shared addresses dialog

[glitchminer]

Bug Report

Description

Channel not shown in channel list (assumed due to permissions not met) is revealed via shared addresses dialog.

Additional Information

• Status desktop version: 2.28.1 RC6
• Operating System: Mac

[caybro]

That was the design requirement afair, unless the channel is marked as "private", we show it here in the permissions overview panel, even if the token criteria are not met

[jrainville]

unless the channel is marked as "private"

Private and Hidden are used interchangeably. So yeah, this is a bug, we should show those channels in the Shared addresses dialog unless met.

[jrainville]

I'll move this to 2.29 as it's not a huge issue that requires to be fixed asap. Still gonna put it as high priority for 2.29

[jrainville]

@noeliaSD FYI' I put this as ui-team, since the model should in theory already have the right info and we just need to filter out the hidden channel on the UI.

[caybro]

@noeliaSD FYI' I put this as ui-team, since the model should in theory already have the right info and we just need to filter out the hidden channel on the UI.

That's the part I don't understand; we show the channel even if the token criteria are not met, unless the permission is marked as private. The fact that the channel is hidden in the chat list doesn't mean it should be also hidden in the dialog, or am I getting it wrong? :)

[caybro]

Let's take this permissions model snippet as an example:

channelsModel: [
                    {
                        key: "general",
                        channelName: "general discussion"
                    }
                ]
...
permissionsModel:
        {
            id: "viewAndPost1a",
            holdingsListModel: root.createHoldingsModel3(),
            channelsListModel: channelsModel,
            permissionType: PermissionTypes.Type.ViewAndPost,
            permissionState: PermissionTypes.State.Approved,
            isPrivate: true,
            tokenCriteriaMet: false
        },
        {
            id: "viewAndPost1b",
            holdingsListModel: root.createHoldingsModel2b(),
            channelsListModel: channelsModel,
            permissionType: PermissionTypes.Type.ViewAndPost,
            permissionState: PermissionTypes.State.Approved,
            isPrivate: false,
            tokenCriteriaMet: true
        },
        {
            id: "viewAndPost1c",
            holdingsListModel: root.createHoldingsModel3a(),
            channelsListModel: channelsModel,
            permissionType: PermissionTypes.Type.ViewAndPost,
            permissionState: PermissionTypes.State.Approved,
            isPrivate: false,
            tokenCriteriaMet: false
        }

These are 3 separate permissions (potentially with 3 separate private flags) but all of them referring to one single channel. Which private flag should we respect in the UI?

Atm, we will only hide the viewAndPost1a permission item because it's private and not met; but that doesn't mean we will hide the channel from the permissions overview

[jrainville]

That property is called hideIfPermissionsNotMet in different models.

If that is true, that means that should hide the channel if none of the permissions are met.

I think later we should move the logic to status-go so that we just don't have access to the channel if the permission is not met, but it's not gonna be until 2.30

[caybro]

That property is called hideIfPermissionsNotMet in different models.

If that is true, that means that should hide the channel if none of the permissions are met.

I think later we should move the logic to status-go so that we just don't have access to the channel if the permission is not met, but it's not gonna be until 2.30

OK, finally understood the problem mentally :) My main question then: is this information available prior to joining the community? I see it's not part of the "permissionsModel", but rather comes from the "chat_section"

[caybro]

And second one: would this flag (hideIfPermissionsNotMet) override what might be set in individual permissions for the given channel?

[noeliaSD]

That property is called hideIfPermissionsNotMet in different models. If that is true, that means that should hide the channel if none of the permissions are met. I think later we should move the logic to status-go so that we just don't have access to the channel if the permission is not met, but it's not gonna be until 2.30

OK, finally understood the problem mentally :) My main question then: is this information available prior to joining the community? I see it's not part of the "permissionsModel", but rather comes from the "chat_section"

Another question should be... Once the UI gets this flag per channel, should "manually" loop through all the permissions to see if the related channel has some permisions AND if this specific permission is met?? I'm wondering if this is some information that the backend can provide directly precalculated @jrainville

[noeliaSD]

And second one: would this flag (hideIfPermissionsNotMet) override what might be set in individual permissions for the given channel?

I understand that NO. The UI needs to loop through the permissions and if some are met, then the channel is shown. If none are met, then the channel is hidden

[noeliaSD]

That property is called hideIfPermissionsNotMet in different models.

If that is true, that means that should hide the channel if none of the permissions are met.

I think later we should move the logic to status-go so that we just don't have access to the channel if the permission is not met, but it's not gonna be until 2.30

Oh I see the answer here.. so it's planned to be done in the backend but now the UI should do this manual loop as a "quick" fix, right?

[caybro]

That property is called hideIfPermissionsNotMet in different models. If that is true, that means that should hide the channel if none of the permissions are met. I think later we should move the logic to status-go so that we just don't have access to the channel if the permission is not met, but it's not gonna be until 2.30

Oh I see the answer here.. so it's planned to be done in the backend but now the UI should do this manual loop as a "quick" fix, right?

Yeah but we still need to know the value of hideIfPermissionsNotMet for the given channel, even when doing the manual loop, that's the problem

[jrainville]

My main question then: is this information available prior to joining the community? I see it's not part of the "permissionsModel", but rather comes from the "chat_section"

Ah right, I think right now, it's only available in the chat section model. It would be possible to add it to that other model, but the problem is that until the check for all permissions is done, we won't have that info. Maybe we should hide the channels until we have confirmation that their permissions are fulfilled?

We should wait until John or Ben answer this question I asked here: https://github.com/status-im/status-desktop/issues/13878#issuecomment-2102886626

If we end up implementing that encryption feature, this ticket right here becomes moot, because the UI won't even have access to those channels

[caybro]

My main question then: is this information available prior to joining the community? I see it's not part of the "permissionsModel", but rather comes from the "chat_section"

Ah right, I think right now, it's only available in the chat section model. It would be possible to add it to that other model, but the problem is that until the check for all permissions is done, we won't have that info. Maybe we should hide the channels until we have confirmation that their permissions are fulfilled?

We should wait until John or Ben answer this question I asked here: #13878 (comment)

If we end up implementing that encryption feature, this ticket right here becomes moot, because the UI won't even have access to those channels

@jrainville I guess we can postpone this for later? I don't see a way to fix this at the moment really, given the fact we don't have the information available prior to joining the community

[jrainville]

@jrainville I guess we can postpone this for later? I don't see a way to fix this at the moment really, given the fact we don't have the information available prior to joining the community

Yeah, I think we can move it to 2.30 for now and re-assess then if it's still an issue

[caybro]

@noeliaSD moved this to 2.30 milestone

[jrainville]

This issue is a non-issue in the end. As discussed here with John, we actually want the hidden channels in the shared address list.

The hidden property is really only for the chat list and searches. It,s not hidden for privacy reason but for UX reasons. (the content of those channels is obviously encryped)