Group Checking Ticket (When to check a group)

[zakhap]

When do we check a user's group membership?

Short answer is:

• When they sign into Common. ("immediately")
• When they land on a Community page that has groups. (TBC- to be confirmed)
• When they attempt any group-gated (write) action.

Longer answer is:

• When the user signs in - We collect their group memberships across all communities they have joined. [endpoint: tbd]
• When user lands on a community page with groups - This is included in original tech spec, and (per below) this check is needed for both for showing the user what actions they can/cannot take when they land on a community page, as well as for private gated communities. [endpoint: /refresh-memberships]
• On content creation - We optimistically update UI based on group memberships collected in previous checks. [endpoint: content creation route]
  • API (write) Request made → Back end re-verifies they have the required membership.
    • If their membership status hasn’t changed the backend returns a 200.
    • If however they no longer have the required membership (eg. their token balance for a required token has gone down) the server returns a reject_reason, and the client performs an optimistic rollback with a message to the user informing them of the error / missing membership requirement.
    • In the absence of more sophisticated UX treatment of this error state, that message can be presented in an error toast.
• On content read - API (read) Request made → meaning the user has already signed in, at which point the membership check ran (“immediately”) and so when they land on a gated group for which they have the appropriate membership, that content is visible for them to read we know which actions they are allowed to take, and which actions should be indicated as 'disabled' bc they do not have the required group membership.
  • NB. Private groups (ie what content is visible, not just which actions are disabled) is slated for v2, but is not a v1 requirement.

"Edge" Cases

• It should be obvious that a user’s group membership(s) may have changed between the time they signed in and when they land on a given gated community, so they could in theory be seeing content they are no longer entitled to. We have said we are okay with these “relaxed requirements”
• Furthermore, when a user loses membership in a group, content they formerly had permission to view will no longer be accessible (?) but in theory would be cached locally by their client. Expectation is that shouldn't be a concern (they had permission to view it when their client cached it.) That being said, Product has stated membership revocation should trigger a purge of the particular cache. Open question whether that is feasible for MVP.

Sequence Diagram

Please see the updated sequence diagram for a visual diagram of the user flow. (Above stated requirements take precedence over diagram, which may contain incidental errors WRT requirements.)

TTL Considerations

• We had discussed including a time-based membership check with an expiry, however not sure that really makes sense? In the context of our never expiring sign-in session, maybe, but then we're diving down the TTL rabbit hole, which we can avoid by refreshing at the the 3 check points listed above: sign-in, landing on community page, and tryna create content.

Open Questions

• Are we refreshing membership status for user landing on a community page ("after" signing in)? We have an endpoint for this /refesh-memberships however it seems like maybe the requirements have drifted? Are we only checking when they try to create content? My preference here (Forest) is we perform a non-blocking background refresh when they land on a community that has groups (since we "never" expire their sign-in session.)
• Is "revoking membership purges client cache" feasible for MVP? Many related questions incl. how we handle that across devices.

[mzparacha]

The OP has lots of questions, going through them and will leave thoughts here....

[mzparacha]

When the user signs in - We collect their group memberships across all communities they have joined. [endpoint: tbd]

Is this included in the scope of this ticket? If so can you please confirm if a new dedicated endpoint is planned for this?

When they land on a Community page that has groups. (TBC- to be confirmed)

I will use the GET /groups endpoint for this. Plz lmk if anything else is planned for this?

When they attempt any group-gated (write) action.

This seems very broad. Is content creation for threads/proposals of a gated group the only thing affected by this?

On content creation - We optimistically update UI based on group memberships collected in previous checks. [endpoint: content creation route]

Does this mean all content creation routes?

On content read - API (read) Request made → meaning the user has already signed in, at which point the membership check ran (“immediately”) and so when they land on a gated group for which they have the appropriate membership, that content is visible for them to read.

Just to understand this better. If a topic is gated, and a thread is created in that topic, only the member of that gated group will be able to view the thread?

Furthermore, when a user loses membership in a group, content they formerly had permission to view will no longer be accessible (?) but in theory would be cached locally by their client. Expectation is that shouldn't be a concern (they had permission to view it when their client cached it.) That being said, Product has stated membership revocation should trigger a purge of the particular cache. Open question whether that is feasible for MVP.

This will depend on the type of data/cache we are handling in frontend. To reduce complexity, I think it's better to handle this as a followup.

Are we refreshing membership status for user landing on a community page ("after" signing in)?

ATM, no

Are we only checking when they try to create content?

ATM, no.

Is "revoking membership purges client cache" feasible for MVP? Many related questions incl. how we handle that across devices.

I think it's better to handle this as a followup.

cc: @zakhap @ForestMars @jnaviask @rbennettcw

[mzparacha]

Added the blocked label, as i am unsure about some things (asked above)

[mzparacha]

Per discussion with @ForestMars, these are engineering questions for @rbennettcw.

cc: @rbennettcw

[CowMuon]

When. user signs in - We collect their group memberships across all communities they have joined.

Correct, this is so the client has the user's groups cached.

NB. that is mainly for performance and has no correctness guarantees, given their original session will not expire unless they are inactive for 7 days (extant), now 30 days (we are about to change, don't recall exact ticket # offhand.)

[endpoint: tbd]

Confirm with Ryan on endpoint pls

[rbennettcw]

Regarding membership refresh:

• We already have the /refresh-membership route which refreshes group memberships for the user address within a single community (can optionally specify a specific topic for more granularity)
• If a refresh is needed for multiple communities, the frontend can technically invoke this route multiple times in parallel– one request per community
• My recommendation is for the frontend to pick wisely which communities to refresh rather than take a nuclear approach of refreshing all of them at once– since a refresh is relatively expensive operation in terms of latency and 3rd party API calls.

On-the-fly membership checks (topic level) are already implemented on the backend within the action routes:

• Create thread
• Create comment
• Create reaction

Each membership has a TTL of 2 minutes (via hardcoded constant), and will only hit the TBC if a membership is stale/expired.

• The /refresh-memberships route already takes the TTL into consideration for determining whether to hit the TBC or not.
• For simplicity and maintainability, I recommend we do not utilize any additional layers of caching, since the TTL effectively serves this purpose already

In terms of read access, the /refresh-memberships route also provides access info

• It performs a refresh, then returns a list of topics within the community and the user's membership status for each topic (approved or denied). The frontend can then use the info to update the UI accordingly.

The backend is effectively complete in terms of what's scoped in this ticket.

[CowMuon]

Given Ryan's reply Is this still blocked? @mzparacha

[mzparacha]

Yes, thank you both @CowMuon @rbennettcw.

On content creation - We optimistically update UI based on group memberships collected in previous checks. [endpoint: content creation route]

On-the-fly membership checks (topic level) are already implemented on the backend within the action routes: Create thread Create comment Create reaction

Per this, I will implement the frontend gating checks for creating threads, comments, and reactions.

[mzparacha]

Status

I summarized some actions items from the ticket description (those action items are updated in OP)

@zakhap Please lmk if you feel these are good? (asking since it looks like a product question)

Also for this question in OP

Furthermore, when a user loses membership in a group, content they formerly had permission to view will no longer be accessible (?) but in theory would be cached locally by their client. Expectation is that shouldn't be a concern (they had permission to view it when their client cached it.) That being said, Product has stated membership revocation should trigger a purge of the particular cache. Open question whether that is feasible for MVP.

Its totally doable, infact easier to do since we have react query setup, that can invalidate a query/data (let's say threads/topics) based on another query data (i.e /refresh-membership response) -- I made the action item 3 in ticket description for this.

cc: @CowMuon @zakhap @jnaviask

[zakhap]

@rbennettcw @mzparacha: I want to make clear what is and is not going into V1. When @CowMuon added the following line to Ticket above:

On content read - API (read) Request made → meaning the user has already signed in, at which point the membership check ran (“immediately”) and so when they land on a gated group for which they have the appropriate membership, that content is visible for them to read.

I want to make sure that we are NOT implementing READ access control in V1. All content on Commonwealth will continue to be visible to All users at this time. However, it is important to know whether or not the user is the requisite Group to participate (create threads, comments, reactions) on the page they are accessing. We have disabled states in the UI on "View Thread" Pages for commenting + reactions as well as helper callout on the "Create Thread" Page as well (#5397). It is for these UX affordances that we need to know what Group a user is in on Content Read.

@mzparacha in response to your last comment, these action items are not necessary in the present moment given that we are not making private (or hiding, or adding "Read access control") Topics at this time.

[CowMuon]

Thanks for the clarification here Zak, updated to indicate what's v1 and what's v2.