> Superseded by [field-manual.md](field-manual.md) §3.1 and §4 — the live wizard at /get/ replaces the honest pre-wizard path described here. See [INDEX.md](INDEX.md).

# DAMM Onboarding Flow

## Goal

Give a new user a flow that feels like:

1. download an app
2. point it at a DAMM server
3. get connected

without lying about what is actually happening under the hood.

## Current Honest Flow

Today, the clean DAMM onboarding path is:

1. install a native WireGuard client or use native OS VPN integration
2. obtain a DAMM-generated profile bundle
3. inspect or handle the profile in the DAMM browser companion if desired
4. import the profile into the native client
5. activate the tunnel

This is not yet a first-party “type server URL and sign in” experience.

## Why The Current Flow Looks Like This

Because the actual tunnel should live in:

- WireGuard for iPhone
- WireGuard for macOS
- WireGuard for Android
- `wg-quick` or NetworkManager on Linux

The browser companion is there to improve:

- install guidance
- profile inspection
- support export
- reissue and replacement clarity

It is not there to pretend it owns the tunnel.

## What “Point It At A Server” Means In DAMM

For DAMM, a real “point it at a server” flow should mean:

1. the user installs the DAMM companion or first-party app
2. the user enters:
   - server URL
   - enrollment token or account auth
3. the device generates its key locally
4. the client enrolls against the control plane
5. the client receives peer material and trusted catalog metadata
6. the resulting profile is handed to the native WireGuard client or OS integration

This is a valid future direction.

## What It Should Not Mean

It should not mean:

- the browser itself acts as the VPN tunnel
- iPhone Safari becomes a real WireGuard endpoint
- the device private key leaves the device
- the client blindly trusts unsigned route changes

## Minimum Future DAMM “Server URL” Product Shape

To offer a proper server-driven onboarding path, DAMM would need:

- browser or native key generation for WireGuard-compatible client keys
- a simple enrollment form:
  - server URL
  - enrollment token
  - device name
  - optional region or exit policy
- profile export or direct handoff into the native client
- local persistence of trusted catalog metadata
- reissue and diagnostics support

## Short-Term Product Recommendation

Until a full first-party app exists, the right DAMM onboarding surface is:

- native WireGuard app for the tunnel
- DAMM companion page for install and profile handling
- generated bundle as the source of truth

That keeps the user path direct without pretending a capability the product does not yet have.

## Ideal Copy For The Landing Page

The landing page should say, plainly:

- download WireGuard for your device
- open the DAMM client companion
- load or receive your DAMM profile
- import it into WireGuard
- connect

And, when the server-driven flow exists later:

- enter your DAMM server URL and token
- DAMM will prepare your local profile
- hand it off to the native client