Right now, our WorkFlows miss a key transition: a user/account becoming part of the site as a recognized participant.

    For example, in the following two flows, I believe we are missing a step:

      Subscription Flow: user subscribe to a site (receives notifications/updates)

          Empty Mermaid block

      Comment Flow: user interacts with content (creates contributions)

          Empty Mermaid block

    But in both cases, we don’t record the moment the Account is registered in the Site’s community graph (with a role, status, permissions, provenance, etc.).

    So the question is: do we need an explicit Site Members List, or can membership be derived/implicit?

    If we introduce membership explicitly, we likely end up with two related but distinct sets:

      The following list: Accounts an Account follows

      Membership list: Accounts that belong to a Site community (with roles/status)

    Now: what’s the best data model?

      Key idea: don’t model “lists”, model “relationships.”

        Lists become views. The underlying primitive is an edge:

          Account —(Relationship)→ Site

        Where a relationship has a type, a state, and metadata.

        This keeps you from duplicating “lists” and lets you answer everything by querying edges.

          Option A: One relationship resource with kind + status
          1

            Create a single resource like:

              SiteRelationship

                site_id

                account_id

                kind: "follow" | "member" | "contributor" | "moderator" | "owner" | ...

                status: "active" | "pending" | "invited" | "banned" | "left"

                created_at, updated_at

                created_by (traceability)

                source: "subscription_flow" | "comment_flow" | "invite" | "domain_auto_join" | ...

                optional: roles (if you want multiple roles), scopes, reason, expires_at

              Views

                “Account following list” = relationships where kind=follow AND status=active

                “Members list” = relationships where kind in {member, moderator, owner} AND status=active

                “Contributors” = relationships where kind=contributor or derived from contributions

              Why this works:

                avoids duplicating edge tables

                supports pending invites / moderation actions cleanly

                easy audit trail

          Option B: Membership is a role on the same edge

            Same as Option A but even simpler:

              relationship_type = "site_participation"

              roles = ["follower", "member", "moderator"]

              status as above

            This is great if you expect users to have multiple simultaneous roles (follower + member), and you don’t want two edges.