Design pillars

Artist Alley has two product pillars. When a design decision is ambiguous, we pick the option that serves a pillar.

1. Artist-first, not archive-first

Artists upload and move on. The system fills in metadata on its own where it can. Every extra step is a reason not to use the archive.

• Drag in a folder and the files upload with sensible per-format defaults.
• EXIF, dimensions, color profile, and embedded thumbnails are read on ingest.
• Image embeddings (CLIP, stored in pgvector) power visual similarity — find assets that look like a given one, or upload an image and find matches. The CLIP encoder runs as an optional add-on container. Upload-time auto-tagging is a follow-up (issue #18).
• The set of required fields is small. An admin can add more per studio.
• Common actions — upload, find, comment, share, approve — take three clicks or fewer. If a workflow takes more, that’s a design problem to fix.

Upload should feel like ArtStation. If a studio wants more metadata, an admin adds the fields. By default, artists get out of the upload modal in seconds.

2. Review-grade

Reviewers open Artist Alley every day, so the tool is shaped around that loop.

• Per-asset comments (Frame.io-style) anchored to a timestamp or frame.
• A review canvas with zoom, pan, tile, and fullscreen.
• Frame-accurate video transport: JKL shuttle, frame-step, and an in/out loop region.

On the roadmap for the rest of this arc: tracking which assets are unreviewed since your last session, resuming mid-review where you left off, and live presenter sessions over SSE for synchronous review meetings.

The review tool is the center of the product. Everything else exists so reviewers have something to review.

---

Underneath the pillars: posture

The pillars describe how the product behaves. Three postures describe how it fits into a studio:

• One system, not five glued together. A studio shouldn’t have to wire up a DAM, a review tool, a transfer service, a chat bot, and a wiki to do its job. Artist Alley aims to cover the whole path — upload, review, version, archive, ship — in one self-hostable system.
• Open by default. The core is open source. Every feature on the roadmap ships in the AGPL binary an operator can self-host. Paid features are additive, and are gated only when an operator uses Artist Alley to monetize third parties, or when we’re carrying real operational cost on their behalf.
• Federated, no SaaS rent. Studios that work with outside partners — co-development teams, marketing agencies, licensing partners, museums on loan — share assets directly between separately-run instances. No vendor in the middle, no per-outsider seat license, no export-then-import that strips metadata. The protocol is ArchivePub, an open, ActivityPub-shaped spec for DAM federation that any other DAM can implement. We wrote it because no such spec existed, and because federation between studios should belong to the protocol rather than being a feature you rent.

Why the combination matters

Each of these exists on its own. There are commercial end-to-end DAMs. There are open-source DAMs (usually PHP, shaped for archivists). There are federated content platforms (Mastodon, Pixelfed, PeerTube for messaging, photos, and video). What doesn’t exist is all three together in one self-hostable binary written this decade. The artist-first pillar keeps daily users coming back; the review-grade pillar is what studio leads sign off on; the three postures are what let a studio adopt it without betting on a single vendor.