Locara

45 — Locara Website (locara.app)

The static website that serves as Locara’s public face: catalog discovery, app downloads, blog, manifesto, docs, legal. Per ADR 0012, the website is one of the three core products.

This spec defines what the website is, what it does, what it deliberately doesn’t do, and how it’s built.

Goals

  1. Discovery surface. Anyone can browse the catalog without signup or login.
  2. Trust establishment. First-time visitors see what Locara is + why to trust it.
  3. One-click downloads. “Click button → get DMG” with zero friction.
  4. Documentation home for developers building with Locara.
  5. Brand voice and editorial home — the calm-craft tone in action.
  6. No tracking, no friction. Anonymous browse + download.

Information architecture

locara.app/
├── /                    # Home: tagline + hero CTA + Featured apps
├── /apps                # Catalog
│   ├── /apps/{publisher}/{name}        # App detail page
│   └── /apps/{publisher}/{name}/{version}  # Specific version (rare; usually latest)
├── /apps?category=...   # Filtered catalog (productivity / creative / dev)
├── /apps?fully_local=true   # Filtered by privacy property
├── /publishers/{name}   # Publisher's full catalog
├── /docs                # Developer documentation
│   ├── /docs/getting-started
│   ├── /docs/concepts
│   ├── /docs/guides
│   ├── /docs/reference  # Auto-generated API ref
│   └── /docs/publish
├── /blog                # Devlogs + long-form posts
├── /manifesto           # The thesis (the existing manifesto.md)
├── /security            # Security policy, advisories, contact
├── /legal               # Privacy / ToS / DMCA
├── /people              # Trust group identity disclosure
├── /sponsors            # Sponsors, transparency
└── /search              # Cross-site search

Key pages

Home (/)

Above the fold:

  • Tagline: “Apps that run on your Mac.”
  • Subtitle: “No cloud. No tracking. Just yours.”
  • Primary CTA: “Browse apps” → /apps
  • Secondary CTA: “Build one” → /docs/getting-started

Below the fold:

  • 3–5 Featured apps as cards (Transcribe, DocVault, etc.).
  • Brief “Why local matters” section — the five-property summary from the manifesto.
  • Latest blog post excerpt.
  • Link to manifesto.

Total: short, clean, doesn’t require scrolling on a 13” laptop to get the gist.

Catalog (/apps)

Filter sidebar:

  • Category (Productivity, Creative, Developer Tools, Research, etc.)
  • Privacy badges (Fully Local, No Telemetry — both default-checked)
  • Device fit (auto-detected from browser if user opts in; otherwise manual)
  • Verified publisher only? (toggle)
  • Tags (multi-select)
  • Last updated (any / 30 days / 90 days)

Sort:

  • Featured (default — editorial mix)
  • Most installed
  • Highest rated
  • Recently updated
  • Newest

Card per app:

  • Icon (256x256)
  • Display name
  • One-line description
  • Publisher name + verified badge
  • Privacy badges (visible on every card)
  • Star rating + review count
  • “Install” button (link to download)

App detail page (/apps/{publisher}/{name})

The most important page. The user decides “do I install this” here.

Hero:

  • Icon (large)
  • Display name + version
  • Publisher with verified badge
  • One-line description
  • Big “Download for Mac” button → DMG link
  • Secondary: “View source on GitHub” / homepage link

Capability summary (auto-generated from manifest):

This app:
  ✓ Uses your microphone
  ✓ Reads files you select

This app cannot:
  ✗ Access the network
  ✗ Read other files on your Mac
  ✗ Phone home or send telemetry

Clicking any line opens a tooltip explaining the underlying enforcement (manifest field + macOS entitlement).

Privacy badges:

  • 🔒 Fully Local
  • 📵 No Telemetry
  • 📦 Open Source (with link to repo)
  • ✓ Verified Publisher (when applicable)

Device fit:

  • “Requires 16 GB RAM, 4 GB disk, Apple Silicon Mac”
  • If user’s device is auto-detected: ”✓ Fits your Mac (32 GB)”

Models used:

  • List with name + size + license
  • Click to see model card from registry

Tools used:

  • List with name + capability requirements

Screenshots / demo video (carousel)

Long description (publisher-authored markdown, sanitized)

Reviews + ratings

  • Aggregate at top (4.7 ★ 23 reviews)
  • Individual reviews with version, date, helpful votes
  • Verified-install badge on real reviews

Version history

  • Latest highlighted; older versions in dropdown
  • Per-version: changelog, capability changes (highlighted if any), publish date

Publisher info

  • Display name, verification level
  • Other apps from this publisher
  • Contact / support link

Publisher page (/publishers/{name})

  • Publisher name + verification level
  • Bio / description (publisher-authored)
  • All apps published by this publisher
  • Verification details (GitHub, optional domain)
  • Member since date

Docs (/docs)

The developer handbook. Per 34-documentation-strategy.md:

  • Getting started: 60-second demo + first-app tutorial.
  • Concepts: manifest, capabilities, modalities, runtime.
  • Guides: chat-app, transcription, document-processing, agent-loops, tool-creation.
  • Reference: auto-generated from JSDoc/rustdoc/manifest schema.
  • Publish: how to ship to the registry.
  • Troubleshooting + FAQ.

Built from markdown sources in the repo. Astro Content Collections.

Blog (/blog)

Devlog posts (weekly cadence) + long-form posts (occasional).

Each post: markdown + frontmatter (title, date, author, tags). RSS feed.

Manifesto (/manifesto)

The existing website/content/manifesto.md. Highlight on the home page; standalone-readable.

Security (/security)

  • Security policy + reporting flow.
  • PGP fingerprint for security@locara.app.
  • Advisories index (linked from incident postmortems).
  • Trust-group identities (links to /people).
  • Privacy policy, ToS, DMCA — links to the Markdown files in /legal/.

People (/people)

Per 40-operational-security.md:

  • Project lead identity (real name, GitHub, blog, country, PGP fingerprint).
  • Backup contact identity.
  • Trust group expansion list (when applicable).

Design system

  • Typography: modern serif (e.g., Source Serif Pro) for body + headings; clean sans (Inter) for UI.
  • Colors: restrained palette. One signature color (TBD per 29-branding.md) + neutrals. No gradients, no AI-tropey chrome.
  • Spacing: generous; breathing room.
  • Mode: respects system dark/light preference. Manual toggle in nav.
  • Responsive: desktop-first (Mac users); functional on tablet/phone for browsing.
  • Accessibility: WCAG AA; keyboard nav; screen-reader friendly. Per 20-accessibility.md.

Tech stack

ComponentChoiceWhy
Static site frameworkAstroFast, MDX support, content-collections, minimal JS
StylingTailwind CSS + custom design tokensAligns with Locara components
ContentMarkdown + MDX in website/content/Easy to edit + maintain
SearchPagefind (build-time static search)No JS runtime; works without backend
HostingCloudflare PagesFree tier; fast CDN
Build/deployGitHub Actions → PagesAutomated on push to main
Forms (security report, contact)Static + email mailto: linksNo form backend in v1
AnalyticsNone — see 41-telemetry-zeroThe point

Astro chosen for: fast page loads, MDX, content collections, Pagefind integration, friendly DX, no React-runtime tax for static pages. (Locara apps use React; the website doesn’t need it.)

What the website does NOT do

  • No accounts required to browse or download. No login wall.
  • No JavaScript that calls the user’s installed Locara apps. The website doesn’t have any handshake with the apps — they’re independent.
  • No server-side personalization. Same page for every visitor (modulo dark mode, locale).
  • No third-party scripts. No analytics, no chat widgets, no ads.
  • No comments / forum. Discussion happens on GitHub Discussions / Discord (linked, not embedded).
  • No payment processing. Apps charge through their own channels.

Catalog data flow

The catalog is built from data in the registry, not edited inline:

  1. Registry’s database has app records (manifest, version, ratings, etc.).
  2. A nightly build job exports a snapshot to public/registry-data.json.
  3. Astro generates static catalog pages at build time from this data.
  4. Hot-path updates (new app, new version) trigger re-builds via webhook.

Static-site approach is fast + cheap; no backend during a user’s browsing session.

For dynamic features (search, ratings) where build-time isn’t enough, fall back to small client-side fetches against the registry API.

Performance budgets

MetricTarget
First Contentful Paint< 1s on 4G
Largest Contentful Paint< 2s on 4G
Total page weight (home)< 200 KB
Lighthouse score95+ across all categories

Critical because: indie developers + privacy-conscious users hate slow sites; first impression matters.

Localization (i18n)

v1: English only (per 39-i18n.md).

When localized, structure supports it: /es/..., /fr/..., etc., with content per-locale in Astro Content Collections.

SEO

  • Open Graph metadata on every page.
  • App pages have rich structured data (schema.org/SoftwareApplication).
  • Sitemap.xml auto-generated.
  • Robots.txt allows crawling everywhere except /admin (which doesn’t exist publicly anyway).

Build + deploy

GitHub: kingtongchoo/locara/website/
   ↓ (push to main)
GitHub Actions:
  ─ bun install
  ─ astro build
  ─ pagefind --site dist
  ─ wrangler pages deploy dist
   ↓
Cloudflare Pages: locara.app

Build time: < 1 minute for the site (without hot-path catalog updates).

For catalog updates: registry’s nightly build job triggers website rebuild. No SSR; pure static.

Domain + DNS

  • Primary: locara.app (TBD per 29-branding.md)
  • CDN subdomain: cdn.locara.app for app artifacts
  • API subdomain: registry.locara.app for the registry API
  • Status page: status.locara.app
  • Docs subdomain (alternative): docs.locara.app (or /docs on main domain — leaning the latter for SEO)

DNS managed via Cloudflare; domain locked + 2FA on registrar.

Open questions

  • (open) Subdomain structure — docs.locara.app vs locara.app/docs? Lean main-domain for SEO + simpler nav.
  • (open) Should app cards include install counts publicly? (Privacy concern + can be gamed.) Lean yes for transparency, with differential privacy on aggregation.
  • (open) Should the website detect the user’s Mac specs (RAM, chip) automatically? Browser APIs have limits + privacy concerns. Lean opt-in.
  • (open) Comments / discussion on app pages? Probably no on the website (link to GitHub instead).
  • (open) Search infrastructure — Pagefind for v1; revisit if catalog grows beyond Pagefind’s index limits.

Cross-references