E5 · Friend request to a nickname

You met someone in an event chat. They're private, so you only know them as DrunkBeaver67. This is how you ask to know them for real — and the only route by which a private account can be reached at all.

1 · Tap the nickname in chat

23:41YEREVAN

DrunkBeaver67alias23:18

first time here — is the second room open too, or just the main floor?

Narek K.23:22

both rooms open after midnight

DrunkBeaver67

NICKNAME · THIS EVENT ONLY

You can't see who this is, and we won't tell you. Ask them. If they accept, you'll see their real name here and everywhere else.

2 · Sent — and it stays a nickname

23:42YEREVAN

Sent2 PENDING

DrunkBeaver67

Met at Analog Only · 23:42

PENDING

SleepyRaven04

Met at Sunset Sessions · 05 JUL

PENDING

These two might be the same person. You will never find out from this screen — no "already sent", no merging, no shared status. Each nickname stands alone until someone chooses otherwise.

Received

Karen A.

Sent 2 days ago

What they see: "DrunkBeaver67 from Analog Only wants to be friends" — with your real name, because you're public. A private sender appears under their own nickname until they accept.

FEEDDISCOVER+EVENTSME

3 · Accepted — the mask comes off

23:47YEREVAN

You're now friends ● ACCEPTED

A Anna S.

You met her as DrunkBeaver67. She chose to show you.

— she appears as herself from here on —

Anna S.23:18

first time here — is the second room open too, or just the main floor?

Anna S.23:47

found you! see you by the booth

It applies backwards. Her earlier messages in this room are hers now too — the nickname was a display layer, not a separate account.

And it can't be undone by unfriending. You already know who she is. Removing a friend hides future events, not memory. The app should never pretend otherwise.

Notes — this is a good idea with one sharp edge. The route is right: a private account is unreachable by search or by profile URL, so the nickname in a chat is the only door, and it only opens if the person on the other side opens it. Consent is the whole mechanism.

The sharp edge is correlation. If you send a request to DrunkBeaver67 at one event and SleepyRaven04 at another, and the app ever says "already sent", silently merges them, greys one out, or shows them resolving together — it has just told you the two nicknames are the same person, which is precisely the attack the alias system exists to prevent. Two pending requests to the same profile must therefore look and behave exactly like two requests to two strangers, and acceptance must resolve only the one that was accepted.

Three more rules this flow needs: a blocked sender's request must appear to send and quietly go nowhere; requests-from-events must be rate limited, or a chat becomes a mailing list for whoever wants to spam forty people; and a private user needs a switch to refuse nickname requests entirely. None of these are in the schema yet — this flow adds scope to Phase 5, and that should be a deliberate decision rather than a discovery.