{"path":"research/auth-patterns-deliberation-platforms.md","content":"# Authentication Patterns Across Deliberation & Knowledge Platforms\n\n**Research date**: 2026-03-30\n**Purpose**: Inform Deliberus auth architecture decisions\n\n---\n\n## Platform-by-Platform Analysis\n\n### 1. Kialo (kialo.com) — Argumentation Platform\n\n**Auth methods**:\n- Email + password (standard signup)\n- **Email-less accounts** (username + password only — no email required)\n- Google SSO (via Google Classroom integration)\n- Microsoft SSO\n- Clever SSO (US education platform)\n- LMS integration via LTI (Schoology, Moodle, Canvas, Blackboard, Brightspace)\n- Optional 2FA\n\n**Anonymous contribution**: No truly anonymous participation. However, discussions can be configured as **\"Anonymous Discussions\"** where participant identities are hidden from other participants (but not from admins). Email-less accounts provide pseudonymity.\n\n**Onboarding friction**: **2-3 clicks** for social login (Continue with Google → confirm). Email-less signup is ~4 fields (username, password, confirm password, display name). Very low friction overall.\n\n**Key insight**: Kialo's email-less accounts are notable — they explicitly trade account recovery for lower onboarding friction, especially for students. The display name is separate from the login username, providing a pseudonymity layer. Their \"Anonymous Discussions\" feature hides authorship from peers while maintaining admin accountability.\n\n---\n\n### 2. Pol.is (pol.is) — Opinion Clustering\n\n**Auth methods**:\n- Facebook login (original, still present)\n- Twitter login (participation interface)\n- Email login (requested heavily by community)\n- **Fully anonymous voting** — the core participation mode requires NO login at all\n- Google auth was the #1 requested addition (as of 2020 GitHub issue #97)\n- OpenID Connect support opened as issue #1750 (Dec 2023, still open)\n\n**Anonymous contribution**: **YES — the default mode.** Polis's core interaction (agree/disagree/pass on statements) is fully anonymous. Statement *submission* can also be anonymous depending on configuration. The `xid` system allows deployers to pass external user IDs for linking without requiring Polis accounts.\n\n**Onboarding friction**: **Zero clicks for voting.** The embedded widget lets anyone vote immediately. Statement submission may require login depending on configuration. Admin accounts require Facebook or email login.\n\n**Key insight**: Polis demonstrates that anonymous participation *at scale* works for opinion clustering — Taiwan's vTaiwan used it with millions of participants. The system's value comes from statistical patterns across anonymous votes, not individual accountability. However, the community has long requested more auth providers — Facebook-only login was a significant barrier. The `xid` external ID system is clever: it lets the embedding organization handle identity however they want, passing a token to Polis.\n\n---\n\n### 3. Loomio (loomio.com) — Deliberation & Decision-Making\n\n**Auth methods** (Ruby on Rails, Devise + OmniAuth):\n- Email + password (primary)\n- Google OAuth2 (via `GOOGLE_APP_KEY`/`GOOGLE_APP_SECRET` env vars)\n- Facebook OAuth2 (same pattern)\n- SAML SSO (via `SAML_APP_KEY` + `SAML_IDP_METADATA_URL` env vars — supports Keycloak, OneLogin, etc.)\n- OpenID Connect (mentioned as future direction, unclear current status)\n- Plugin architecture for adding custom OAuth providers (Twitter example documented)\n\n**Anonymous contribution**: **No.** Loomio is designed for identified group deliberation. Every participant has an account. Groups are typically invitation-only. The platform is oriented toward organizational decision-making where accountability matters.\n\n**Onboarding friction**: **3-5 clicks** — email signup with confirmation, or social login. But the real friction is the *invitation* step: most Loomio groups require an invite link or admin approval.\n\n**Key insight**: Loomio's auth is deliberately simple because their trust model is different — it's for known groups (cooperatives, boards, organizations), not open public deliberation. The SAML support is telling: their enterprise/organization customers need it. The plugin architecture for adding OAuth providers is well-designed (inherit from `Clients::Base`, add controller, register in `providers.yml`).\n\n---\n\n### 4. Discourse (discourse.org) — Forum Platform\n\n**Auth methods** (Ruby on Rails, most comprehensive of any platform studied):\n- Email + password (built-in)\n- **Built-in social login plugins** (ship with core):\n  - Google OAuth2\n  - Facebook\n  - Twitter\n  - GitHub\n  - Discord (added ~2023)\n- **OpenID Connect** (bundled with core — the recommended modern path)\n- **OAuth2 Basic plugin** (for non-OIDC OAuth2 providers)\n- **DiscourseConnect** (Discourse's own SSO protocol — for making Discourse the *consumer* of your existing auth system)\n- SAML (via plugin)\n- Auth0, Okta, Keycloak, Azure AD (all via OIDC)\n- Passkeys/WebAuthn (added 2024)\n- Magic link / passwordless email login\n\n**Anonymous contribution**: **No.** Discourse requires accounts for all posting. Reading is public. Trust levels (0-4) gate capabilities: new users can't post links, upload images, or send PMs until they've read enough content. This is the \"earn your way in\" model.\n\n**Onboarding friction**: **2-3 clicks** for social login. Email signup requires confirmation. But **Trust Level 0→1** requires reading 5 topics and 30 posts before full participation — deliberate friction to ensure quality.\n\n**Key insight**: Discourse's approach is the gold standard for configurable auth in open-source community platforms. Three SSO mechanisms (OIDC, OAuth2 Basic, DiscourseConnect) cover every integration scenario. The trust level system is the most relevant pattern for Deliberus — it decouples *identity verification* from *participation privileges*. You can sign up easily, but your influence grows with demonstrated engagement.\n\n---\n\n### 5. Wikipedia / MediaWiki — Collaborative Knowledge\n\n**Auth methods**:\n- Username + password (custom auth system, not OAuth-based for user accounts)\n- **Logged-out editing allowed** (the defining characteristic)\n- OAuth extensions available for external provider login (Google, Facebook, GitHub via `Extension:OAuth` and `Extension:PluggableAuth`)\n- CentralAuth for cross-wiki SSO (shared login across all Wikimedia projects)\n- **Temporary accounts** (NEW, rolling out 2024-2025): replacing raw IP attribution\n\n**Anonymous contribution**: **YES — historically the core design.** Anyone could edit without an account; edits were attributed to IP addresses. This is changing:\n\n**The Temporary Accounts system** (2024-2025 rollout) is highly relevant to Deliberus:\n- Logged-out edits now get auto-generated temporary accounts (`~2024-1234567`)\n- Same device = same temporary account for 90 days (cookie-based)\n- IP addresses hidden from public, visible only to authorized moderators\n- Temporary accounts can receive notifications, be thanked, be pinged\n- Cannot be converted to registered accounts\n- After 90 days, cookie expires → new temporary account\n- Motivated by privacy regulations (GDPR etc.)\n\n**Onboarding friction**: **Zero clicks** for reading and editing. Account creation is optional. Registered accounts unlock: custom watchlists, talk page, preferences, no IP exposure, ability to create pages (on some wikis), and skip some anti-vandalism checks.\n\n**Key insight**: Wikipedia is the strongest evidence that low-friction anonymous contribution works at civilizational scale. BUT: it requires massive anti-vandalism infrastructure (bots, patrollers, CAPTCHA, abuse filters, IP blocking). The new temporary accounts system is a fascinating middle ground — pseudonymous-by-default with accountability available to moderators. The 90-day rotation prevents long-term tracking while maintaining short-term consistency. This is the closest existing model to what Deliberus might need.\n\n---\n\n### 6. LessWrong / ForumMagnum — Rationalist Community\n\n**Auth methods** (Node.js/TypeScript, ForumMagnum framework):\n- Email + password (with password reset)\n- **Google OAuth** (primary social login)\n- **GitHub OAuth** (secondary social login)\n- Legacy LW1 credential migration (historical — ported bcrypt hashes from the old Meteor-based site)\n- Built on Vulcan.js/Meteor accounts system (historically), now custom ForumMagnum\n\n**Anonymous contribution**: **No.** All posts and comments require accounts. Voting requires accounts. Reading is public. Strong real-name culture (though pseudonyms are accepted). Karma system gates visibility and posting frequency.\n\n**Onboarding friction**: **2 clicks** for Google login (the dominant path). Email signup requires confirmation. New users start with limited karma; high-quality contributions earn karma which unlocks capabilities (e.g., strong upvotes, moderation tools).\n\n**Key insight**: LessWrong's approach — just Google + GitHub + email, no Facebook/Twitter — reflects their community's demographics (technical, privacy-conscious). The karma system parallels Discourse's trust levels but is more granular and reputation-based. The ForumMagnum codebase (open source) also powers the EA Forum, demonstrating the \"same auth framework, different community\" pattern.\n\n---\n\n### 7. Hypothesis (web.hypothes.is) — Web Annotation\n\n**Auth methods** (Python/Pyramid, custom OAuth2 server):\n- Email + password (primary, via `h` service's own account system)\n- **Hypothesis IS its own OAuth2 provider** — third-party apps authenticate via Hypothesis accounts using standard OAuth2 authorization code flow\n- `pyramid-googleauth` exists in their GitHub org (for internal admin tools, not user-facing)\n- No social login for end users — Hypothesis accounts only\n- API keys for programmatic access\n- Group-based access control for private annotations\n\n**Anonymous contribution**: **Partial.** Public web annotations are visible to anyone. But *creating* annotations requires a Hypothesis account. Annotations can be made in private groups (visible only to members) or public (visible to all). There's no anonymous annotation mode.\n\n**Onboarding friction**: **4-5 clicks** — create account (username, email, password), confirm email, install browser extension, activate on page. Higher friction than most, but justified by the browser extension requirement.\n\n**Key insight**: Hypothesis chose to be its own identity provider rather than delegating to Google/Facebook. This gives them full control over the annotation identity namespace — important because annotations persist across the entire web. Their OAuth2 server design means third-party tools (LMS platforms, Pressbooks) can integrate without Hypothesis needing to support every auth provider. The lesson: if your identity *is* your product's core value, own it.\n\n---\n\n## Comparative Summary\n\n| Platform | Social Login | Anonymous | Own Auth | Onboarding Clicks | Trust Model |\n|----------|-------------|-----------|----------|-------------------|-------------|\n| **Kialo** | Google, Microsoft, Clever | Pseudo (email-less accounts) | Yes | 2-3 | Admin-controlled visibility |\n| **Pol.is** | Facebook, Twitter | **Yes (voting)** | Yes | **0 (voting)** | Statistical (clustering) |\n| **Loomio** | Google, Facebook | No | Yes + SAML | 3-5 + invite | Invitation-based groups |\n| **Discourse** | Google, FB, Twitter, GitHub, Discord + OIDC/OAuth2/SAML | No | Yes | 2-3 + trust levels | Progressive trust levels |\n| **Wikipedia** | None (extensions available) | **Yes → Temporary accounts** | Yes (custom) | **0** | Anti-vandalism infrastructure |\n| **LessWrong** | Google, GitHub | No | Yes | 2 | Karma-based reputation |\n| **Hypothesis** | None | No | Yes (is own OAuth provider) | 4-5 | Group membership |\n\n---\n\n## Patterns That Work for Community Deliberation\n\n### Pattern 1: Progressive Trust (Discourse model)\n**How it works**: Easy signup (social login or email), but capabilities unlock gradually as users demonstrate good faith. New users can read and make basic contributions; advanced capabilities (editing others' work, moderation, creating categories) require proven track record.\n\n**Why it works for deliberation**: Separates the identity question from the quality question. You don't need to verify who someone *is* to verify that their arguments are *good*. Let the arguments earn trust, then gradually extend trust to the person.\n\n**Deliberus relevance**: HIGH. Claims and arguments can be evaluated on their merits regardless of who submitted them. But curation, voting weight, and moderation powers should require demonstrated engagement.\n\n### Pattern 2: Anonymous Contribution + Identified Moderation (Wikipedia model)\n**How it works**: Anyone can contribute with minimal friction. Contributions are attributed to pseudonyms or temporary identities. A smaller group of identified, trusted moderators can see more identity information and exercise quality control.\n\n**Why it works for deliberation**: Maximizes input diversity. People contribute arguments they might not under their real name (especially on politically sensitive topics). The temporary accounts model provides just enough consistency for conversation continuity without permanent tracking.\n\n**Deliberus relevance**: HIGH for the \"Wikipedia for argumentation\" vision. The Wikipedia temporary accounts system (90-day pseudonyms, moderator-visible IPs) is directly applicable. However, Wikipedia's anti-vandalism costs are enormous — Deliberus would need the structured nature of argumentation (claims must connect logically) as a natural quality filter.\n\n### Pattern 3: External Identity Delegation (Pol.is xid model)\n**How it works**: The platform doesn't handle auth at all. The embedding organization passes an external user ID. The platform trusts the embedder's identity system.\n\n**Why it works for deliberation**: When Deliberus is embedded in existing institutions (universities, governments, organizations), those institutions already have identity systems. Don't make users create yet another account.\n\n**Deliberus relevance**: MEDIUM-HIGH for institutional deployments. An `xid`-like system would let universities embed Deliberus and pass student IDs, or governments embed it and use national ID systems, without Deliberus needing to know about any of them.\n\n### Pattern 4: Own Your Identity Namespace (Hypothesis model)\n**How it works**: The platform is its own OAuth2 provider. Third-party tools authenticate through platform accounts. No dependency on Google/Facebook.\n\n**Why it works for deliberation**: If Deliberus identities carry reputation (argument quality scores, trust levels), those identities become valuable. Owning the identity namespace means the reputation system isn't dependent on third-party account survival.\n\n**Deliberus relevance**: MEDIUM for long-term vision. Initially overkill. But if Deliberus accounts carry cross-platform reputation for argument quality, owning the identity system becomes strategic.\n\n---\n\n## The Anonymity-Accountability Spectrum for Deliberation\n\n### Academic Research: Moore (2018) — \"Anonymity, Pseudonymity, and Deliberation: Why Not Everything Should Be Connected\"\n\nKey findings from Alfred Moore's influential paper:\n- **Full anonymity** enables expression of unpopular views but degrades accountability\n- **Pseudonymity** is the sweet spot for deliberation — consistent identity enables reputation without real-world consequences\n- **Real-name requirements** reduce participation and bias toward socially dominant views\n- The value of anonymity is *context-dependent*: anonymous voting on claims is fine; anonymous moderation is not\n\n### Tiered Anonymity (2026 research, arXiv:2506.12814)\n\nRecent research proposes tiered anonymity as a countermeasure against misinformation:\n- **Tier 0**: Fully anonymous (reading, browsing)\n- **Tier 1**: Pseudonymous (consistent identity, can build reputation)\n- **Tier 2**: Verified pseudonymous (identity verified by platform, displayed as pseudonym)\n- **Tier 3**: Verified identified (real name displayed)\n\nDifferent actions require different tiers. This maps naturally to deliberation:\n- Reading/browsing: Tier 0\n- Voting on claims: Tier 1 (pseudonymous, prevents ballot stuffing)\n- Submitting claims: Tier 1-2 (reputation trackable)\n- Moderation/curation: Tier 2-3 (accountability for power)\n\n---\n\n## Recommended Approach for Deliberus\n\nBased on this research, a **tiered pseudonymous model** best serves the \"Wikipedia for argumentation\" vision:\n\n### Phase 1 (MVP — current):\n- **Email + password** (own auth, simple)\n- **Google OAuth** (covers ~70% of social login demand)\n- **GitHub OAuth** (covers technical early adopters)\n- Anonymous reading of all public content\n\n### Phase 2 (Community growth):\n- **Temporary pseudonymous accounts** (Wikipedia-style, cookie-based, 90-day rotation) for anonymous claim submission and voting\n- Progressive trust levels (Discourse-style) for registered accounts\n- OpenID Connect support for institutional deployments\n\n### Phase 3 (Scale):\n- External identity delegation (`xid` pattern) for embedded institutional use\n- Reputation portability (Deliberus as OAuth provider, Hypothesis-style)\n- Verified identity tier for high-trust roles (moderators, domain experts)\n\n### Key Principles:\n1. **Arguments, not identities, are the primary unit of trust.** A well-structured argument from a pseudonymous account is worth more than a bare assertion from a verified professor. The argumentation structure itself is the quality filter.\n2. **Pseudonymity is the default.** Display names, not real names. Consistent enough to build reputation, private enough to encourage honest engagement on controversial topics.\n3. **Accountability scales with power.** Reading: anonymous. Voting: pseudonymous. Submitting claims: pseudonymous with reputation. Moderation: verified. This follows Moore's principle that anonymity's value is context-dependent.\n4. **Don't build what you can delegate.** Use Google/GitHub OAuth for Phase 1. Add OIDC for Phase 2. Only build custom identity infrastructure (Phase 3) if Deliberus accounts carry enough value to justify it.\n5. **The structured nature of argumentation is the anti-vandalism system.** Wikipedia needs massive bot armies because free-text vandalism is easy. In a structured argumentation graph, low-quality contributions are structurally visible (disconnected claims, missing premises, circular reasoning). The ontology does the work that vandalism detection does for Wikipedia.\n\n### Technical Implementation Notes (for when auth is built):\n- **FastAPI + Python**: Consider `authlib` (OAuth2/OIDC client and server), or `python-social-auth` (Django/Flask/FastAPI, 40+ providers)\n- **SvelteKit frontend**: `@auth/sveltekit` (Auth.js/NextAuth for Svelte, supports Google/GitHub/email/credentials)\n- **Session management**: JWT tokens for API, httpOnly cookies for web\n- **For Phase 1 simplicity**: Auth.js handles Google + GitHub + email with minimal code. The SvelteKit adapter is well-maintained.\n\n---\n\n## Sources\n\n- Kialo account creation: https://support.kialo-edu.com/en/hc/creating-an-account/\n- Pol.is auth discussion: https://github.com/compdemocracy/polis/issues/97\n- Pol.is OIDC issue: https://github.com/compdemocracy/polis/issues/1750\n- Loomio third-party logins: https://www.loomio.com/d/4KcnoDtT/third-party-logins\n- Loomio SAML SSO: https://www.loomio.com/d/CL8Xr5kW/is-sso-compatible-with-selfhosted-loomio\n- Discourse SSO guide: https://blog.elest.io/discourse-sso-implement-single-sign-on-with-oauth2-and-oidc/\n- Wikipedia temporary accounts: https://diff.wikimedia.org/2024/11/05/say-hi-to-temporary-accounts-easier-collaboration-with-logged-out-editors-with-better-privacy-protection/\n- LessWrong login page: https://www.lesswrong.com/login\n- ForumMagnum repo: https://github.com/ForumMagnum/ForumMagnum\n- Hypothesis OAuth docs: https://h.readthedocs.io/en/latest/api/using-oauth/\n- Hypothesis pyramid-googleauth: https://github.com/hypothesis/pyramid-googleauth\n- Moore (2018), \"Anonymity, Pseudonymity, and Deliberation\": https://gwern.net/doc/sociology/technology/2018-moore.pdf\n- Tiered Anonymity research (2026): https://arxiv.org/html/2506.12814v2\n"}