Set up Beads dependency-aware issue tracker to provide persistent
memory and task tracking across agent sessions. Issues will use
prefix 'Coves-1, Coves-2, etc.' and sync via JSONL in git.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Update project guidelines and best practices.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Add complete Docker configuration for containerized deployment.

Files added:
- Dockerfile: Multi-stage Python 3.11 image with cron scheduler
- docker-compose.yml: Simple deployment configuration
- docker-entrypoint.sh: Startup script with validation
- .dockerignore: Build optimization

Features:
- Automated cron scheduling (daily at 1 PM UTC)
- Health checks (verifies cron is running)
- Log rotation (10MB max, 3 files)
- Auto-restart on failure
- Environment-based configuration
- Single command deployment: docker compose up -d

The container runs cron internally and streams logs to stdout,
making it production-ready and easy to monitor.

Updated README with comprehensive Docker deployment documentation
including quick start, configuration, testing, and production
deployment best practices.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Add Kagi-specific automated registration script and update README.

Changes:
- Move setup-kagi-aggregator.sh to kagi-news/scripts/setup.sh
- Add comprehensive Registration section to README
- Document automated vs manual setup options
- Explain registration workflow and requirements
- Update project structure to reflect new scripts

The setup script automates all 4 registration steps:
1. PDS account creation
2. .well-known file generation
3. Coves registration via XRPC
4. Service declaration creation

This makes the Kagi aggregator self-contained and ready to be
split into its own repository.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Add comprehensive setup scripts and documentation for aggregator registration.

Scripts:
- 1-create-pds-account.sh: Create PDS account for aggregator
- 2-setup-wellknown.sh: Generate .well-known/atproto-did file
- 3-register-with-coves.sh: Register with Coves instance via XRPC
- 4-create-service-declaration.sh: Create service declaration record

Documentation:
- Detailed README with step-by-step instructions
- Troubleshooting guide
- Configuration examples (nginx/Apache)
- Security best practices

These scripts automate the 4-step process of:
1. Creating a DID for the aggregator
2. Proving domain ownership
3. Registering with Coves
4. Publishing service metadata

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Implement social.coves.aggregator.register endpoint for aggregator registration.

Features:
- Lexicon schema for registration request/response
- Domain verification via .well-known/atproto-did
- DID resolution and validation
- User table insertion for aggregators
- Comprehensive integration tests

The endpoint allows aggregators to register with a Coves instance by:
1. Providing their DID and domain
2. Verifying domain ownership via .well-known file
3. Getting indexed into the users table

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Implements mandatory bidirectional did:web verification matching Bluesky's
security model. This prevents domain impersonation attacks by requiring
DID documents to claim the handle domain in their alsoKnownAs field.

Security Improvements:
- MANDATORY bidirectional verification (hard-fail, not soft-fail)
- Verifies domain matching (handle domain == hostedBy domain)
- Fetches DID document from https://domain/.well-known/did.json
- Verifies DID document ID matches claimed DID
- NEW: Verifies DID document claims handle in alsoKnownAs field
- Rejects communities that fail verification (was: log warning only)
- Cache TTL increased from 1h to 24h (matches Bluesky recommendations)

Implementation:
- Location: internal/atproto/jetstream/community_consumer.go
- Verification runs in AppView Jetstream consumer (not creation API)
- Impact: Controls AppView indexing and federation trust
- Performance: Bounded LRU cache (1000 entries), rate limiting (10 req/s)

Attack Prevention:
✓ Domain impersonation (can't claim did:web:nintendo.com without owning it)
✓ DNS hijacking (bidirectional check fails even with DNS control)
✓ Reputation hijacking (can't point your domain to someone else's DID)
✓ AppView pollution (only legitimate communities indexed)
✓ Federation trust (other instances can verify instance identity)

Tests:
- Updated existing tests to handle mandatory verification
- Added comprehensive bidirectional verification tests with mock HTTP server
- All tests passing ✅

Documentation:
- PRD_BACKLOG.md: Marked did:web verification as COMPLETE
- PRD_ALPHA_GO_LIVE.md: Added production deployment requirements
- Clarified architecture: AppView (coves.social) + PDS (coves.me)
- Added PDS deployment checklist (separate domain required)
- Updated production environment checklist
- Added Jetstream configuration (Bluesky production firehose)

Production Requirements:
- Deploy .well-known/did.json to coves.social with alsoKnownAs field
- Set SKIP_DID_WEB_VERIFICATION=false (production)
- PDS must be on separate domain (coves.me, not coves.social)
- Jetstream connects to wss://jetstream2.us-east.bsky.network/subscribe

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Added comprehensive PRD for implementing Lemmy-style federation in Beta:

**Overview:**
- Enable users on any Coves instance to post to communities on other instances
- Maintain community ownership (posts live in community repos)
- Use atProto-native service authentication pattern

**Key Features:**
- Cross-instance posting: user@instance-a posts to !community@instance-b
- atProto service auth via com.atproto.server.getServiceAuth
- Community moderation control maintained
- Allowlist-based federation (manual for Beta)

**Technical Approach:**
- Service-to-service JWT authentication
- Community credentials delegation to user's instance
- Proper record ownership in community repos
- Security: signature verification, rate limiting, moderation

**Deferred to Future:**
- Automatic instance discovery (Beta uses manual allowlist)
- Cross-instance moderation delegation
- Content mirroring/replication
- User migration between instances

**Target:** Beta Release

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>