Architecting Account Integrity: The Dual Authentication Design of Artemis

{{IMAGE:1}}

Authentication systems represent the gatekeepers of digital experiences, yet their implementation often reveals philosophical tensions between user autonomy and system security. Artemis, an open-source web reader, presents a compelling case study in balancing these concerns through its tripartite authentication approach supporting IndieAuth, email/password, and passkeys. This architectural examination reveals how services can maintain account integrity while honoring the IndieWeb principle of domain ownership.

The Authentication Trinity

Artemis's login screen presents users with three distinct pathways:

1. IndieAuth: Using domain-based identities (formally User Profile URLs per the IndieAuth specification)
2. Email/Password: Traditional credential-based authentication
3. Passkeys: Passwordless future-facing authentication

The coexistence of these methods introduces unique design constraints. As creator James explains: "An account MUST have either a verified email address or domain name, and MUST NOT be left in an authentication vacuum." This foundational principle prevents the catastrophic scenario where users lose access through misconfigured credentials.

Core Structural Premises

Artemis enforces several invariants within its account system:

• Accounts may possess either email/password credentials, a domain identity, or both
• All accounts must maintain at least one verified authentication method
• Email addresses and domain names exhibit uniqueness constraints across accounts
• Domain names undergo strict canonicalization per IndieAuth specification rules

The verification requirement proves particularly crucial. As James notes: "I've emboldened 'verified' because users shouldn't detach a domain name without confirmed access to their email." This prevents scenarios where users might inadvertently orphan their accounts.

State Transition Mechanics

The system's elegance emerges in its state-dependent capabilities:

Email-Only Accounts

• Awareness of current authentication method
• Ability to change email address
• Capacity to add domain identity

Domain-Only Accounts

• Explicit notification of authentication method
• Option to add email credentials
• Domain modification functionality (forthcoming)

Dual-Method Accounts

• Clear indication of combined authentication
• Email modification or removal (when domain exists)
• Domain removal contingent on verified email
• Domain modification (forthcoming)

These workflows manifest in Artemis's interface through explicit status indicators showing active authentication methods—a deliberate transparency measure acknowledging that identity representation extends beyond technical implementation into user cognition.

Edge Case Resolution

Two notable edge cases receive special attention:

1. Domain Entry UX: Artemis implements Aaron Parecki's URL field enhancements to automatically prefix domain entries with http://, smoothing user experience while maintaining server-side validation.

2. Email Retrieval via IndieAuth: For domain-authenticated users lacking email, Artemis leverages the IndieAuth profile scope to potentially retrieve addresses. As James details: "After authentication, Artemis could ask if they want to add the email sent in the profile payload," followed by verification workflows. This exemplifies the specification's underutilized potential for progressive enhancement.

Passkeys as Complementary Actors

While passkeys exist within Artemis's ecosystem, they function as supplementary rather than primary credentials. James clarifies: "Passkey registration isn't supported... users can never get in a state where removing a passkey means they lack authentication." This intentional limitation preserves the core authentication duality.

Philosophical Implications

This architecture embodies deeper digital identity principles:

• User Sovereignty: Domain-based authentication actualizes the IndieWeb vision of personal digital territories
• Fail-Safe Design: The verified-method requirement acknowledges authentication as a fallible human process
• Progressive Enhancement: Optional email retrieval demonstrates how specifications can evolve beyond core functionality

The system does reveal limitations—domain modification remains unimplemented, and passkey integration remains deliberately constrained. Yet these represent conscious tradeoffs favoring system integrity over feature completeness.

As authentication ecosystems grow increasingly complex, Artemis demonstrates how thoughtful constraint creates robust user experiences. Its dual-channel approach offers a template for services seeking to bridge traditional and decentralized authentication paradigms while maintaining ironclad account recoverability—a philosophical stance where user autonomy and system reliability coexist through deliberate design.