Phil Skentelbery
dd822a35b5
Complete implementation of v1.2.0 "IndieWeb Features" release. ## Phase 1: Custom Slugs - Optional custom slug field in note creation form - Auto-sanitization (lowercase, hyphens only) - Uniqueness validation with auto-numbering - Read-only after creation to preserve permalinks - Matches Micropub mp-slug behavior ## Phase 2: Author Discovery + Microformats2 - Automatic h-card discovery from IndieAuth identity URL - 24-hour caching with graceful fallback - Never blocks login (per ADR-061) - Complete h-entry, h-card, h-feed markup - All required Microformats2 properties - rel-me links for identity verification - Passes IndieWeb validation ## Phase 3: Media Upload - Upload up to 4 images per note (JPEG, PNG, GIF, WebP) - Automatic optimization with Pillow - Auto-resize to 2048px - EXIF orientation correction - 95% quality compression - Social media-style layout (media top, text below) - Optional captions for accessibility - Integration with all feed formats (RSS, ATOM, JSON Feed) - Date-organized storage with UUID filenames - Immutable caching (1 year) ## Database Changes - migrations/006_add_author_profile.sql - Author discovery cache - migrations/007_add_media_support.sql - Media storage ## New Modules - starpunk/author_discovery.py - h-card discovery and caching - starpunk/media.py - Image upload, validation, optimization ## Documentation - 4 new ADRs (056, 057, 058, 061) - Complete design specifications - Developer Q&A with 40+ questions answered - 3 implementation reports - 3 architect reviews (all approved) ## Testing - 56 new tests for v1.2.0 features - 842 total tests in suite - All v1.2.0 feature tests passing ## Dependencies - Added: mf2py (Microformats2 parser) - Added: Pillow (image processing) Version: 1.2.0-rc.1 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
3.8 KiB
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:
- Assume an external IndieAuth provider
- Never include hooks or abstractions for self-hosting
- Document indielogin.com as the recommended provider
- 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.