# LAYER.systems Design Direction

## 1. Design Intent

LAYER.systems should feel like Nostr relay infrastructure made visible: direct, fast, public, and protocol-native. The visual direction takes cues from bold editorial community sites such as `einundzwanzig.space`: strong navigation, large type, ticker energy, clear content bands, and a public-broadcast feeling.

This is not a clone. LAYER.systems needs its own identity: orange, infrastructural, decentralized, and practical. The site should make the relay endpoint the center of the experience, not a footnote.

## 2. Reference Translation

Inspired by `einundzwanzig.space`:

- Strong top navigation with grouped links.
- Large typographic hero with direct messaging.
- Horizontal ticker / marquee energy for relay URLs, protocol phrases, and network language.
- Clear content bands for relay status, usage, and connection steps.
- Editorial confidence instead of generic landing-page polish.
- Playful tone without losing operational credibility.

Translate for LAYER.systems:

- Use an orange-led palette instead of purple.
- Replace podcast/news hierarchy with relay endpoint and Nostr infrastructure hierarchy.
- Replace sponsor/content blocks with relay, protocol, client, and network modules.
- Use `wss://relay.layer.systems` as a visible recurring design motif.
- Make the copyable relay URL feel like the main product surface.

## 3. Personality

The interface should be:

- Public, not gated.
- Bold, not glossy.
- Operational, not corporate.
- Protocol-aware, not protocol-obscure.
- Human in tone, calm in structure.

Avoid:

- Generic orange gradient SaaS aesthetics.
- Overly soft pastel community branding.
- Crypto-bro visual language.
- Dense technical jargon in primary UI copy.
- Stock-photo hero sections.

## 4. Visual System

### Color Palette

Use orange as the identity anchor, but avoid a one-note all-orange interface.

Suggested palette:

- `Signal Orange`: `#F97316` for primary actions and identity marks.
- `Deep Ink`: `#18110D` for dark text, footer, and hard borders.
- `Relay Amber`: `#FACC15` for secondary highlights and ticker details.
- `Paper`: `#FFF7E8` for warm page background.
- `Chalk`: `#FFFFFF` for content surfaces.
- `Clay`: `#7C3F1D` for subdued labels and supporting text.
- `Protocol Green`: `#17A673` for live/verified states.
- `Network Blue`: `#2563EB` as a sparing cool accent.

Usage rules:

- Orange should lead, not flood.
- Use ink-heavy contrast and crisp borders for readability.
- Use amber, green, and blue sparingly to prevent the interface from becoming monochrome.
- Relay cards should remain legible before they are decorative.

### Typography

The type system should feel editorial and independent.

Recommended direction:

- Display: bold grotesk weight for hero and section titles.
- Body: readable sans with warmth and strong numerals.
- Mono: restrained monospace for relay URLs, event kinds, public keys, and tags.

Implementation preference:

- Use `@fontsource` packages when available.
- Use CSS variables for font families.
- Keep body text comfortable on content-heavy sections.
- Keep hero type large and compact, but never allow it to overflow mobile widths.

## 5. Layout

### Page Structure

The first version should be a single-page relay experience:

1. Sticky navigation
2. Relay ticker
3. Hero / identity
4. Copyable relay endpoint
5. Relay feature modules
6. Client connection steps
7. Footer with terms, privacy, and dashboard links

### Navigation

The nav should feel practical and slightly editorial:

- Left: LAYER.systems wordmark.
- Center: Relay, Signal, Connect, Explore.
- Right: `LoginArea`.
- Mobile: compact header with persistent login/account access.

Use strong text links and clear hover/focus treatment. Avoid oversized pill buttons for every nav item.

### Ticker

Add a horizontal ticker near the top of the page.

Potential ticker phrases:

- `LAYER.systems`
- `public Nostr relay`
- `wss://relay.layer.systems`
- `open protocols`
- `relay-first social`
- `NIP-aware infrastructure`
- `bring your own client`
- `events over platforms`

Ticker behavior:

- Continuous motion on desktop.
- Static fallback with `prefers-reduced-motion`.
- High contrast.
- No essential information should exist only in the ticker.

### Hero

The hero should be typographic and signal-heavy.

Content:

- Main title: `Relay signal for the open social web.`
- Supporting line: a concise statement about public Nostr relay infrastructure.
- Primary CTA: jump to the relay URL.
- Secondary CTA: jump to connection steps.

Visual treatment:

- Large editorial headline.
- Copyable endpoint module.
- Subtle grid or protocol texture is acceptable if it does not reduce readability.
- Use real relay/data motifs rather than abstract decorative blobs.

## 6. Components

### Relay Endpoint Card

Required elements:

- Relay URL.
- Copy button with copied state.
- Access mode.
- Network/protocol labels.
- Clear read/write language when applicable.

Design:

- Rectangular panel with `8px` or less radius.
- Crisp border and offset shadow.
- Relay URL must wrap safely on small screens.
- Copy action must remain reachable on mobile.

### Feature Cards

Required elements:

- Icon.
- Short title.
- One practical sentence.

Design:

- Rectangular cards.
- Crisp border.
- Subtle hover shift.
- No nested cards.

### Connection Steps

Required elements:

- Step number.
- Client action.
- Relay URL in the add-relay step.

Design:

- Structured rows or blocks.
- Step numbers should be visually strong.
- Code text should wrap cleanly.

### Empty States

If live relay status or event lists are added later, empty states should be minimalist and practical:

- Explain what data will appear.
- Include a short hint about adding `wss://relay.layer.systems` from any Nostr client.
- Avoid speculative promises about uptime or persistence.

## 7. Motion

Motion should feel like signal movement, not decoration.

Use:

- Ticker movement.
- Subtle hover shifts on cards and CTAs.
- Focus-visible rings with a quick transition.

Avoid:

- Heavy parallax.
- Decorative floating orbs.
- Motion that distracts from reading the relay URL.

Respect `prefers-reduced-motion`.

## 8. Imagery and Texture

This site does not need stock photography.

Preferred visual motifs:

- Relay/network linework.
- Terminal-inspired grid texture.
- Endpoint/code fragments.
- Protocol tags and event-kind labels.
- Simple infrastructure diagrams.

Texture direction:

- Light paper/noise texture is acceptable.
- Grid backgrounds are acceptable.
- Keep texture subtle enough that body text remains AA compliant.

## 9. Accessibility

Requirements:

- WCAG 2.1 AA contrast for text and controls.
- Keyboard-accessible navigation and controls.
- Visible focus states.
- Semantic headings.
- Descriptive alt text for static images.
- Empty `alt` for purely decorative images.
- No unsafe HTML injection.

## 10. Responsive Behavior

Mobile:

- Single-column flow.
- Sticky compact nav.
- Ticker can become static.
- Relay URL must wrap without layout overflow.
- Hero type must scale by breakpoint, not viewport-width formulas.

Tablet:

- Two-column section layouts where useful.
- Endpoint card remains prominent.

Desktop:

- Editorial grid with asymmetric section rhythm.
- Relay endpoint and hero copy share the first viewport.
- Keep primary content width controlled for readability.

## 11. Copy Tone

Tone should be direct and protocol-native.

Good:

- `Relay signal for the open social web.`
- `A public Nostr relay for portable social identity.`
- `Add the relay URL from any Nostr client.`
- `Events over platforms.`

Avoid:

- `Revolutionizing social engagement`
- `The ultimate decentralized ecosystem`
- `Next-generation community platform`
- `Seamless innovative experiences`

## 12. Implementation Notes

- Use existing shadcn/ui primitives.
- Keep cards at `8px` radius or less unless a local component requires otherwise.
- Use `cn()` for class composition when class branching is needed.
- Use lucide icons where icons are needed.
- Define color and font tokens in CSS variables.
- Keep sections as full-width bands with constrained inner content.
- Do not nest UI cards inside UI cards.
- Do not add unsafe HTML rendering for Nostr content.
- Sanitize all event-sourced URLs before rendering.

## 13. Documentation Tie-In

The `/docs` folder can document the design system once implementation expands.

Recommended docs:

- `/docs/design-system.md`: colors, typography, spacing, components.
- `/docs/content-guidelines.md`: tone, protocol language, relay usage guidance.
- `/docs/nostr-data.md`: relay-facing event kinds, tags, validation, and query patterns.

## 14. Design Acceptance Criteria

- The site clearly reads as LAYER.systems in the first viewport.
- The visual direction feels inspired by `einundzwanzig.space` but has its own orange Nostr relay identity.
- The relay endpoint is visually central, not secondary.
- The interface remains readable and usable at 360px width.
- Motion respects `prefers-reduced-motion`.
- UI contrast meets WCAG 2.1 AA.
- The design avoids generic orange SaaS styling.