docs(community-management): add Session, Matrix, and SimpleX guides

docs/pages/community-management/index.mdx

@@ -15,3 +15,6 @@ title: "Community Management"
 - [Discord Security](/community-management/discord)
 - [Twitter/X Security](/community-management/twitter)
 - [Telegram Security](/community-management/telegram)
+- [Matrix Security](/community-management/matrix)
+- [Session Security](/community-management/session)
+- [SimpleX Security](/community-management/simplex)

docs/pages/community-management/matrix.mdx

@@ -0,0 +1,105 @@
+---
+title: "Matrix Security | Security Alliance"
+description: "Run a Matrix community safely: federation and homeserver trust, room join rules, power levels, ban lists and server ACLs, and cross-signed operator devices."
+tags:
+  - Community & Marketing
+contributors:
+  - role: wrote
+    users: [AllyPry]
+  - role: reviewed
+    users: []
+  - role: fact-checked
+    users: []
+---
+
+import { TagList, AttributionList, ContributeFooter } from '../../../components'
+
+# Matrix
+
+<TagList tags={frontmatter.tags} />
+<AttributionList contributors={frontmatter.contributors} />
+
+> 🔑 **Key Takeaway**: Federation makes room membership a data-distribution decision. Every homeserver with a member in
+> a room holds a copy of it, and every unverified operator device is an unaccounted-for reader.
+
+Matrix community security spans homeserver choice, device verification, room configuration, and federated
+moderation—each covered in depth in the [Matrix Security Guide](/guides/account-management/matrix). Use this page to
+find the right section.
+
+## The community manager's role in security
+
+Matrix is the decentralized option Web3 projects reach for when they want to run community infrastructure they control
+rather than rent. A project can host its own homeserver, keep its own metadata, and remain reachable from every other
+server in the federation. Element is the client most members will use.
+
+That control comes with operator responsibility that Discord and Telegram absorb on the project's behalf. Spam
+filtering, raid response, ban propagation, and abuse handling are the community team's job, executed through room
+configuration and moderation bots rather than a vendor's trust-and-safety pipeline.
+
+What differs most from centralized platforms is the trust boundary. A Matrix room is replicated to every homeserver
+that has a member in it, so admitting one member from a hostile server hands that server a copy of the room's history
+going forward. Encryption limits this to metadata, but many large community rooms are deliberately unencrypted so that
+moderation tooling works — which means content, too.
+
+### Why following this guide is not optional
+
+Matrix's per-device encryption model has an operational consequence community managers meet immediately: an unverified
+session is untrusted. Cross-signing exists so that a device added to an operator account — by an attacker with the
+password, or by a compromised homeserver administrator — is visibly unverified to everyone in the room. Ignoring those
+warnings discards the only signal the protocol provides.
+
+Room defaults are the other recurring failure. Encryption cannot be enabled retroactively and cannot be turned off once
+enabled, history visibility decides how much archive a raid inherits, and power level 100 cannot be revoked by an
+equal. These are decisions made at room creation that are painful to correct afterwards.
+
+### What is at stake
+
+| Risk | Consequence |
+| --- | --- |
+| **Unverified operator device** | Attacker-added session reads encrypted rooms and posts as the team |
+| **Lost recovery key** | Encrypted history becomes permanently unreadable on any new device |
+| **Hostile federated server** | A member from an abusive homeserver gives that server a copy of the room |
+| **Over-granted power levels** | A compromised administrator at level 100 cannot be demoted by another administrator |
+| **Permissive join rules** | Public, directory-listed rooms invite raids and archive scraping |
+| **Bridge exposure** | A bridge to another platform decrypts room content for the bridged side |
+| **Homeserver compromise** | Server operator visibility over metadata, and over content in unencrypted rooms |
+
+The guide addresses these with room-level configuration, moderation tooling, and homeserver operating practice.
+
+## What the guide covers
+
+The guide is structured by scope: personal account first, then room and server operations.
+
+| Scope | What it covers |
+| --- | --- |
+| **Personal account** | Recovery key setup, cross-signing every session, session review, discovery settings |
+| **Encryption limits** | Metadata exposure, unencrypted federated rooms, bridges, homeserver choice |
+| **Room and space operations** | Join rules, history visibility, power levels, moderation bots, ban lists, server ACLs |
+| **Homeserver operations** | Patching, registration policy, admin credentials, backups, federation monitoring |
+
+## Topic index
+
+| Topic | Summary | Guide section |
+| --- | --- | --- |
+| **Recovery key** | Secure Backup key that restores encrypted history and verifies new logins | [Account security checklist](/guides/account-management/matrix#account-security-checklist) |
+| **Cross-signing** | Verify every session; unverified devices are the protocol's compromise signal | [Account security checklist](/guides/account-management/matrix#account-security-checklist) |
+| **Session review** | Audit signed-in clients and sign out anything unrecognized | [Account security checklist](/guides/account-management/matrix#account-security-checklist) |
+| **What encryption covers** | Content is protected; membership, timestamps, and device lists are not | [Encryption limits](/guides/account-management/matrix#understanding-what-encryption-does-and-does-not-cover) |
+| **Join rules and history** | Invite-only, space-member, or knock rules; restrict pre-join history | [Room configuration](/guides/account-management/matrix#room-configuration-checklist) |
+| **Power levels** | Default 0, moderator 50, administrator 100; grant 100 rarely and audit it | [Room configuration](/guides/account-management/matrix#room-configuration-checklist) |
+| **Moderation bots and ban lists** | Draupnir enforcing bans and redactions across every protected room | [Moderation](/guides/account-management/matrix#moderation-and-abuse-response) |
+| **Server ACLs** | Ban an abusive homeserver from a room instead of chasing recreated accounts | [Moderation](/guides/account-management/matrix#moderation-and-abuse-response) |
+| **Homeserver hygiene** | Patching, restricted registration, admin MFA, tested backups | [Homeserver operations](/guides/account-management/matrix#homeserver-operations) |
+
+For step-by-step procedures, see the [Matrix Security Guide](/guides/account-management/matrix).
+
+## Further reading
+
+- [Matrix Security Guide](/guides/account-management/matrix)
+- [Community Management overview](/community-management/overview): how platform pages fit together
+- [Matrix.org moderation guide](https://matrix.org/docs/communities/moderation/): power levels, ban lists, server ACLs
+- [Element documentation](https://docs.element.io/): client settings and account security
+
+---
+
+<ContributeFooter />

docs/pages/community-management/overview.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Community Management | Security Alliance"
-description: "Secure Web3 communities on Discord, X (Twitter), and Telegram: operator credentials, anti-impersonation, phishing resistance, and incident handoff when channels fail."
+description: "Secure Web3 communities on Discord, X, Telegram, Matrix, Session, and SimpleX: operator credentials, anti-impersonation, and phishing-resistant channel hygiene."
 tags:
   - Community & Marketing
 contributors:
@@ -42,6 +42,12 @@ Deep, step-by-step controls live in the linked account-management guides.
    official-channel practices.
 3. [Telegram](/community-management/telegram): two-step verification, phone-number privacy, admin permissions, and
    man-in-the-group style threats.
+4. [Matrix](/community-management/matrix): federation and homeserver trust, room join rules, power levels, and
+   federated moderation with ban lists and server ACLs.
+5. [Session](/community-management/session): recovery-password custody, Account ID impersonation, and unencrypted
+   Communities run on operator-hosted servers.
+6. [SimpleX](/community-management/simplex): invitation links as access control, local database custody, member roles,
+   and moderation without user identities.
 
 ## Related security domains
 

docs/pages/community-management/session.mdx

@@ -0,0 +1,102 @@
+---
+title: "Session Security | Security Alliance"
+description: "Run a Session community safely: recovery-password custody, Account ID impersonation, unencrypted Communities, and moderation without a central account provider."
+tags:
+  - Community & Marketing
+contributors:
+  - role: wrote
+    users: [AllyPry]
+  - role: reviewed
+    users: []
+  - role: fact-checked
+    users: []
+---
+
+import { TagList, AttributionList, ContributeFooter } from '../../../components'
+
+# Session
+
+<TagList tags={frontmatter.tags} />
+<AttributionList contributors={frontmatter.contributors} />
+
+> 🔑 **Key Takeaway**: Session removes phone numbers and central accounts, so recovery and revocation disappear with
+> them. The recovery password is the account, and Communities are not end-to-end encrypted.
+
+Session account and Community security spans recovery-password custody, Account ID verification, privacy settings, and
+Community server administration—each covered in depth in the
+[Session Security Guide](/guides/account-management/session). Use this page to find the right section.
+
+## The community manager's role in security
+
+Session appeals to Web3 teams for the reason it appeals to everyone else: no phone number, no email address, and no
+central account provider. For a community manager who has watched a colleague lose an account to a SIM swap, that is a
+meaningful improvement.
+
+The same design removes the safety net. There is no support desk that can freeze a stolen identity, no password reset,
+and no way to revoke a leaked credential. A community manager operating on Session holds a key pair, and the entire
+security posture of the role reduces to how that key pair is stored and how members verify which Account ID is real.
+
+What differs from Discord and Telegram is that recovery is a project responsibility rather than a platform feature.
+Losing the recovery password means the operator identity is gone; leaking it means an attacker becomes that identity to
+every contact, with no mechanism to take it back.
+
+### Why following this guide is not optional
+
+Session's two chat surfaces have different security properties, and mixing them up is the most common operational
+mistake. Groups are end-to-end encrypted and suited to team coordination. Communities run on a Session Open Group
+Server (SOGS) and are **not** end-to-end encrypted on that server: whoever operates the instance can read the traffic
+it stores. Treating a Community as a private channel misplaces trust in an operator who may not even be the project.
+
+Impersonation is also harder to counter than on platforms with usernames and verified badges. Account IDs are long
+hexadecimal strings, and members cannot reasonably eyeball the difference between a real one and a near-match. The only
+durable answer is a project-controlled page listing official Account IDs and invite links, plus a stated policy that
+moderators never send the first direct message.
+
+### What is at stake
+
+| Risk | Consequence |
+| --- | --- |
+| **Recovery password leak** | Attacker restores the account and becomes the operator to every contact, permanently |
+| **Recovery password loss** | Operator identity is unrecoverable; contacts must be re-established out of band |
+| **Account ID impersonation** | Lookalike IDs direct members to scam links with no verified-badge signal to contradict them |
+| **Community server exposure** | The SOGS operator can read Community messages, which are not end-to-end encrypted |
+| **Unsolicited message requests** | Posting in a Community exposes the operator Account ID to mass phishing |
+| **Over-granted moderator rights** | Compromised moderator can act on the server with no central authority to intervene |
+| **Community cloning** | Duplicate rooms and invite URLs redirect members into attacker-controlled spaces |
+
+The guide addresses these with controls that fit the platform's constraints, starting with treating the recovery
+password like a wallet seed phrase.
+
+## What the guide covers
+
+The guide is structured by scope: personal account first, then Community operations.
+
+| Scope | What it covers |
+| --- | --- |
+| **Personal account** | Recovery password custody, privacy toggles, screen lock, notification content, contact verification |
+| **Community operations** | Choosing groups over Communities, moderator permissions, SOGS hosting, official channel lists |
+
+## Topic index
+
+| Topic | Summary | Guide section |
+| --- | --- | --- |
+| **Recovery password** | The mnemonic that encodes the account key; store it offline like a seed phrase | [Account security checklist](/guides/account-management/session#account-security-checklist) |
+| **Privacy settings** | Screen lock, read receipts, link previews, and Community message requests | [Account security checklist](/guides/account-management/session#account-security-checklist) |
+| **Account ID verification** | Compare the full ID out of band; matching prefixes and suffixes prove nothing | [Verifying who is on the other end](/guides/account-management/session#verifying-who-is-on-the-other-end) |
+| **Communities are not E2EE** | Community traffic is readable by the server operator; keep sensitive threads in groups | [Best practices](/guides/account-management/session#best-practices-for-safe-use) |
+| **Groups versus Communities** | Pick the surface by confidentiality requirement, not by member count | [Choosing groups or Communities](/guides/account-management/session#choosing-groups-or-communities) |
+| **Moderator permissions** | SOGS read, write, upload, and access rights granted at the minimum level | [Community and server checklist](/guides/account-management/session#community-and-server-checklist) |
+| **Compromise response** | Removing server permissions and re-establishing the operator under a new Account ID | [Community and server checklist](/guides/account-management/session#community-and-server-checklist) |
+
+For step-by-step procedures, see the [Session Security Guide](/guides/account-management/session).
+
+## Further reading
+
+- [Session Security Guide](/guides/account-management/session)
+- [Community Management overview](/community-management/overview): how platform pages fit together
+- [Session documentation](https://docs.getsession.org/): vendor documentation
+- [How to stay safe on Session](https://getsession.org/blog/how-to-stay-safe-on-session): vendor security guidance
+
+---
+
+<ContributeFooter />