# ADR-056: Use External IndieAuth Provider (Never Self-Host)

## Status
**ACCEPTED** - This is a permanent, non-negotiable decision.

## Context
StarPunk is a minimal IndieWeb CMS focused on **content creation and syndication**, not identity infrastructure. The project philosophy demands that every line of code must justify its existence.

The question of whether to implement self-hosted IndieAuth has been raised multiple times. This ADR documents the final, permanent decision on this matter.

## Decision
**StarPunk will NEVER implement self-hosted IndieAuth.**

We will always rely on external IndieAuth providers such as:
- indielogin.com (primary recommendation)
- Other established IndieAuth providers

This decision is **permanent and non-negotiable**.

## Rationale

### 1. Project Focus
StarPunk's mission is to be a minimal CMS for publishing IndieWeb content. Our core competencies are:
- Publishing notes with proper microformats
- Generating RSS/Atom/JSON feeds
- Implementing Micropub for content creation
- Media management for content

Identity infrastructure is explicitly **NOT** our focus.

### 2. Complexity vs Value
Implementing IndieAuth would require:
- OAuth 2.0 implementation
- Token management
- Security considerations
- Key storage and rotation
- User profile management
- Authorization code flows

This represents hundreds or thousands of lines of code that don't serve our core mission of content publishing.

### 3. Existing Solutions Work
External IndieAuth providers like indielogin.com:
- Are battle-tested
- Handle security updates
- Support multiple authentication methods
- Are free to use
- Align with IndieWeb principles of building on existing infrastructure

### 4. Philosophy Alignment
Our core philosophy states: "Every line of code must justify its existence. When in doubt, leave it out."

Self-hosted IndieAuth cannot justify its existence in a minimal content-focused CMS.

## Consequences

### Positive
- Dramatically reduced codebase complexity
- No security burden for identity management
- Faster development of content features
- Clear project boundaries
- User authentication "just works" via proven providers

### Negative
- Dependency on external service (indielogin.com)
- Cannot function without internet connection to auth provider
- No control over authentication user experience

### Mitigations
- Document clear setup instructions for using indielogin.com
- Support multiple external providers for redundancy
- Cache authentication tokens appropriately

## Alternatives Considered

### 1. Self-Hosted IndieAuth (REJECTED)
**Why considered:** Full control over authentication
**Why rejected:** Massive scope creep, violates project philosophy

### 2. No Authentication (REJECTED)
**Why considered:** Ultimate simplicity
**Why rejected:** Single-user system still needs access control

### 3. Basic Auth or Simple Password (REJECTED)
**Why considered:** Very simple to implement
**Why rejected:** Not IndieWeb compliant, poor user experience

### 4. Hybrid Approach (REJECTED)
**Why considered:** Optional self-hosted with external fallback
**Why rejected:** Maintains complexity we're trying to avoid

## Implementation Notes

All authentication code should:
1. Assume an external IndieAuth provider
2. Never include hooks or abstractions for self-hosting
3. Document indielogin.com as the recommended provider
4. Include clear error messages when auth provider is unavailable

## References
- Project Philosophy: "Every line of code must justify its existence"
- IndieAuth Specification: https://indieauth.spec.indieweb.org/
- indielogin.com: https://indielogin.com/

## Final Note
This decision has been made after extensive consideration and multiple discussions. It is final.

**Do not propose self-hosted IndieAuth in future architectural discussions.**

The goal of StarPunk is **content**, not **identity**.