[Spike] Feasability of Private Topics feature

[jnaviask]

Description

One idea we've tossed around in various forms since the inception of Commonwealth was privacy features, i.e. gating read access to certain parts of the application. We once had a notion of private communities, however this was deprecated years ago. The presently proposed form, following on the heels of Gating, is "Private Topics", scoped out in this product brief.

The tl;dr: the feature is to allow admins to mark topics that are gated as "private", where only admins + users passing the requirements check can read the contents. Note that all users will be able to see the existence of the private topic (e.g. in the sidebar or through the API), so a useful term may be "protected" instead of "private".

Areas of Investigation

Private topics bring up a few key concerns:

• Most basic level: what data model / API / UI changes would be needed? In particular, we will need to investigate how to handle access control considerations for read methods as well as writes, now that read authorization is required for some queries.
• Feeds and Notifications: what do we need to do to ensure that private threads/comments are not displayed on profiles and the dashboard feeds and other lists of content?
• Decentralization: how will private topics interface with Canvas? On what circumstances will we publish private threads/comments/reactions, and how much effort will it be to omit publishing to Canvas? @raykyri can act as point of reference here.
• Threat model: what means could a malicious user try to access private topics, if they were so inclined? What changes would be required to ensure they cannot?
• Enablement: what happens when a public topic "becomes" private? Will any additional migration work be needed to ensure proper protection on content? Or will only new content be protected under the requirements? May need additional info from Product to get specific requirements here.

Additional topics for research:

• Secrecy: how much additional effort would it be to support "secret" rather than "protected" topics, i.e. they do not appear at all in topic listings? What changes would be required?
• Encryption: how complex would encryption be, to ensure privacy through the wire? How do other platforms that support private content such as Discord handle encryption?
• Staking interactions: how will submitting content for staking or contests interact with privacy settings? @ianrowan may be able to answer this.
• Eventing: how will privacy tie into our event model, particularly on the frontend? How can we best architect a proper access control system in a clear + extensible way that addresses our needs and doesn't require a full conversion? @Rotorsoft may have insight here. #6802 implements gating authorization middleware

Deliverables

A document providing an overview of the systems design necessary to implement private topics + detailed answers to the above questions, such that we can proceed with implementation.

Timebox

4 hours ideally, 1 day if needed.

[dillchen]

add in additional areas for research, private chats

[CowMuon]

Key area for research here is the underlying permissions model, which is v much related to API unification.

[Rotorsoft]

We are building a small framework in libs/core that will separate validation and authorization concerns from the core domain logic. This is in preparation for the systematic refactoring of commands and queries, ideally using something like TRPC.

The reusable authorization middleware will deal with role/group based authorization, as well as membership/gating based authorization. Still a WIP.

[dillchen]

How long to implement Private Topics via named "small framework in libs/core"?

Estimate on story points / scope of changes?

[Rotorsoft]

We are just allocating 1hr a week (on Fridays) to review the new framework and make adjustments, considering we still have other tickets with higher priority. This is a common (less disruptive) approach with platform work... we will put the framework on the "shelf" for general use when ready. Guess we'll start scoping for adoption after Denver.

[ForestMars]

This is not currently scoped.

[dillchen]

Bumping this for Q3