Profile and details

3.4 Profile tab

Top bar: the active profile’s avatar and first name (tap: profile switcher, a list sheet that always offers Add profile, whatever the account has) and the gear for Settings. There is no Edit mode: every row opens its own sheet (A105). Mock: mobile/design/redesign/redesign-round-5.html and redesign-main-screens.html (direction C).

Content, under the title “Profile”:

1. Profile header: 52 dp avatar, default name, profile kind (“Your profile” / “Managed profile · Child”).
2. View as: filter chips Me, then one per circle. Me (the default) is your own view below. Choosing a circle replaces the sections with your card exactly as that circle receives it, read-only, from preview_circle(<circle id>) (the same function Circle details uses, Circles §3.2.1), with the line “As Family sees you. Choose Me to edit.” Nothing about visibility is computed on the device for this view.
3. Names, Phone numbers, E-mail addresses, Addresses, Special dates, Photos: one section each (v2’s six), headed by the category icon and name with Add on the right. Every row shows the type label (with ” · not verified” in warning where it applies), the value, and under it the circle labels of the circles that see it (“Family”, “Friends (city only)”); a detail shared with nobody shows “Only you · choose” in warning. Tapping a row opens its detail sheet; tapping its circle labels opens Who sees it directly. Long-press a row to reorder it within its section (photos by dragging their tiles).

The Profiles card of the first design is gone: switching and adding profiles live in the switcher sheet.

3.4.1 Detail sheets

Editing is one detail per bottom sheet (A105), replacing the category edit pages and their unsaved-changes guard. The sheet is titled with what it edits (“Mobile number”, “Home address”, “Birthday”) and holds, top to bottom: the type picker (and the country picker where it applies), the value fields, the Findable by this … switch where the category has one, Who sees it with the circle labels and Change (or two such rows for dates), and Cancel / Save … (“Save number”). Delete sits in the sheet’s title row in danger, and asks first. Adding opens the same sheet empty. The same sheets serve onboarding’s Build your card (Sign-in and onboarding §2.2), whose per-category rules (lengths, validation, defaults) apply here unchanged.

Values are written on Save; visibility and searchability are written at once when changed in the sheet, as before: choosing circles on a detail whose value is half-typed writes that detail’s circles only and leaves the value unsaved until Save. Cancel or dragging the sheet away discards the unsaved value without asking, because one sheet holds at most one detail. A detail the server does not have yet is written entirely on Save (2026-09-13).

Category	Sheet specifics
Names	One default; the others offer Make default. Deleting the default requires choosing another first. The default name is shared with all connections; its sheet says “Always visible to your contacts” in place of Who sees it.
Phones	Country + number with E.164 formatting; searchable switch; “Unverified” label. Changing a number resets is_verified.
E-mails	The sign-in e-mail is marked “Sign-in address” and edited via Settings → Account. Verify button sends a code; searchable only when verified — and the sign-in address counts as verified, because Supabase Auth proved it at sign-up, so the server sets is_verified on any row that carries it (ruling A70) and its switch is on from the start.
Addresses	Country-specific field order; Share as a segmented control Whole address / Per field, per field one Who sees it row under each field name; the NL postcode lookup appears under the fields as a suggestion with Use, never a silent overwrite; “Copy from …” action to duplicate another profile’s address (Marieke’s scenario).
Dates	Day, month and an optional year (“Year is optional”); two rows, Who sees the day and month and Who sees the year; year circles ⊆ day-month circles, and a tip box: “Share the day widely and the year narrowly. Only circles that see the day can see the year.”
Photos	The Photos section shows four tiles with each photo’s circle labels under it; the first carries an “Avatar” badge (“The first one is your avatar for everyone who may see a photo”). Drag to reorder; tap a photo for its sheet (replace, delete, type, Who sees it); an empty tile adds one. Upload shows progress; failure keeps the old photo.

Types and custom types

Each category has system types and user-defined custom types (v2’s CustomType):

Category	System types
Name	Personal, Work
Phone	Mobile, Home, Work
E-mail	Personal, Work
Address	Home, Work
Date	Birthday, Anniversary
Photo	Personal, Work

The type picker is a sheet listing system types, then custom types, then “New type…” (max 30 characters, unique per category and profile). Custom types can be renamed and deleted from the picker’s edit mode; deleting one that is in use asks to pick a replacement. Types are per profile and are sent to connections as the label on the shared detail, translated for system types and verbatim for custom types.

Who sees it (circle sheet)

One component used everywhere a detail’s visibility is set (round 2, sheet variant). A bottom sheet with:

• the title “Who sees your home phone?” and the value under it;
• shortcuts All circles and No one;
• one row per circle: checkbox, dot, circle name, member count (“8 people”); the checkbox is the only control, so a whole row is the touch target;
• for dates: two sections, Day and month and Year; a circle that does not see the day is dimmed in the Year section with the reason “Needs the day and month first” (subset rule);
• for addresses in per-field mode: opened per field from that field’s row;
• a primary Done that says the result: “Done · 12 people see it”, or “Done · only you” when nothing is ticked.

Ticking writes circle_ids at once and triggers snapshot refresh; the detail’s circle labels update when the sheet closes. Because adding a circle can reveal a detail, closing the sheet after an addition shows the toast “Now visible to Book club (5 people)” with Undo. Removing a circle needs no confirmation.

Verification

• Sign-in e-mail: verified by Supabase Auth.
• Additional e-mails: verify-email-detail sends a 6-digit code valid 15 minutes, max 5 attempts, 3 sends per hour per address. Verified e-mails show a check badge; unverified show a dashed badge and “Verify” link.
• Phones: unverified at launch; the badge says “Unverified” with an info sheet explaining that connections see the number regardless and that verification affects only searchability, which is disabled for unverified numbers.

Searchability

A detail marked searchable produces hashed search tokens; the row shows a small magnifier badge. Settings → Privacy → Findable by summarises them. Turning off searchability removes the tokens immediately.

Managed profiles

A managed profile has the same editors. Its rows carry the managed profile’s own circles (seeded Family, Friends, Work), so a child’s details can be shared with the child’s friends’ parents without touching the parent’s circles. The top bar shows the managed profile’s avatar and first name while it is active. A managed profile also carries its relationship label (managed_relation: child, parent, partner or someone else), chosen in Add profile and shown in the profile card. It is display-only.

Profile deletion

In the profile header’s overflow menu, for managed profiles only: Delete profile (confirm sheet listing the number of connections that will lose the card). Deleting calls delete_profile, which tells every one of those connections before the rows go; a client can no longer delete a profile row directly. The main profile is deleted only with the account.

Business rules

• At most 20 names, 20 phones, 20 e-mails, 10 addresses, 30 dates, 4 photos per profile (server constraints). Enforced by triggers since phase 3; the client shows errors.too_many_details when one fires.
• Whitespace-only values are rejected; values are trimmed once at the boundary.
• Every change bumps profiles.version; connections see the change after snapshot refresh (typically within a second) and receive a contact_updated notification per changed card; while an unread contact_updated for that connection exists, insert_notification drops the new one, so a burst of edits becomes one notification (A56).