CONSENT IN THE INTERFACE

A reveal takes two yeses.

Turning mutual choice into explicit states, with time to talk and a clear decision from both people.

1 min read

Separate eligibility from consent

An anonymous conversation can give people space to talk before choosing to share a profile. Conversation rules decide when a request becomes available; they cannot decide the answer for the other person.

The product design calls for an active session, five minutes of conversation and a message from each person. Then the other person gets a separate decision. This is a design note: blind chat is not open in Blink yet. It is coming soon.

Make a no meaningful

A declined request leaves names and photos hidden and disables further requests in that session. This avoids turning the same button into repeated pressure. Ending or blocking the conversation is terminal and cancels a pending reveal.

Both profiles are disclosed only after acceptance. The requester cannot accept their own request. If an ordinary chat already exists after a reveal, reopening it is clearer than creating duplicate conversation threads.

Protect the decision, not just the animation

When blind chat opens, Blink’s servers must enforce elapsed time, session rules and each person’s action. Hiding a photo in an interface is not enough if its URL has already been sent to the other client.

Requests can race with an end or a block. A service needs to resolve those events consistently, reject stale actions and avoid revealing private profile data before consent. Those are service requirements, not effects that a screen animation can supply.

A person still chooses what to say

An anonymous interface cannot stop a person from typing their own name, handle or address. Clear copy and a useful safety guide matter alongside the state machine. Two explicit yeses should remain the rule whenever the product itself reveals the profiles.

a little closer.

Maybe you’ve already crossed paths.