Toko · Phase 3 · Consistency reference

Friends list — states gallery.

First-pass mock for the friends list, per Design Documentation/Phase3/friends-list-design.md (proposed 2026-07-03 — most decisions are proposals for review). Friendships are keyed by the Toko User ID (usr_…) — decided — and are mutual (request / accept), one row per pair. V1 utility: the wallet transfer picker, Recipient::User suggestions in revenue presets, and profile shortcuts. The list is private to its owner — no public counts, no mutual-friends display. Blocks are separate, one-way, and silent.

01Friends page · populatedOwner-only surface (placement open: profile section vs its own page). Accepted list with profile links and remove; incoming requests (accept / decline); outgoing requests (cancellable). Declines and removals are silent to the other side.
Account/Friends
Account · Friends

Friends.

Your private list — only you can see it. Add a friend with their User ID (it's on their profile).

Requests

2 incoming · 1 outgoing
Mara Okafor
usr_8H2K…M4Q · wants to be friends
Jonas Feld
usr_2X9C…A7T · wants to be friends
nightowl.icp
usr_5T1P…R2W · request sent — waiting

Friends

3
Selo Arts
usr_9D4F…K8L
kiln&wheel
usr_3M7B…X1E
Petra V.
usr_6Q2N…J9S
02Empty stateStandard centred empty hero (max-width 920, per the shell). The copy teaches the add gesture: paste a friend's User ID — theirs is on their profile.
Toko character art
No friends yet.

Add a friend with their User ID — you'll find it on their profile as a copyable chip. Friends make gifting tokens and picking payout recipients quicker.

03Add friend · exact User ID, resolve-before-sendV1 adds are by exact usr_… ID only — no name search (display names aren't unique; exact-ID adds avoid discovery/spam surface). The ID must resolve to an existing account before Send enables (the resolve-before-save pattern). Self-add is rejected; an existing pending/accepted pair short-circuits idempotently.

Add friend

We couldn't find an account with that User ID. Check it and try again.

They'll get a request to accept — you'll be friends once they do.

04Transfer picker · the V1 payoffThe wallet transfer modal offers "Choose a friend" beside raw principal entry — no more copy-pasting principals to gift a token. The transfer still settles through normal validation; how a User ID resolves to a receiving account is an open backend question (likely the account's primary principal).

Transfer · Fern Keeper #018

Or choose a friend
Selo Arts usr_9D4F…K8L
kiln&wheel usr_3M7B…X1E
Petra V. usr_6Q2N…J9S
05Remove friend · canonical destructive confirmThe one canonical delete/confirm shape: left-aligned, red warning icon, red action — no character art, not centred. Removal is one-sided and silent; the other side simply no longer sees the friendship.

Remove friend · kiln&wheel?

This removes kiln&wheel from your friends list. They won't be notified. To be friends again, one of you sends a new request. This can't be undone.

Note (not UI) — open questions

From friends-list-design.md: mutual vs one-way follow (mutual proposed — fits the gifting use case; follow could arrive later as a separate thing); placement (profile section vs dedicated page); request limits / rate limits / a manage-blocks list; whether public profiles get an "Add friend" button (still resolving to a request) or paste-the-ID is enough for V1; and the User ID → receiving-account resolution rule for transfers (backend to confirm). Friend request / accepted notifications route through the standard bell (see the Notification system gallery); declines and removals are silent. Explicitly not V1: activity feeds, seeing a friend's holdings, messaging, presence.