mirrors/at-container-registry
1
0
Fork 0
mirror of https://tangled.org/evan.jarrett.net/at-container-registry synced 2026-08-29 04:06:58 +00:00
Code Issues Packages Projects Releases Wiki Activity

remove distribution from hold, add vulnerability scanning in appview.

Browse Source 
1. Removing distribution/distribution from the Hold Service (biggest change)
  The hold service previously used distribution's StorageDriver interface for all blob operations. This replaces it with direct AWS SDK v2 calls through ATCR's own pkg/s3.S3Service:
  - New S3Service methods: Stat(), PutBytes(), Move(), Delete(), WalkBlobs(), ListPrefix() added to pkg/s3/types.go
  - Pull zone fix: Presigned URLs are now generated against the real S3 endpoint, then the host is swapped to the CDN URL post-signing (previously the CDN URL was set as the endpoint, which
  broke SigV4 signatures)
  - All hold subsystems migrated: GC, OCI uploads, XRPC handlers, profile uploads, scan broadcaster, manifest posts — all now use *s3.S3Service instead of storagedriver.StorageDriver
  - Config simplified: Removed configuration.Storage type and buildStorageConfigFromFields(); replaced with a simple S3Params() method
  - Mock expanded: MockS3Client gains an in-memory object store + 5 new methods, replacing duplicate mockStorageDriver implementations in tests (~160 lines deleted from each test file)
2. Vulnerability Scan UI in AppView (new feature)
  Displays scan results from the hold's PDS on the repository page:
  - New lexicon: io/atcr/hold/scan.json with vulnReportBlob field for storing full Grype reports
  - Two new HTMX endpoints: /api/scan-result (badge) and /api/vuln-details (modal with CVE table)
  - New templates: vuln-badge.html (severity count chips) and vuln-details.html (full CVE table with NVD/GHSA links)
  - Repository page: Lazy-loads scan badges per manifest via HTMX
  - Tests: ~590 lines of test coverage for both handlers
3. S3 Diagnostic Tool
  New cmd/s3-test/main.go (418 lines) — tests S3 connectivity with both SDK v1 and v2, including presigned URL generation, pull zone host swapping, and verbose signing debug output.
4. Deployment Tooling
  - New syncServiceUnit() for comparing/updating systemd units on servers
  - Update command now syncs config keys (adds missing keys from template) and service units with daemon-reload
5. DB Migration
  0011_fix_captain_successor_column.yaml — rebuilds hold_captain_records to add the successor column that was missed in a previous migration.
6. Documentation
  - APPVIEW-UI-FUTURE.md rewritten as a status-tracked feature inventory
  - DISTRIBUTION.md renamed to CREDENTIAL_HELPER.md
  - New REMOVING_DISTRIBUTION.md — 480-line analysis of fully removing distribution from the appview side
7. go.mod
  aws-sdk-go v1 moved from indirect to direct (needed by cmd/s3-test).
This commit is contained in:
Evan Jarrett
2026-02-13 15:26:24 -06:00
parent 434a5f1eee
commit de02e1f046
38 changed files with 3134 additions and 962 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/APPVIEW-UI-FUTURE.md
+305 -462
View File
@@ -1,23 +1,51 @@
# ATCR AppView UI - Future Features
# ATCR UI - Feature Roadmap
This document outlines potential features for future versions of the ATCR AppView UI, beyond the V1 MVP. These are ideas to consider as the project matures and user needs evolve.
This document tracks the status of ATCR features beyond the V1 MVP. Features are marked with their current status:
- **DONE** — Fully implemented and shipping
- **PARTIAL** — Some parts implemented
- **BACKEND ONLY** — Backend exists, no UI yet
- **NOT STARTED** — Future work
- **BLOCKED** — Waiting on external dependency
---
## What's Already Built (not in original roadmap)
These features were implemented but weren't in the original future features list:
| Feature | Location | Notes |
|---------|----------|-------|
| **Billing (Stripe)** | `pkg/hold/billing/` | Checkout sessions, customer portal, subscription webhooks, tier upgrades. Build with `-tags billing`. |
| **Garbage collection** | `pkg/hold/gc/` | Mark-and-sweep for orphaned blobs. Preview (dry-run) and execute modes. Triggered from hold admin UI. |
| **libSQL embedded replicas** | AppView + Hold | Sync to Turso, Bunny DB, or self-hosted libsql-server. Configurable sync interval. |
| **Hold successor/migration** | `pkg/hold/` | Promote a hold as successor to migrate users to new storage. |
| **Relay management** | Hold admin | Manage firehose relay connections from admin panel. |
| **Data export** | `pkg/appview/handlers/export.go` | GDPR-compliant export of all user data from AppView + all holds where user is member/captain. |
| **Dark/light mode** | AppView UI | System preference detection, toggle, localStorage persistence. |
| **Credential helper install page** | `/install` | Install scripts for macOS/Linux/Windows, version API. |
| **Stars** | AppView UI | Star/unstar repos stored as `io.atcr.star` ATProto records, counts displayed. |
---
## Advanced Image Management
### Multi-Architecture Image Support
### Multi-Architecture Image Support — DONE (display) / NOT STARTED (creation)
**Display image indexes:**
- Show when a tag points to an image index (multi-arch manifest)
- Display all architectures/platforms in the index (linux/amd64, linux/arm64, darwin/arm64, etc.)
**Display image indexes — DONE:**
- Show when a tag points to an image index (multi-arch manifest) — `IsMultiArch` flag, "Multi-arch" badge
- Display all architectures/platforms in the index — platform badges (e.g., linux/amd64, linux/arm64)
- Allow viewing individual manifests within the index
- Show platform-specific layer details
- Show platform-specific details
**Image index creation:**
**Image index creation — NOT STARTED:**
- UI for combining multiple single-arch manifests into an image index
- Automatic platform detection from manifest metadata
- Validate that all manifests are for the same image (different platforms)
### Layer Inspection & Visualization
### Layer Inspection & Visualization — NOT STARTED
DB stores layer metadata (digest, size, media type, layer index) but there's no UI for any of this.
**Layer details page:**
- Show Dockerfile command that created each layer (if available in history)
@@ -30,594 +58,409 @@ This document outlines potential features for future versions of the ATCR AppVie
- Calculate storage savings from layer sharing
- Identify duplicate layers with different digests (potential optimization)
### Image Operations
### Image Operations — PARTIAL (delete only)
**Tag Management:**
- **Tag promotion workflow:** dev → staging → prod with one click
- **Tag aliases:** Create multiple tags pointing to same digest
- **Tag patterns:** Auto-tag based on git commit, semantic version, date
- **Tag protection:** Mark tags as immutable (prevent deletion/re-pointing)
**Tag/manifest deletion — DONE:**
- Delete tags with `DeleteTagHandler` (cascade + confirmation modal)
- Delete manifests with `DeleteManifestHandler` (handles tagged manifests gracefully)
**Image Copying:**
**Tag Management — NOT STARTED:**
- Tag promotion workflow (dev → staging → prod)
- Tag aliases (multiple tags → same digest)
- Tag patterns (auto-tag based on git commit, semantic version, date)
- Tag protection (mark tags as immutable)
**Image Copying — NOT STARTED:**
- Copy image from one repository to another
- Copy image from another user's repository (fork)
- Bulk copy operations (copy all tags, copy all manifests)
- Bulk copy operations
**Image History:**
- Timeline view of tag changes (what digest did "latest" point to over time)
- Rollback functionality (revert tag to previous digest)
- Audit log of all image operations (push, delete, tag changes)
**Image History — NOT STARTED:**
- Timeline view of tag changes
- Rollback functionality
- Audit log of image operations
### Vulnerability Scanning
### Vulnerability Scanning — DONE (backend) / NOT STARTED (UI)
**Integration with security scanners:**
- **Trivy** - Comprehensive vulnerability scanner
- **Grype** - Anchore's vulnerability scanner
- **Clair** - CoreOS vulnerability scanner
**Backend — DONE:**
- Separate scanner service (`scanner/` module) with Syft (SBOM) + Grype (vulnerabilities)
- WebSocket-based job queue connecting scanner to hold service
- Priority queue with tier-based scheduling (quartermaster > bosun > deckhand)
- Scan results stored as ORAS artifacts in S3, referenced in hold PDS
- Automatic scanning dispatched by hold on manifest push
- See `docs/SBOM_SCANNING.md`
**Features:**
- Automatic scanning on image push
**AppView UI — NOT STARTED:**
- Display CVE count by severity (critical, high, medium, low)
- Show detailed CVE information (description, CVSS score, affected packages)
- Filter images by vulnerability status
- Subscribe to CVE notifications for your images
- Compare vulnerability status across tags/versions
### Image Signing & Verification
### Image Signing & Verification — NOT STARTED
**Cosign/Sigstore integration:**
- Sign images with Cosign
Concept doc exists at `docs/SIGNATURE_INTEGRATION.md` but no implementation.
- Sign images
- Display signature verification status
- Show keyless signing certificate chains
- Integrate with transparency log (Rekor)
**Features:**
- UI for signing images (generate key, sign manifest)
- Verify signatures before pull (browser-based verification)
- Display signature metadata (signer, timestamp, transparency log entry)
- Display signature metadata
- Require signatures for protected repositories
### SBOM (Software Bill of Materials)
### SBOM (Software Bill of Materials) — DONE (backend) / NOT STARTED (UI)
**SBOM generation and display:**
- Generate SBOM on push (SPDX or CycloneDX format)
**Backend — DONE:**
- Syft generates SPDX JSON format SBOMs
- Stored as ORAS artifacts (referenced via `artifactType: "application/spdx+json"`)
- Blobs in S3, metadata in hold's PDS
- Accessible via ORAS CLI and hold XRPC endpoints
**UI — NOT STARTED:**
- Display package list from SBOM
- Show license information
- Link to upstream package sources
- Compare SBOMs across versions (what packages changed)
- Compare SBOMs across versions
**SBOM attestation:**
- Store SBOM as attestation (in-toto format)
- Link SBOM to image signature
- Verify SBOM integrity
---
## Hold Management Dashboard
## Hold Management Dashboard — DONE (on hold admin panel)
### Hold Discovery & Registration
Hold management is implemented as a separate admin panel on the hold service itself (`pkg/hold/admin/`), not in the AppView UI. This makes sense architecturally — hold owners manage their own holds.
**Create hold:**
### Hold Discovery & Registration — PARTIAL
**Hold registration — DONE:**
- Automatic registration on hold startup (captain + crew records created in embedded PDS)
- Auto-detection of region from cloud metadata
**NOT STARTED:**
- UI wizard for deploying hold service
- One-click deployment to Fly.io, Railway, Render
- Configuration generator (environment variables, docker-compose)
- Test connectivity after deployment
- One-click deployment to cloud platforms
- Configuration generator
- Test connectivity UI
**Hold registration:**
- Automatic registration via OAuth (already implemented)
- Manual registration form (for existing holds)
- Bulk import holds from JSON/YAML
### Hold Configuration — DONE (admin panel)
### Hold Configuration
**Hold settings page:**
- Edit hold metadata (name, description, icon)
**Hold settings — DONE (hold admin):**
- Toggle public/private flag
- Configure storage backend (S3, Storj, Minio, filesystem)
- Set storage quotas and limits
- Configure retention policies (auto-delete old blobs)
- Toggle allow-all-crew
- Toggle Bluesky post announcements
- Set successor hold DID for migration
- Writes changes back to YAML config file
**Hold credentials:**
- Rotate S3 access keys
- Test hold connectivity
- View hold service logs (if accessible)
**Storage config — YAML-only:**
- S3 credentials, region, bucket, endpoint, CDN pull zone all configured via YAML
- No UI for editing S3 credentials or rotating keys
### Crew Management
**Quotas — DONE (read-only UI):**
- Tier-based limits (deckhand 5GB, bosun 50GB, quartermaster 100GB)
- Per-user quota tracking and display in admin
- Not editable via UI (requires YAML change)
**Invite crew members:**
- Send invitation links (OAuth-based)
- Invite by handle or DID
- Set crew permissions (read-only, read-write, admin)
- Bulk invite (upload CSV)
**NOT STARTED:**
- Retention policies (auto-delete old blobs)
- Hold service log viewer
**Crew list:**
- Display all crew members
- Show last activity (last push, last pull)
### Crew Management — DONE (hold admin panel)
**Implemented in `pkg/hold/admin/handlers_crew.go`:**
- Add crew by DID with role, permissions (`blob:read`, `blob:write`, `crew:admin`), and tier
- Crew list showing handle, role, permissions, tier, usage, quota
- Edit crew permissions and tier
- Remove crew members
- Change crew permissions
- Bulk JSON import/export with deduplication (`handlers_crew_io.go`)
**Crew request workflow:**
- Allow users to request access to a hold
- Hold owner approves/rejects requests
- Notification system for requests
**NOT STARTED:**
- Invitation links (OAuth-based, currently must know DID)
- Invite by handle (currently DID-only)
- Crew request workflow (users can't self-request access)
- Approval/rejection flow
### Hold Analytics
### Hold Analytics — PARTIAL
**Storage metrics:**
- Total storage used (bytes)
- Blob count
- Largest blobs
- Growth over time (chart)
- Deduplication savings
**Storage metrics — DONE (hold admin):**
- Total blobs, total size, unique digests
- Per-user quota stats (total size, blob count)
- Top users by storage (lazy-loaded HTMX partial)
- Crew count and tier distribution
**Access metrics:**
- Total downloads (pulls)
- Bandwidth used
- Popular images (most pulled)
- Geographic distribution (if available)
- Access logs (who pulled what, when)
**NOT STARTED:**
- Access metrics (downloads, pulls, bandwidth)
- Growth over time charts
- Cost estimation
- Geographic distribution
- Access logs
**Cost estimation:**
- Calculate S3 storage costs
- Calculate bandwidth costs
- Compare costs across storage backends
- Budget alerts (notify when approaching limit)
---
## Discovery & Social Features
### Federated Browse & Search
### Federated Browse & Search — PARTIAL
**Enhanced discovery:**
- Full-text search across all ATCR images (repository name, tag, description)
**Basic search — DONE:**
- Full-text search across handles, DIDs, repo names, and annotations
- Search UI with HTMX lazy loading and pagination
- Navigation bar search component
**NOT STARTED:**
- Filter by user, hold, architecture, date range
- Sort by popularity, recency, size
- Advanced query syntax (e.g., "user:alice tag:latest arch:arm64")
- Advanced query syntax
- Popular/trending images
- Categories and user-defined tags
**Popular/Trending:**
- Most pulled images (past day, week, month)
- Fastest growing images (new pulls)
- Recently updated images (new tags)
- Community favorites (curated list)
### Sailor Profiles — PARTIAL
**Categories & Tags:**
- User-defined categories (web, database, ml, etc.)
- Tag images with keywords (nginx, proxy, reverse-proxy)
- Browse by category
- Tag cloud visualization
**Public profile page — DONE:**
- `/u/{handle}` shows user's avatar, handle, DID, and all public repositories
- OpenGraph meta tags and JSON-LD structured data
### Sailor Profiles (Public)
**Public profile page:**
- `/ui/@alice` shows alice's public repositories
- Bio, avatar, website links
**NOT STARTED:**
- Bio/description field
- Website links
- Statistics (total images, total pulls, joined date)
- Pinned repositories (showcase best images)
- Pinned/featured repositories
**Social features:**
- Follow other sailors (get notified of their pushes)
- Star repositories (bookmark favorites)
- Comment on images (feedback, questions)
### Social Features — PARTIAL (stars only)
**Stars — DONE:**
- Star/unstar repositories stored as `io.atcr.star` ATProto records
- Star counts displayed on repository pages
**NOT STARTED:**
- Follow other sailors
- Comment on images
- Like/upvote images
- Activity feed
- Federated timeline / custom feeds
- Sharing to Bluesky/ATProto social apps
**Activity feed:**
- Timeline of followed sailors' activity
- Recent pushes from community
- Popular images from followed users
### Federated Timeline
**ATProto-native feed:**
- Real-time feed of container pushes (like Bluesky's timeline)
- Filter by follows, community, or global
- React to pushes (like, share, comment)
- Share images to Bluesky/ATProto social apps
**Custom feeds:**
- Create algorithmic feeds (e.g., "Show me all ML images")
- Subscribe to curated feeds
- Publish feeds for others to subscribe
---
## Access Control & Permissions
### Repository-Level Permissions
### Hold-Level Access Control — DONE
**Private repositories:**
- Mark repositories as private (only owner + collaborators can pull)
- Invite collaborators by handle/DID
- Set permissions (read-only, read-write, admin)
- Public/private hold toggle (admin UI + OCI enforcement)
- Crew permissions: `blob:read`, `blob:write`, `crew:admin`
- `blob:write` implicitly grants `blob:read`
- Captain has all permissions implicitly
- See `docs/BYOS.md`
**Public repositories:**
- Default: public (anyone can pull)
- Require authentication for private repos
- Generate read-only tokens (for CI/CD)
### Repository-Level Permissions — BLOCKED
**Implementation challenge:**
- ATProto doesn't support private records yet
- May require proxy layer for access control
- Or use encrypted blobs with shared keys
- **Private repositories blocked by ATProto** — no private records support yet
- Repository-level permissions, collaborator invites, read-only tokens all depend on this
- May require proxy layer or encrypted blobs when ATProto adds private record support
### Team/Organization Accounts
### Team/Organization Accounts — NOT STARTED
**Multi-user organizations:**
- Create organization account (e.g., `@acme-corp`)
- Add members with roles (owner, maintainer, member)
- Organization-owned repositories
- Billing and quotas at org level
- Organization accounts, RBAC, SSO, audit logs
- Likely a later-stage feature
**Features:**
- Team-based access control
- Shared hold for organization
- Audit logs for all org activity
- Single sign-on (SSO) integration
---
## Analytics & Monitoring
### Dashboard
### Dashboard — PARTIAL
**Personal dashboard:**
**Hold dashboard — DONE (hold admin):**
- Storage usage, crew count, tier distribution
**Personal dashboard — NOT STARTED:**
- Overview of your images, holds, activity
- Quick stats (total size, pull count, last push)
- Recent activity (your pushes, pulls)
- Alerts and notifications
- Quick stats, recent activity, alerts
**Hold dashboard:**
- Storage usage, bandwidth, costs
- Active crew members
- Recent uploads/downloads
- Health status of hold service
### Pull Analytics — NOT STARTED
### Pull Analytics
**Detailed metrics:**
- Pull count per image/tag
- Pull count by client (Docker, containerd, podman)
- Pull count by geography (country, region)
- Pull count over time (chart)
- Failed pulls (errors, retries)
- Pull count by client, geography, over time
- User analytics (authenticated vs anonymous)
**User analytics:**
- Who is pulling your images (if authenticated)
- Anonymous vs authenticated pulls
- Repeat users vs new users
### Alerts & Notifications — NOT STARTED
### Alerts & Notifications
- Alert types (quota exceeded, vulnerability detected, hold down, etc.)
- Notification channels (email, webhook, ATProto, Slack/Discord)
**Alert types:**
- Storage quota exceeded
- High bandwidth usage
- New vulnerability detected
- Image signature invalid
- Hold service down
- Crew member joined/left
**Notification channels:**
- Email
- Webhook (POST to custom URL)
- ATProto app notification (future: in-app notifications in Bluesky)
- Slack, Discord, Telegram integrations
---
## Developer Tools & Integrations
### API Documentation
### Credential Helper — DONE
**Interactive API docs:**
- Swagger/OpenAPI spec for OCI API
- Swagger/OpenAPI spec for UI API
- Interactive API explorer (try API calls in browser)
- Code examples in multiple languages (curl, Go, Python, JavaScript)
- Install page at `/install` with shell scripts
- Version API endpoint for automatic updates
**SDK/Client Libraries:**
- Official Go client library
- JavaScript/TypeScript client
- Python client
- Rust client
### API Documentation — NOT STARTED
### Webhooks
- Swagger/OpenAPI specs
- Interactive API explorer
- Code examples, SDKs
**Webhook configuration:**
- Register webhook URLs per repository
- Select events to trigger (push, delete, tag update)
- Test webhooks (send test payload)
- View webhook delivery history
- Retry failed deliveries
### Webhooks — NOT STARTED
**Webhook events:**
- `manifest.pushed`
- `manifest.deleted`
- `tag.created`
- `tag.updated`
- `tag.deleted`
- `scan.completed` (vulnerability scan finished)
- Repository-level webhook registration
- Events: manifest.pushed, tag.created, scan.completed, etc.
- Test, retry, delivery history
### CI/CD Integration Guides
### CI/CD Integration — NOT STARTED
**Documentation for popular CI/CD platforms:**
- GitHub Actions (example workflows)
- GitLab CI (.gitlab-ci.yml examples)
- CircleCI (config.yml examples)
- Jenkins (Jenkinsfile examples)
- Drone CI
- GitHub Actions, GitLab CI, CircleCI example workflows
- Pre-built actions/plugins
- Build status badges
**Features:**
- One-click workflow generation
- Pre-built actions/plugins for ATCR
- Cache layer optimization for faster builds
- Build status badges (show build status in README)
### Infrastructure as Code — PARTIAL
### Infrastructure as Code
**DONE:**
- Custom UpCloud deployment tool (`deploy/upcloud/`) with Go-based provisioning, cloud-init, systemd, config templates
- Docker Compose for dev and production
**IaC examples:**
- Terraform module for deploying hold service
- Pulumi program for ATCR infrastructure
- Kubernetes manifests for hold service
- Docker Compose for local development
- Helm chart for AppView + hold
**NOT STARTED:**
- Terraform modules
- Helm charts
- Kubernetes manifests (only an example verification webhook exists)
- GitOps integrations (ArgoCD, FluxCD)
**GitOps workflows:**
- ArgoCD integration (deploy images from ATCR)
- FluxCD integration
- Automated deployments on tag push
---
## Documentation & Onboarding
## Documentation & Onboarding — PARTIAL
### Interactive Getting Started
**DONE:**
- Install page with credential helper setup
- Learn more page
- Internal developer docs (`docs/`)
**Onboarding wizard:**
- Step-by-step guide for first-time users
- Interactive tutorial (push your first image)
- Verify setup (test authentication, test push/pull)
- Completion checklist
**Guided tours:**
- Product tour of UI features
- Tooltips and hints for new users
**NOT STARTED:**
- Interactive onboarding wizard
- Product tour / tooltips
- Help center with FAQs
- Video tutorials
- Comprehensive user-facing documentation site
### Comprehensive Documentation
**Documentation sections:**
- Quickstart guide
- Detailed user manual
- API reference
- ATProto record schemas
- Deployment guides (hold service, AppView)
- Troubleshooting guide
- Security best practices
**Video tutorials:**
- YouTube channel with how-to videos
- Screen recordings of common tasks
- Conference talks and demos
### Community & Support
**Community features:**
- Discussion forum (or integrate with Discourse)
- GitHub Discussions for ATCR project
- Discord/Slack community
- Monthly community calls
**Support channels:**
- Email support
- Live chat (for paid tiers)
- Priority support (for enterprise)
---
## Advanced ATProto Integration
### Record Viewer
### Data Export — DONE
**ATProto record browser:**
- Browse all your `io.atcr.*` records
- Raw JSON view with ATProto metadata (CID, commit info, timestamp)
- Diff viewer for record updates
- History view (see all versions of a record)
- Link to ATP URI (`at://did/collection/rkey`)
- GDPR-compliant data export (`ExportUserDataHandler`)
- Fetches data from AppView DB + all holds where user is member/captain
**Export/Import:**
- Export all records as JSON (backup)
- Import records from JSON (restore, migration)
- CAR file export (ATProto native format)
### Record Viewer — NOT STARTED
### PDS Integration
- Browse `io.atcr.*` records with raw JSON view
- Record history, diff viewer
- ATP URI links
**Multi-PDS support:**
- Switch between multiple PDS accounts
- Manage images across different PDSs
- Unified view of all your images (across PDSs)
### PDS Integration — NOT STARTED
**PDS health monitoring:**
- Show PDS connection status
- Alert if PDS is unreachable
- Fallback to alternate PDS (if configured)
- Multi-PDS support, PDS health monitoring
- PDS migration tools
- "Verify on PDS" button
**PDS migration tools:**
- Migrate images from one PDS to another
- Bulk update hold endpoints
- Re-sign OAuth tokens for new PDS
### Federation — NOT STARTED
### Decentralization Features
- Cross-AppView image pulls
- AppView discovery
- Federated search
**Data sovereignty:**
- "Verify on PDS" button (proves manifest is in your PDS)
- "Clone my registry" guide (backup to another PDS)
- "Export registry" (download all manifests + metadata)
**Federation:**
- Cross-AppView image pulls (pull from other ATCR AppViews)
- AppView discovery (find other ATCR instances)
- Federated search (search across multiple AppViews)
## Enterprise Features (Future Commercial Offering)
### Team Collaboration
**Organizations:**
- Enterprise org accounts with unlimited members
- RBAC (role-based access control)
- SSO integration (SAML, OIDC)
- Audit logs for compliance
### Compliance & Security
**Compliance tools:**
- SOC 2 compliance reporting
- HIPAA-compliant storage options
- GDPR data export/deletion
- Retention policies (auto-delete after N days)
**Security features:**
- Image scanning with policy enforcement (block vulnerable images)
- Malware scanning (scan blobs for malware)
- Secrets scanning (detect leaked credentials in layers)
- Content trust (require signed images)
### SLA & Support
**Paid tiers:**
- Free tier: 5GB storage, community support
- Pro tier: 100GB storage, email support, SLA
- Enterprise tier: Unlimited storage, priority support, dedicated instance
**Features:**
- Guaranteed uptime (99.9%)
- Premium support (24/7, faster response)
- Dedicated account manager
- Custom contract terms
---
## UI/UX Enhancements
### Design System
### Theming — PARTIAL
**Theming:**
- Light and dark modes (system preference)
- Custom themes (nautical, cyberpunk, minimalist)
- Accessibility (WCAG 2.1 AA compliance)
**DONE:**
- Light/dark mode with system preference detection and toggle
- Responsive design (Tailwind/DaisyUI, mobile-friendly)
- PWA manifest with icons (no service worker yet)
**NOT STARTED:**
- Custom themes
- WCAG 2.1 AA accessibility audit
- High contrast mode
- Internationalization (i18n)
- Native mobile apps
**Responsive design:**
- Mobile-first design
- Progressive web app (PWA) with offline support
- Native mobile apps (iOS, Android)
### Performance — PARTIAL
### Performance Optimizations
**DONE:**
- HTMX lazy loading for data-heavy partials
- Efficient server-side rendering
**Frontend optimizations:**
- Lazy loading for images and data
**NOT STARTED:**
- Service worker for offline caching
- Virtual scrolling for large lists
- Service worker for caching
- Code splitting (load only what's needed)
- GraphQL API
- Real-time WebSocket updates in UI
**Backend optimizations:**
- GraphQL API (fetch only required fields)
- Real-time updates via WebSocket
- Server-sent events for firehose
- Edge caching (CloudFlare, Fastly)
---
### Internationalization
## Enterprise Features — NOT STARTED (except billing)
**Multi-language support:**
- UI translations (English, Spanish, French, German, Japanese, Chinese, etc.)
- RTL (right-to-left) language support
- Localized date/time formats
- Locale-specific formatting (numbers, currencies)
### Billing — DONE
## Miscellaneous Ideas
- Stripe integration (`pkg/hold/billing/`, requires `-tags billing` build tag)
- Checkout sessions, customer portal, subscription webhooks
- Tier upgrades/downgrades
### Image Build Service
### Everything Else — NOT STARTED
**Cloud-based builds:**
- Build images from Dockerfile in the UI
- Multi-stage build support
- Build cache optimization
- Build logs and status
- Organization accounts with SSO (SAML, OIDC)
- RBAC, audit logs for compliance
- SOC 2, HIPAA, GDPR compliance tooling (data export exists, see above)
- Image scanning policy enforcement
- Paid tier SLAs
**Automated builds:**
- Connect GitHub/GitLab repository
- Auto-build on git push
- Build matrix (multiple architectures, versions)
- Build notifications
---
### Image Registry Mirroring
## Miscellaneous Ideas — NOT STARTED
**Mirror external registries:**
- Cache images from Docker Hub, ghcr.io, quay.io
- Transparent proxy (pull-through cache)
- Reduce external bandwidth costs
- Faster pulls (cache locally)
These remain future ideas with no implementation:
**Features:**
- Configurable cache retention
- Whitelist/blacklist registries
- Statistics (cache hit rate, savings)
- **Image build service** — Cloud-based Dockerfile builds
- **Registry mirroring** — Pull-through cache for Docker Hub, ghcr.io, etc.
- **Deployment tools** — One-click deploy to K8s, ECS, Fly.io
- **Image recommendations** — ML-based "similar images" and "people also pulled"
- **Gamification** — Achievement badges, leaderboards
- **Advanced search** — Semantic/AI-powered search, saved searches
### Deployment Tools
---
**One-click deployments:**
- Deploy image to Kubernetes
- Deploy to Docker Swarm
- Deploy to AWS ECS/Fargate
- Deploy to Fly.io, Railway, Render
## Updated Priority List
**Deployment tracking:**
- Track where images are deployed
- Show running versions (which environments use which tags)
- Notify on new deployments
**Already done (was "High Priority"):**
1. ~~Multi-architecture image support~~ — display working
2. ~~Vulnerability scanning integration~~ — backend complete
3. ~~Hold management dashboard~~ — implemented on hold admin panel
4. ~~Basic search~~ — working
### Image Recommendations
**Remaining high priority:**
1. Scan results UI in AppView (backend exists, just needs frontend)
2. SBOM display UI in AppView (backend exists, just needs frontend)
3. Webhooks for CI/CD integration
4. Enhanced search (filters, sorting, advanced queries)
5. Richer sailor profiles (bio, stats, pinned repos)
**ML-based recommendations:**
- "Similar images" (based on layers, packages, tags)
- "People who pulled this also pulled..." (collaborative filtering)
- "Recommended for you" (personalized based on history)
**Medium priority:**
1. Layer inspection UI
2. Pull analytics and monitoring
3. API documentation (Swagger/OpenAPI)
4. Tag management (promotion, protection, aliases)
5. Onboarding wizard / getting started guide
### Gamification
**Achievements:**
- Badges for milestones (first push, 100 pulls, 1GB storage, etc.)
- Leaderboards (most popular images, most active sailors)
- Community contributions (points for helping others)
### Advanced Search
**Semantic search:**
- Search by description, README, labels
- Natural language queries ("show me nginx images with SSL")
- AI-powered search (GPT-based understanding)
**Saved searches:**
- Save frequently used queries
- Subscribe to search results (get notified of new matches)
- Share searches with team
## Implementation Priority
If implementing these features, suggested priority order:
**High Priority (Next 6 months):**
1. Multi-architecture image support
2. Vulnerability scanning integration
3. Hold management dashboard
4. Enhanced search and filtering
5. Webhooks for CI/CD integration
**Medium Priority (6-12 months):**
**Low priority / long-term:**
1. Team/organization accounts
2. Repository-level permissions
3. Image signing and verification
4. Pull analytics and monitoring
5. API documentation and SDKs
**Low Priority (12+ months):**
1. Enterprise features (SSO, compliance, SLA)
2. Image build service
3. Registry mirroring
4. Mobile apps
5. ML-based recommendations
4. Federation features
5. Internationalization
**Research/Experimental:**
**Blocked on external dependencies:**
1. Private repositories (requires ATProto private records)
2. Federated timeline (requires ATProto feed infrastructure)
3. Deployment tools integration
4. Semantic search
---
**Note:** This is a living document. Features may be added, removed, or reprioritized based on user feedback, technical feasibility, and ATProto ecosystem evolution.
*Last audited: 2026-02-12*
docs/DISTRIBUTION.md → docs/CREDENTIAL_HELPER.md
View File
docs/REMOVING_DISTRIBUTION.md
+480
View File
@@ -0,0 +1,480 @@
# Removing distribution/distribution
This document analyzes what it would take to remove the `github.com/distribution/distribution/v3` library and implement ATCR's own OCI Distribution Spec HTTP endpoints.
## Why Consider Removing It
1. **Impedance mismatch** -- Distribution assumes manifests and blobs live in the same storage backend. ATCR routes manifests to ATProto PDS and blobs to hold/S3. Every storage interface is overridden.
2. **Context value workaround** -- `Repository()` receives only `context.Context` from distribution's interface, forcing auth/identity data through context keys into `RegistryContext`.
3. **Per-request repository creation** -- `RoutingRepository` is recreated on every request because distribution's caching assumptions conflict with ATCR's OAuth session model.
4. **Stale transitive dependencies** -- Distribution pulls in AWS SDK v1 (EOL) via its S3 storage driver, even though ATCR doesn't use that driver.
5. **Unused features** -- GC, notifications, storage drivers, replication -- none are used. ATCR has its own GC, its own event dispatch (`processManifest` XRPC), and its own S3 integration.
6. **Upstream maintenance pace** -- Slow to merge dependency updates and bug fixes.
## What Distribution Currently Provides
Only these pieces are actually used:
| What | Distribution Package | ATCR Usage |
|------|---------------------|------------|
| HTTP endpoint routing | `registry/handlers` | `handlers.NewApp()` creates the `/v2/` handler |
| OCI error responses | `registry/api/errcode` | `ErrorCodeUnauthorized`, `ErrorCodeDenied`, `ErrorCodeUnsupported` |
| Middleware registration | `registry/middleware/registry` | `Register("atproto-resolver", ...)` |
| Repository interface | `distribution` (root) | `Repository`, `ManifestService`, `BlobStore`, `TagService` |
| Reference parsing | `distribution/reference` | `reference.Named` for `identity/image` parsing |
| Token auth | `registry/auth/token` | Blank import for registration |
| In-memory driver | `registry/storage/driver/inmemory` | Blank import; placeholder since real storage is external |
| Configuration types | `configuration` | `configuration.Configuration` struct |
Everything else (S3 driver, GC, notifications, replication, schema validation) is dead weight.
## Files That Import Distribution
All in `pkg/appview/` -- hold and scanner are unaffected.
**Core implementation (8 files):**
- `storage/routing_repository.go` -- `distribution.Repository` wrapper
- `storage/manifest_store.go` -- `distribution.ManifestService` impl
- `storage/proxy_blob_store.go` -- `distribution.BlobStore` + `BlobWriter` impl
- `storage/tag_store.go` -- `distribution.TagService` impl
- `middleware/registry.go` -- `distribution.Namespace` + middleware registration
- `config.go` -- Builds `configuration.Configuration`
- `server.go` -- `handlers.NewApp()`, `errcode` for error responses
- `cmd/appview/main.go` -- Blank imports for driver/auth registration
**Tests (6 files):**
- `storage/routing_repository_test.go`
- `storage/manifest_store_test.go`
- `storage/proxy_blob_store_test.go`
- `storage/tag_store_test.go`
- `middleware/registry_test.go`
## OCI Distribution Spec Endpoints to Implement
The spec defines these HTTP endpoints. ATCR would need handlers for each.
### Version Check
```
GET /v2/
200 OK (confirms OCI compliance)
401 Unauthorized (triggers auth flow)
```
Docker clients hit this first. Must return 200 for authenticated requests. A 401 response with `WWW-Authenticate` header triggers the Docker auth handshake.
### Manifests
```
GET /v2/<name>/manifests/<reference> -> 200 + manifest body
HEAD /v2/<name>/manifests/<reference> -> 200 + headers only
PUT /v2/<name>/manifests/<reference> -> 201 Created
DELETE /v2/<name>/manifests/<reference> -> 202 Accepted
```
`<reference>` is either a tag (`latest`) or digest (`sha256:abc...`).
**Required headers:**
- Request `Accept`: manifest media types the client supports
- Response `Content-Type`: actual manifest media type
- Response `Docker-Content-Digest`: canonical digest of manifest
**Media types to support:**
- `application/vnd.oci.image.manifest.v1+json`
- `application/vnd.oci.image.index.v1+json`
- `application/vnd.docker.distribution.manifest.v2+json`
- `application/vnd.docker.distribution.manifest.list.v2+json`
### Blobs
```
GET /v2/<name>/blobs/<digest> -> 200 + blob body (or 307 redirect)
HEAD /v2/<name>/blobs/<digest> -> 200 + headers only
DELETE /v2/<name>/blobs/<digest> -> 202 Accepted
```
ATCR already redirects to presigned S3 URLs via `ServeBlob()` -- this would become a direct 307 redirect in the handler.
### Blob Uploads (Chunked/Resumable)
**Initiate:**
```
POST /v2/<name>/blobs/uploads/
202 Accepted
Location: /v2/<name>/blobs/uploads/<uuid>
```
**Monolithic (single request):**
```
POST /v2/<name>/blobs/uploads/?digest=sha256:...
Content-Type: application/octet-stream
Body: <entire blob>
201 Created
```
**Chunked:**
```
PATCH /v2/<name>/blobs/uploads/<uuid>
Content-Type: application/octet-stream
Content-Range: <start>-<end>
Body: <chunk data>
202 Accepted
Range: 0-<end>
(repeat PATCH for each chunk)
PUT /v2/<name>/blobs/uploads/<uuid>?digest=sha256:...
201 Created
Location: /v2/<name>/blobs/<digest>
```
**Check progress:**
```
GET /v2/<name>/blobs/uploads/<uuid>
204 No Content
Range: 0-<bytes received>
```
**Cancel:**
```
DELETE /v2/<name>/blobs/uploads/<uuid>
204 No Content
```
**Cross-repo mount:**
```
POST /v2/<name>/blobs/uploads/?mount=<digest>&from=<other-repo>
201 Created (if blob exists in source repo)
202 Accepted (fall back to regular upload)
```
### Tags
```
GET /v2/<name>/tags/list
200 OK
{
"name": "<name>",
"tags": ["latest", "v1.0"]
}
```
Supports pagination via `n` (count) and `last` (cursor) query params.
### Referrers (OCI v1.1)
```
GET /v2/<name>/referrers/<digest>
200 OK
Content-Type: application/vnd.oci.image.index.v1+json
Body: image index of referring manifests
```
Supports `artifactType` query filter. Returns manifests whose `subject` field points to the given digest.
### Catalog (Optional)
```
GET /v2/_catalog
200 OK
{ "repositories": ["alice/app", "bob/tool"] }
```
Pagination via `n` and `last`. ATCR may choose not to implement this (many registries don't).
## Error Response Format
All 4xx/5xx responses must use the OCI error envelope:
```json
{
"errors": [
{
"code": "MANIFEST_UNKNOWN",
"message": "manifest not found",
"detail": { "tag": "latest" }
}
]
}
```
**Standard error codes:**
| Code | HTTP Status | Meaning |
|------|-------------|---------|
| `BLOB_UNKNOWN` | 404 | Blob not found |
| `BLOB_UPLOAD_INVALID` | 400 | Bad digest or size mismatch |
| `BLOB_UPLOAD_UNKNOWN` | 404 | Upload session expired/missing |
| `DIGEST_INVALID` | 400 | Digest doesn't match content |
| `MANIFEST_BLOB_UNKNOWN` | 404 | Manifest references missing blob |
| `MANIFEST_INVALID` | 400 | Malformed manifest |
| `MANIFEST_UNKNOWN` | 404 | Manifest not found |
| `NAME_INVALID` | 400 | Bad repository name |
| `NAME_UNKNOWN` | 404 | Repository doesn't exist |
| `SIZE_INVALID` | 400 | Content-Length mismatch |
| `UNAUTHORIZED` | 401 | Authentication required |
| `DENIED` | 403 | Permission denied |
| `UNSUPPORTED` | 405 | Operation not supported |
| `TOOMANYREQUESTS` | 429 | Rate limited |
## What Exists Today vs What's New
For each handler, this breaks down what logic already exists in the storage layer (and just needs to be called) vs what new HTTP glue code must be written. Distribution's handler layer currently handles all the HTTP parsing, header validation, content negotiation, and response formatting -- all of that becomes our responsibility.
### Shared New Code
**Error helpers (~50 lines, new):**
OCI error envelope formatting. Currently provided by `errcode.ErrorCodeUnauthorized` etc.
```go
type RegistryError struct {
Code string `json:"code"`
Message string `json:"message"`
Detail interface{} `json:"detail,omitempty"`
}
func WriteError(w http.ResponseWriter, status int, code, message string) {
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(status)
json.NewEncoder(w).Encode(struct {
Errors []RegistryError `json:"errors"`
}{Errors: []RegistryError{{Code: code, Message: message}}})
}
```
**Auth middleware (~80 lines, mostly exists):**
`ExtractAuthMethod()` already exists in `middleware/registry.go`. Needs adaptation to work standalone (currently wraps distribution's app). Must also generate `WWW-Authenticate` header for 401 responses -- distribution's token auth handler currently does this via blank import of `registry/auth/token`.
**Identity resolution middleware (~250 lines, exists):**
`NamespaceResolver.Repository()` in `middleware/registry.go` does identity resolution, hold discovery, service token acquisition, and ATProto client creation. This logic moves into an HTTP middleware but the code is the same -- resolves DID, finds hold, gets service token, builds `RegistryContext`. The validation cache (concurrent service token deduplication) comes along as-is.
**Router (~30 lines, new):**
```go
mux.HandleFunc("GET /v2/", handleVersionCheck)
mux.HandleFunc("GET /v2/{name...}/manifests/{reference}", handleManifestGet)
// ... etc
```
### Handler-by-Handler Breakdown
---
**`handleVersionCheck`** -- `GET /v2/`
| | |
|---|---|
| Existing logic | None needed -- this is just a 200 OK response |
| New code | ~10 lines. Return 200 with `Docker-Distribution-API-Version: registry/2.0` header. If unauthenticated, return 401 with `WWW-Authenticate` header to trigger Docker's auth flow |
---
**`handleManifestGet`** -- `GET /v2/<name>/manifests/<reference>`
| | |
|---|---|
| Existing logic | `ManifestStore.Get()` fetches manifest from PDS (record lookup, optional blob download for new-format records). Returns media type + raw bytes. Also fires async pull notification to hold for stats. `TagStore.Get()` resolves tag → digest when reference is a tag |
| New code (~40 lines) | Parse `<reference>` to determine tag vs digest. If tag, call `TagStore.Get()` first to resolve digest. Call `ManifestStore.Get()`. Set response headers: `Content-Type` (manifest media type), `Docker-Content-Digest` (canonical digest), `Content-Length`. Write body. Handle 404 (manifest not found → `MANIFEST_UNKNOWN` error) |
| Subtle | Content negotiation: must check client's `Accept` header against the manifest's actual media type. Distribution handles this transparently. If client doesn't accept the type, return 404. In practice most clients accept everything, but `crane` and `skopeo` can be picky |
---
**`handleManifestHead`** -- `HEAD /v2/<name>/manifests/<reference>`
| | |
|---|---|
| Existing logic | `ManifestStore.Exists()` checks PDS record existence. `ManifestStore.Get()` needed for full headers |
| New code (~30 lines) | Same as GET but write headers only, no body. Needs `Content-Type`, `Docker-Content-Digest`, `Content-Length`. Could call `Exists()` for a fast path and `Get()` for full header population, or just call `Get()` and skip the body write |
| Note | Some clients (Docker) use HEAD to check existence before pulling. Must return same headers as GET |
---
**`handleManifestPut`** -- `PUT /v2/<name>/manifests/<reference>`
| | |
|---|---|
| Existing logic | `ManifestStore.Put()` does a LOT: calculates digest, uploads manifest bytes as blob to PDS, creates `ManifestRecord` with structured metadata, validates manifest list child references, extracts config labels, fetches README/icon, creates tag record, fires async notifications to hold, creates repo page records, handles successor migration |
| New code (~50 lines) | Read request body. Extract `Content-Type` header as media type. Parse `<reference>` to determine if this is a tag push. Call `ManifestStore.Put()` with payload, media type, and optional tag. Set response headers: `Location` (`/v2/<name>/manifests/<digest>`), `Docker-Content-Digest`. Return 201 Created. Handle errors: `MANIFEST_INVALID` (bad JSON), `MANIFEST_BLOB_UNKNOWN` (missing child manifest in manifest list) |
| Subtle | Distribution currently wraps the manifest in a `distribution.Manifest` interface (with `Payload()` and `References()` methods) before passing to `Put()`. Without distribution, we'd change `Put()` to accept raw `[]byte` + `mediaType` + optional tag directly -- simpler but requires updating the method signature and its internals |
---
**`handleManifestDelete`** -- `DELETE /v2/<name>/manifests/<reference>`
| | |
|---|---|
| Existing logic | `ManifestStore.Delete()` calls `ATProtoClient.DeleteRecord()` |
| New code (~15 lines) | Parse digest from `<reference>`. Call `ManifestStore.Delete()`. Return 202 Accepted. Handle 404 |
---
**`handleBlobGet`** -- `GET /v2/<name>/blobs/<digest>`
| | |
|---|---|
| Existing logic | `ProxyBlobStore.ServeBlob()` checks read access, gets presigned URL from hold, and issues 307 redirect. This is already essentially an HTTP handler |
| New code (~20 lines) | Parse digest from path. Call the presigned URL logic (read access check + hold XRPC call). Write 307 redirect with `Location` header pointing to presigned S3 URL |
| Note | `ServeBlob()` currently takes `http.ResponseWriter` and `*http.Request` -- it's already doing the HTTP work. This handler is mostly just calling it. Could almost be used as-is |
---
**`handleBlobHead`** -- `HEAD /v2/<name>/blobs/<digest>`
| | |
|---|---|
| Existing logic | `ProxyBlobStore.Stat()` checks read access, gets presigned HEAD URL, makes HEAD request to S3, returns size |
| New code (~20 lines) | Parse digest. Call `Stat()`. Set `Content-Length`, `Docker-Content-Digest`, `Content-Type: application/octet-stream`. Return 200. Handle 404 (`BLOB_UNKNOWN`) |
---
**`handleBlobUploadInit`** -- `POST /v2/<name>/blobs/uploads/`
| | |
|---|---|
| Existing logic | `ProxyBlobStore.Create()` checks write access, generates upload ID, calls `startMultipartUpload()` XRPC to hold, creates `ProxyBlobWriter`, stores in `globalUploads` map |
| New code (~50 lines) | Check for `?mount=<digest>&from=<repo>` query params (cross-repo mount). Check for `?digest=<digest>` (monolithic upload -- read body, write to store, complete in one shot). Otherwise, call `Create()` to start a new upload session. Return 202 Accepted with `Location: /v2/<name>/blobs/uploads/<uuid>` header, `Docker-Upload-UUID` header |
| Subtle | Monolithic upload (single POST with digest and body) is a shortcut some clients use. Distribution handles this transparently. We'd need to handle it explicitly: read body, create writer, write, commit. Cross-repo mount is also handled here -- check if blob exists in source repo, skip upload if so |
---
**`handleBlobUploadChunk`** -- `PATCH /v2/<name>/blobs/uploads/<uuid>`
| | |
|---|---|
| Existing logic | `ProxyBlobWriter.Write()` buffers data and auto-flushes 10MB chunks to S3 via presigned URLs. `flushPart()` handles the XRPC call to hold for part upload URLs and ETag tracking |
| New code (~40 lines) | Look up writer from `globalUploads` by UUID. Parse `Content-Range` header (format: `<start>-<end>`). Read request body. Call `writer.Write(body)`. Return 202 Accepted with `Location` header (same upload URL), `Range: 0-<total bytes received>` header. Handle missing upload (`BLOB_UPLOAD_UNKNOWN`) |
| Subtle | `Content-Range` validation: must verify start offset matches current writer position (no gaps, no out-of-order). Return 416 Range Not Satisfiable if misaligned. Distribution handles this; we'd need to track and validate |
---
**`handleBlobUploadComplete`** -- `PUT /v2/<name>/blobs/uploads/<uuid>?digest=sha256:...`
| | |
|---|---|
| Existing logic | `ProxyBlobWriter.Commit()` flushes remaining buffer, calls `completeMultipartUpload()` XRPC to hold, removes writer from `globalUploads` |
| New code (~40 lines) | Look up writer from `globalUploads`. Parse `?digest=` query param. If request has body, write it to the writer (final chunk can be in the PUT). Call `writer.Commit()` with digest descriptor. Return 201 Created with `Location: /v2/<name>/blobs/<digest>`, `Docker-Content-Digest` header. Handle errors: `DIGEST_INVALID` (provided digest doesn't match), `BLOB_UPLOAD_UNKNOWN` (expired session) |
| Subtle | Digest validation: distribution verifies the provided digest matches what was actually uploaded. Our writer doesn't currently track a running digest hash -- `Commit()` just passes the digest through to hold. Need to decide: trust the hold to validate, or add client-side validation. Currently hold does the final validation since it has all the parts |
---
**`handleBlobUploadStatus`** -- `GET /v2/<name>/blobs/uploads/<uuid>`
| | |
|---|---|
| Existing logic | `ProxyBlobWriter.Size()` returns total bytes written |
| New code (~15 lines) | Look up writer from `globalUploads`. Return 204 No Content with `Range: 0-<size - 1>`, `Docker-Upload-UUID`, `Location` headers. Handle missing upload |
---
**`handleBlobUploadCancel`** -- `DELETE /v2/<name>/blobs/uploads/<uuid>`
| | |
|---|---|
| Existing logic | `ProxyBlobWriter.Cancel()` calls `abortMultipartUpload()` XRPC to hold, removes from `globalUploads` |
| New code (~15 lines) | Look up writer. Call `Cancel()`. Return 204 No Content. Handle missing upload |
---
**`handleTagsList`** -- `GET /v2/<name>/tags/list`
| | |
|---|---|
| Existing logic | `TagStore.All()` lists all tag records from PDS, filters by repository |
| New code (~30 lines) | Call `TagStore.All()`. Parse `?n=` and `?last=` query params for pagination (slice the results). Return JSON: `{"name": "<name>", "tags": [...]}`. Set `Link` header for pagination if there are more results |
| Note | Distribution handles pagination. We'd need to implement it ourselves -- sort tags, apply cursor, set Link header with next page URL |
---
**`handleReferrers`** -- `GET /v2/<name>/referrers/<digest>`
| | |
|---|---|
| Existing logic | Not currently implemented in ATCR's storage layer. Distribution may return an empty index |
| New code (~30 lines) | Query manifests that have a `subject` field pointing to the given digest. Return an OCI image index containing descriptors for each referrer. Support `?artifactType=` filter. If no referrers, return empty index |
| Note | This is new functionality either way. ATCR would need to query PDS for manifests with matching subject digests. Could defer this (return empty index) and implement properly later |
---
### Interface Changes to Storage Layer
The existing stores would need their method signatures simplified. This is mostly mechanical -- removing distribution wrapper types:
**ManifestStore changes:**
- `Get()`: returns `(distribution.Manifest, error)` → returns `(mediaType string, payload []byte, err error)`
- `Put()`: accepts `distribution.Manifest` + `...distribution.ManifestServiceOption` → accepts `payload []byte, mediaType string, tag string`
- `Exists()` and `Delete()`: signatures stay roughly the same (just `digest.Digest` in, error out)
- Remove `rawManifest` struct (wrapper implementing `distribution.Manifest` interface)
- Remove `distribution.WithTagOption` extraction logic in `Put()`
**ProxyBlobStore changes:**
- `Stat()`: returns `distribution.Descriptor` → returns `(size int64, err error)`
- `Get()`: stays the same (returns `[]byte`)
- `ServeBlob()`: already takes `http.ResponseWriter`/`*http.Request` -- could become the handler itself
- `Create()`: returns `distribution.BlobWriter` → returns `*ProxyBlobWriter` directly
- `Resume()`: same change
- Remove `distribution.BlobCreateOption` / `distribution.CreateOptions` parsing
- `ProxyBlobWriter.Commit()`: accepts `distribution.Descriptor` → accepts `digest string, size int64`
**TagStore changes:**
- `Get()`: returns `distribution.Descriptor` → returns `(digest string, err error)`
- `Tag()`: accepts `distribution.Descriptor` → accepts `digest string`
- `All()`, `Untag()`, `Lookup()`: minimal changes
**RoutingRepository:**
- Removed entirely. Handlers call stores directly. The lazy initialization via `sync.Once` goes away since there's no interface requiring a `Repository` object.
**Estimated interface change work:** ~150 lines changed across storage files + ~150 lines changed across test files.
## What Stays
These dependencies are used directly and stay regardless:
- `github.com/opencontainers/go-digest` -- Digest parsing/validation (standard, lightweight)
- `github.com/opencontainers/image-spec` -- OCI manifest/index structs (optional but useful for validation)
- `github.com/distribution/reference` -- Could stay (lightweight, no heavy transitive deps) or replace with string splitting since ATCR's name format is always `<identity>/<image>`
## Revised Effort Estimate
| Component | New Lines | Changed Lines | Notes |
|-----------|-----------|---------------|-------|
| Router + version check | ~40 | 0 | Trivial |
| Error helpers | ~50 | 0 | OCI error envelope, error code constants |
| Auth middleware adaptation | ~30 | ~50 | `WWW-Authenticate` header generation is new; `ExtractAuthMethod` moves |
| Identity resolution middleware | ~20 | ~30 | `NamespaceResolver.Repository()` logic moves to HTTP middleware; code is the same |
| Manifest handlers (GET/HEAD/PUT/DELETE) | ~135 | 0 | Content negotiation, header writing, tag vs digest parsing |
| Blob handlers (GET/HEAD/DELETE) | ~55 | 0 | Presigned URL redirect, stat, delete stub |
| Blob upload handlers (POST/PATCH/PUT/GET/DELETE) | ~160 | 0 | Chunked upload protocol, Content-Range validation, monolithic upload, cross-repo mount |
| Tags list handler | ~30 | 0 | Pagination logic |
| Referrers handler | ~30 | 0 | Could defer with empty index |
| Storage interface changes | 0 | ~150 | Remove distribution types from method signatures |
| Test updates | 0 | ~150 | Update mocks and assertions for new signatures |
| Config cleanup | 0 | ~80 | Remove `buildDistributionConfig()`, blank imports |
| **Total** | **~550 new** | **~460 changed** | **~1010 lines total** |
This is not a trivial migration. The ~550 new lines are genuine new HTTP handler code that doesn't exist today -- distribution's handler layer provides all of it currently. The changed lines are mostly mechanical (removing distribution type wrappers) but still need care and test updates.
## Risk Assessment
**Low risk:**
- Storage logic is unchanged -- same PDS calls, same hold XRPC calls, same presigned URLs
- Auth flow is unchanged -- same JWT validation, same OAuth refresh
- Tests can be adapted incrementally
**Medium risk:**
- Subtle OCI spec compliance gaps (edge cases in content negotiation, digest validation, chunked upload semantics)
- Docker client compatibility -- different clients (Docker, Podman, crane, skopeo) may exercise different code paths
**Mitigation:**
- Use [OCI conformance tests](https://github.com/opencontainers/distribution-spec/tree/main/conformance) to validate
- Test against Docker, Podman, crane, and skopeo before shipping
- Can be done incrementally: build new router, test alongside distribution handler, swap when ready
## Dependencies Removed
Removing distribution eliminates ~30-40 transitive packages, notably:
- `github.com/aws/aws-sdk-go` (v1, EOL)
- Azure cloud SDK packages
- Google Cloud Storage packages
- Distribution-specific logging/metrics
- Unused storage driver registrations
Most other transitive deps (gRPC, protobuf, OpenTelemetry, logrus) are also pulled by `bluesky-social/indigo` and would remain.