Skip to content

ADR 021: Adding shipmates to a crew directly

  • Status: Accepted
  • Date: 2026-11-03
  • Deciders: Owner (plan "add a shipmate to the crew directly" and its answers, 2026-11-03; the plan was removed once built)
  • Technical Context: apps/server; behaviour in docs/specs/server/sharing.md and emails.md

Context

A crew member joins a trip only through the crew link (ADR 010): copy it, send it in a messenger, open it, sign in, tap Join trip. Sailors sail with the same people again and again. Once two people were on board together, the next trip should take one tap, and the person added should learn about it by email, with a way to open the trip and a way out.

Decision

  1. Shipmates are everyone on board together: owner, skipper and crew of a shared trip are each other's shipmates (owner), worked out from today's memberships with one query object (Shipmates), no table of its own. Leaving every shared trip ends it.
  2. Adding needs no confirmation by the added person: they are on the crew at once, as crew, and get an email. A profile setting "Shipmates may add me to trips directly" lets them opt out, on by default (owner); every email links to it and has "Leave it".
  3. Who adds: everyone with invite_crew (ADR 020), so crew too. Only their own shipmates; 20 adds an hour.
  4. The email's links are today's magic links with a target (owner: "build on our current sign-in"): 30 minutes, once, confirm page. A link opened later keeps its target through a new sign-in, and opens it directly when the browser is already signed in as that user (both since PR 129). "Leave it" also needs the sign-in (owner) and lands on a confirm page, so mail scanners can't leave.
  5. The map in the email is inline (cid:), drawn in the mail job when no current preview image is stored, so no image URL with a token goes out by email.
  6. Owner's answers to the open questions: no email to the owner when someone else adds a crew member; a newly added person is everyone's shipmate on that trip at once; no undo.

Consequences

  • New data: users.shipmates_may_add, crew_memberships.source and added_by_id (nullified when the adder's account is deleted; the added person's membership stays). The privacy page describes direct adding and the email; the privacy version stays 2 because the processing is part of the crew sharing already agreed to, and the person can opt out and leave.
  • The adder sees only names they already see on shared crew cards, masked emails for people without a name.
  • A crew member can now change a trip's crew without the owner: owner and skipper see "added by " and can remove them.
  • Quality goals affected: Q1 Privacy by consent: no new outside service, data removed with the account, opt-out and leave in every email; Q3 Access safety: the user id in the request is resolved only among the adder's addable shipmates (404 otherwise, ADR 015), rate-limited.