Product

Register

product

Users

The operator and a small, deliberately-invited circle of friends and family. They visit dab occasionally — to mint a token for a new DAV client, to add a calendar collection before they point Thunderbird at it, to drop a folder into the file tree before sharing the URL with someone over chat. The daily work happens in real DAV clients (Apple Calendar, Thunderbird, DAVx⁵, Joplin, anything that speaks WebDAV/CalDAV/CardDAV); dab itself is the configuration desk behind those clients, not a daily driver.

A single subject owns the entire host (<five-word-host-label>.dab.limic.dev/). There are no tenants, no orgs, no teams. The control plane (dab.limic.dev/) is this configuration UI; the subject host is where DAV traffic lives. The user is always either the operator themselves or one specific invited subject — never a visitor and never a paying customer.

Primary use cases

• Sign in via tessera, then leave — most onward work happens in a DAV client.
• Mint and revoke Personal Access Tokens for new DAV clients (Thunderbird, iOS Calendar, DAVx⁵, etc.).
• Create a new calendar / address book / file folder collection before pointing a client at it.
• Copy the principal/calendar-home/addressbook-home discovery URLs into a client's "add account" dialog.
• Audit and prune existing collections occasionally.

Product Purpose

dab gives each tessera subject a private DAV host with an opaque five-word DNS label, and a small browser surface to configure what lives behind it. The control plane is the doorway and the reading desk; everything else is DAV.

The product exists because the alternatives are wrong shapes:

• Consumer clouds (iCloud, Drive, Dropbox) are share-link products with paywalls, AI scans, and a relationship the user did not ask for.
• Enterprise NAS appliances (Nextcloud, Synology DSM) are IT-admin tools optimized for an enterprise that doesn't exist here.
• Hand-rolled radicale/baikal installs are correct in spirit but ship no presentable surface; you cannot ask a friend to "log into your CalDAV."

dab is the smallest possible control plane for a Cloudflare-native DAV service: tessera handles identity, dab handles your DAV-shaped data, and any client that speaks the standards can use the result. Success looks like a user visiting four times a year, doing the one thing they came to do in under a minute, and going back to their actual mail/calendar/file client. Failure looks like the operator opening dab to "browse" their own data.

Brand Personality

Composed. Specific. Warm.

dab is the private wing of a library that the operator cut a key to. The gate (tessera) is at the front of the building; dab is the room behind it where the labeled shelves sit. The surface is sparse, the typography is ceremonial in one place and quiet everywhere else, the accent appears as a small bookmark slip rather than a banner.

If dab were a place, it would be a small reading room with three labeled stacks: one for calendars, one for address books, one for files. The catalog card on each shelf names what's there; the placard at the entrance to the wing gives you the shelfmark you'd point a DAV client at. Nothing flashes. Nothing asks to be your daily driver.

The voice does not explain. There is no welcome copy. The H1 names the room you're in (Tokens, Calendars, Files) in a warm variable serif (Fraunces); the body label below it tells you what the room is for in one sentence. The coral-magenta accent (#db3a8b) appears rarely: the primary CTA, the active nav state, the small heart in the footer, the bookmark slip on an active row. Never a background fill, never a gradient, never a decorative shadow. Rarity is the point.

The Layers brand glyph rotates -rotate-6 on hover. That single micro-detail carries the whole "a person made this" message; the rest of the surface remains still. The serif handles ceremony; Hanken handles the steady labor; JetBrains Mono handles the URLs and IDs that need to be copy-pasted.

Anti-references

• Consumer cloud storage (Dropbox / iCloud / Google Drive). The tile-grid file browser, the "Upgrade to Pro" sidebar, the share-link modal with social buttons, the AI-scan opt-in, the "Recents" carousel. dab is not a consumer share-link product and the surface should not look like one. No tile grids. No "+ New" floating action buttons. No social share affordances.
• Enterprise NAS admin (Nextcloud / ownCloud / Synology DSM). The default Bootstrap-styled "Files / Contacts / Calendar" tab bar, the sidebar accordions, the server-room cyan-on-gray palette, the settings buried five clicks deep, the "App Center" landing page. dab is not an IT-admin appliance and the surface should not feel like one. No left-rail accordion menus. No cyan-and-gray palette. No "Apps" view.
• AI-template dark mode. Neon-on-near-black, gradient meshes, glassmorphism, gradient text, the shield-plus-checkmark icon over a "Your data, secure" hero, "Get started in 60 seconds" CTAs. Anything that could ship as a Vercel template default. dab's coral-magenta lives at the warm edge of the magenta open range specifically to dodge the violet-500 ai-template reflex; this should never come back through the door as decoration.
• iCloud-style "soft pastel" calendar aesthetic. The pastel-tinted month grid, floating rounded event pills, decorative weather glyphs, the cheerful-Apple voice. dab does not render calendar grids (collection metadata only) but the aesthetic could leak into how we render a calendar's color swatch or the empty state. It must not. Calendar color is one solid 3px dot beside the display name, not a tinted pill background.

Design Principles

1. The wing is sparse on purpose. Most pages have one H1, one short sentence, and the work. No reassurance copy. No "Welcome back." No "What's new?" callouts. The user did not come here to read marketing; they came to add a calendar. Show them the calendars. The empty space is the message that nothing else needs their attention.

2. The serif is rare; the accent is rarer. Fraunces (display) appears on page H1s and the brand mark only. Coral-magenta (#db3a8b) appears on the primary CTA, the active nav state, and the footer heart — and almost nowhere else. Spreading either dilutes both. The whole design system is built around the assumption that you will see the serif once and the accent twice per page; if that count creeps up, the page is getting fancy in a way that contradicts the wing metaphor.

3. Catalog-card density, not dashboard density. Each row in a list is a labeled shelf: display name, internal name (mono), one timestamp, the URL in a collapsed <details> block. No charts. No "Recent activity" graphs. No multi-column dashboards with sparklines and KPI tiles. If a piece of information would not fit on an index card, it does not belong on the row.

4. Trust the user to read the URL. When a user creates a token or a calendar, the response is the URL itself, copy-able, in a mono <input> inside the Copyable component. There is no "Successfully created!" banner, no celebratory animation, no confetti. The toast says "Created" or "Revoked" in past tense; the row appears or disappears; that is the acknowledgement. The URL on the page is the receipt.

5. The library is closed at night. dab is a configuration surface, not a daily workspace. Every design decision should be measured against "does this make the four-times-a-year visit pleasant?" — not "is this discoverable for a user who lives here?" If the answer is no, cut it. If a feature would only matter on visit ten of a day, it does not belong in dab; that feature belongs in the user's actual DAV client.

Accessibility & Inclusion

Astigmatism is a hard constraint, not a preference. Inherited suite-wide from anvil/bland/flamemail/tessera. Roughly 33% of people have some degree of astigmatism; on near-black surfaces light text blooms (halates) and fatigues extended reading. dab honors the suite's response:

• Lifted canvas, never near-black. Body background #221f21, not #09090b. The surface hierarchy is four tiers (Chrome #1b181a, Canvas #221f21, Recessed #1b181a, Elevated #2a2729) — depth comes from tone, not shadow.
• Body weight 450, never thinner. No font-light, no font-thin. Light strokes halate on dark for ~33% of users.
• No pure white on pure black. Body text ceiling is zinc-100 (#f5f4f4) on canvas; warmer than stock zinc by design.
• No hairline borders. Minimum effective border: 1px at ≥40% opacity, or use a background tint instead.
• Contrast checked on lifted surfaces. zinc-400 on zinc-900 (an Elevated card on the canvas) is the real check, not zinc-400 on zinc-950.

WCAG AA is the floor, not the ceiling. The accent palette is sized so accent-400 text on canvas clears AA normal (~5.5:1) and accent-500 filled backgrounds carry white text cleanly (~4.6:1).

Reduced motion is respected globally: a single @media (prefers-reduced-motion: reduce) rule clamps animation and transition durations to 0.01ms, scroll behavior to auto, and disables iterations. Don't add per-element guards; the global rule covers everything.

Keyboard and screen reader basics: skip link as the first focusable element, focus ring visible on every interactive element via the global *:focus-visible rule (ring-2 ring-accent-500/50 ring-offset-canvas), icon buttons always have aria-label, dialogs use native <dialog> for focus trap + ESC dismiss, route announcements via aria-live="polite" on the content wrapper.