# SimSim Us — V0.001 implementation and experiment boundary **September 18, 2026 · E02 implementation note.** [Open SimSim Us](/us/). This is a small standalone pairwise experiment, not a full personal Universe or an implemented generalized SimSim Protocol. It complements the protected First Light workstream. The historical 30-round review does not cover this later implementation. ## What the pilot does 1. Create a temporary browser identity and a small card: an alias, interests, allowed activities, time window and pace. 2. Preview the card and approve the stated two-hour comparison purpose. No card is saved before approval. 3. Create a one-use invitation QR and private link. The other person scans with their phone's camera, or opens the link. Scanning alone grants no data access or consent. 4. The recipient previews and approves their own card. Only one recipient can redeem the invitation. 5. Rules compare the two cards. Both must allow the suggested activity and select the same time window. Quiet pace wins if either asks for it. Shared interests explain an overlap but are not compulsory. 6. Each person privately chooses “I'd do this” or “Not for me.” The API never returns the other's individual answer. A mutual yes reveals only the two selected aliases and the proposed activity. No contacts are exchanged, messages sent, venue booked or attendance inferred. 7. Either person can optionally record Yes, Maybe, No or Didn't happen as a private outcome. It is not shown to the partner. They can also delete the shared session. There is no LLM dispatch, compatibility percentage, automated notification, room-wide search, paid compute or model training. Voice recording and transcription are not implemented; optional phone keyboard dictation is controlled by the device and its provider, not this site. Those device settings may involve their own processing. ## Deliberately limited constraints The pilot supports only one-to-one public-place activity suggestions, in a standalone Đà Lạt context. Unchecked activities are excluded. Today and this-week choices must match. Quiet/either controls pace. It does not interpret arbitrary free-text dealbreakers, travel feasibility, medical needs, venue accessibility or real availability. Someone whose constraints do not fit these choices should skip the pilot rather than assume the system understood them. No dating profile or sensitive personal history is requested. Participants affirm they are adults; there is no identity or age verification. The suggestion is exploratory. Humans must independently agree on safe, accessible practical details. A yes is not a binding commitment; end the session to withdraw. Declining produces no public rejection receipt. Mutual interest can naturally reveal that both said yes; the pilot cannot prevent participants from voluntarily discussing or photographing the result. ## Data and authority boundary The site server receives the selected cards for comparison. This is not a claim of local-only or end-to-end encrypted processing. Browser-session secrets are random and held in a Secure, HttpOnly, SameSite cookie; only hashes are stored in the application database. The separate one-use invitation token is kept in the URL fragment rather than query parameters. The browser removes that fragment after reading it. Anyone who obtains an unused invitation can join; it should be shared deliberately. The partner sees only a proposed shared activity, explicitly common interest signals, the selected window/pace, and—after two yes answers—the alias. No endpoint reveals their whole card, individual vote or feedback. Card choices become immutable for the invitation. To change them, end the session and make another; old approval cannot silently apply to a new proposal. Each API request enforces access deadlines. Sharing and identity access expire after two hours. On the next pilot request, expired names, cards and proposals are removed from the active application table. Owner-only feedback, credential hashes and minimal own-event history remain accessible for seven days from creation; after that they are inaccessible and removed on the next pilot request. This request-driven cleanup is not a scheduled guarantee of physical deletion at the exact deadline. Either participant may immediately end and remove the whole session, including both people's feedback. This is intentionally a temporary experiment, not a durable journal. Hosting-provider logs and backups are not promised instant erasure. Do not enter private memories or sensitive identifiers. There is no third-party analytics or training collection in the pilot code. Losing the browser cookie loses access; no account recovery or permanent archive is promised. At most 200 retained sessions fit this initial pilot; no IP profile or hidden social graph is used to fill missing data. ## Correctness checks and remaining limits The API uses optimistic revision checks for joining and answering, a stable session identity, private non-cacheable responses, origin checks on writes, bounded payloads and a fixed allowlist. Expiry, deletion and a stale tab cannot authorize a new session's actions. A failed response should be followed by refresh to inspect the last saved state, not an assumption of success. Automated tests cover policy and database behavior with a local SQLite adapter: one-use join, private responses, mutual reveal, concurrent votes, denied origin, no-overlap, stale session, expiry and deletion. These checks do not establish actual provider retention, human comprehension, practical meeting safety, subjective value or causal benefit. A published pilot is not a validated product. ## The smallest human test Arrange one voluntary pair or a small controlled event with organizer approval. Ask people to use the flow without coaching, keeping ordinary accessibility help available. Observe what they think they shared and what mutual acceptance means. Later, invite each person to report privately whether the possibility happened and felt worthwhile. Do not treat no feedback as failure or “didn't happen” as evidence that the people were incompatible. The standalone room is not embedded in Dalat.app and has no access to its event attendance. A future integration needs its actual API, permissions, approved event context and operational support. A P1 pool and P2 agent negotiation remain proposals.