atBB Trust Model#

Version: 1.0 Last Updated: 2026-02-17 Audience: Forum operators considering or running a self-hosted atBB instance

Summary#

atBB is built on the AT Protocol, where users own their posts on their own Personal Data Servers (PDS). Forum-level records — forum metadata, categories, boards, roles, and moderation actions — belong to the Forum DID, which your AppView manages on behalf of admins and moderators.

The bottom line: You must trust the server running your AppView. In exchange, your users can trust that their posts belong to them — not to you, and not to your server.

What Each Party Controls#

Users control their own posts#

When a user writes a post on your forum, the AppView submits that post to the user's own PDS. The record lives in the user's AT Protocol repository. The user can take it with them if they move PDS providers, and no one can delete it from the AT Protocol network without the user's cooperation.

Your AppView can choose not to display a post (for example, if a moderator hides it), but it cannot delete the post from the user's PDS. The content remains in the user's control.

The operator controls forum structure#

Forum-level records — forum metadata, categories, boards, roles, and moderation actions — belong to the Forum DID. The Forum DID is the AT Protocol identity you created during setup (see FORUM_DID in your environment config).

The AppView holds the credentials for this account (FORUM_HANDLE and FORUM_PASSWORD). When an admin creates a category or a moderator bans a user, the AppView verifies their role and writes the record to the Forum DID's PDS on their behalf. Role assignment works differently: the AppView writes the updated role reference into the user's own membership record on their PDS — not the Forum DID's PDS.

This means the AppView has full write access to the Forum DID's repository, and can also update membership records on users' PDSes.

What "Trusting the AppView" Means#

Because the AppView holds the Forum DID's credentials, anyone who controls the AppView process can write any record to the Forum DID's repository. In practice, this includes:

• Creating, editing, or deleting categories, boards, and forum metadata
• Issuing, modifying, or removing moderation actions (bans, locks, hides)
• Assigning or removing roles — by updating the user's membership record on their PDS

This is a deliberate design choice for the MVP. The AppView is a single, trusted intermediary — it does not require a separate delegation layer.

Why This Model Is Acceptable for Self-Hosted Deployment#

The atBB MVP targets self-hosted, single-server deployments. In this model, the operator is the AppView. You control the server, the environment variables, and the deployment. There is no third party between you and your forum.

This is the same trust model used by almost every traditional forum platform (phpBB, Discourse, etc.). The difference is that AT Protocol gives your users a guarantee that their content remains portable and under their control, even though you as the operator control the forum structure.

For a community that runs and trusts its own infrastructure, this tradeoff is appropriate.

Security Implications#

If an attacker compromises your AppView server, they gain the ability to write arbitrary forum-level records. Specifically, they could:

• Escalate a user account to admin or owner
• Overwrite or fabricate moderation actions
• Modify category structure or forum metadata

Note: An attacker who compromises your AppView cannot forge user posts. User posts live on the user's own PDS and require the user's own credentials to create or modify.

Mitigations#

Protect the AppView server with standard hardening practices:

• Secrets management: Store FORUM_PASSWORD and SESSION_SECRET in environment variables, not in source code. Use a secrets manager or vault for production deployments. Never commit .env.production to version control.
• Firewall: Restrict inbound traffic to ports 80 and 443. Do not expose the database port to the public internet.
• SSH: Use key-based authentication. Disable password-based SSH login.
• Updates: Keep the host OS and the atBB container up to date. Review release notes before upgrading.
• Access control: Limit who has SSH access to the server. Each admin is a potential attacker if their machine is compromised.
• Monitoring: Set up log monitoring and alerts. Unexpected writes to the Forum DID's PDS are a sign of compromise.

See docs/deployment-guide.md for a full pre-launch security checklist.

Future: AT Protocol Privilege Delegation#

The current model — where the AppView holds the Forum DID's credentials — is a shortcut that avoids building a delegation layer at launch. At least one prposal exists for a system under the at.delegation namespace (see atBB-Community/at-delegation) that could replace this.

Under privilege delegation, admins and moderators would receive scoped write access to specific record collections on the Forum DID's repository. For example:

• A moderator would receive write access to space.atbb.modAction only — not to categories, boards, or roles.
• An admin would receive write access to categories, boards, and roles, but not the forum's core identity records.

This removes the AppView as the single key-holding bottleneck. It also enables multi-server moderation teams: a moderator on one server could act on a forum hosted on another.

The roadmap tracks this under the Privilege Delegation section of docs/atproto-forum-plan.md. It will not ship as part of the MVP.

Quick Reference#

Questions or concerns about this trust model? Open an issue at github.com/malpercio-dev/atbb-monorepo/issues.