# Synantisi Protocol

> **18+ ONLY. ALL PARTICIPANTS MUST BE ADULTS.**
>
> **STRICTLY NON-SEXUAL AND PLATONIC.** Synantisi is for friendship, shared
> interests, conversation, activities, language exchange and professional or
> community networking. It is not a dating, hookup, sexual-contact or erotic
> service.
>
> **NO UNSOLICITED FREE-TEXT MESSAGES.** A person may receive only a neutral
> invitation after both profiles pass a mutual match. Free-text chat opens only
> after both people explicitly accept.
>
> **NO PRIVATE DETAILS IN SHARED PROFILES.** Do not include telephone numbers,
> email addresses, home or work addresses, exact locations, full legal names,
> school or employer details, financial information or live travel plans.
> External-service handles may be released only in a separate contact card after
> the owner reviews it and confirms the release manually.
>
> **TIME-LIMITED AND OFF BY DEFAULT.** A session starts only after the user
> confirms it, displays a countdown and stops automatically at expiry.
>
> **THIS MARKDOWN FILE CANNOT CONTROL BLUETOOTH.** It defines behaviour and can
> drive a simulation. Real nearby discovery and chat require a signed native
> Android/iPhone application, operating-system permissions and an explicit
> software bridge made available to the AI.
>
> **MARKDOWN IS NOT A SECURITY BOUNDARY.** Anyone can read or alter a public
> protocol file or build a modified client. Age gates, consent, authentication,
> encryption, expiry, rate limits, blocking and moderation MUST be enforced by
> trusted application code and, where used, the service backend.

```yaml
protocol_manifest:
  name: Synantisi
  greek: "Συνάντηση"
  meaning: "meeting or encounter"
  version: 0.1.1
  status: "Draft / research and UX prototype"
  date: 2026-08-25
  minimum_age: 18
  adult_only: true
  sexual_or_dating_use: prohibited
  default_session_minutes: 30
  maximum_session_minutes: 120
  activation: explicit_user_confirmation
  profile_in_bluetooth_beacon: prohibited
  free_text_before_mutual_consent: prohibited
  private_details_in_shared_profile: prohibited
  introduction_after_mutual_acceptance: true
  contact_release_requires_separate_manual_consent: true
  native_app_required_for_bluetooth: true
```

## 1. Purpose

Synantisi is an opt-in protocol for helping nearby adults discover a mutually
welcome reason to talk. It is intended to recreate the useful part of informal
Bluetooth-based social discovery without broadcasting personal adverts or
allowing strangers to send arbitrary messages.

Example contexts include:

- railway journeys, railway exhibitions and transport-interest events;
- birdwatching, walking, photography and local-history activities;
- conferences, large halls, cafés and community events;
- meeting other adults interested in AI, languages, engineering or a hobby;
- finding a platonic conversation or activity partner nearby.

Synantisi does not claim that two detected phones are in direct sight of one
another. Bluetooth range is not a fixed 25-metre circle. Bodies, walls, windows,
radio power, interference, reflections and metal structures can weaken,
strengthen or distort reception. A person detected in a train, hall or building
may be farther away, on another floor or outside.

## 2. Non-goals

Version 0.1 does not provide:

- dating, romance matching, hookups or sexual contact;
- access for anyone under 18;
- anonymous random chat with every Bluetooth device;
- a public list of everybody nearby;
- exact location, distance, direction or line-of-sight claims;
- background visibility that remains on indefinitely;
- automatic messages written or sent by AI;
- a claim that a self-declared profile is necessarily true;
- protection merely because fields are compressed into bits or short codes;
- Bluetooth functionality from a Markdown file alone.

Physical appearance fields such as hair colour, body measurements and clothing
are excluded from the v0.1 discovery and matching schema. An ordinary message
after mutual consent may refer politely to the shared situation, but the system
must not encourage surveillance-like openings such as “I can see you.”

## 3. Normative language

The words **MUST**, **MUST NOT**, **SHOULD**, **SHOULD NOT** and **MAY** describe
requirements for a conforming implementation.

## 4. Core safety rules

1. Every participant MUST be at least 18.
2. Every session MUST be platonic and non-sexual.
3. Discovery MUST be off by default.
4. Motion or location MAY suggest a session but MUST NOT activate one.
5. The user MUST choose or confirm the session duration.
6. The session MUST visibly count down and automatically expire.
7. The discovery signal MUST NOT contain a name, social handle, exact age,
   gender, photograph, location, permanent account identifier or preference
   profile.
8. A match MUST be mutual: each participant's private profile must satisfy the
   other's private acceptance rules.
9. Before mutual acceptance, the only permitted approach is a neutral system
   invitation. User-written free text MUST NOT be delivered.
10. Both participants MUST independently accept before chat or contact sharing.
11. A longer introduction file MUST remain private until both participants have
    accepted the invitation and its owner has approved the exact preview.
12. A contact card MUST be a later, separate consent event. It MUST NOT contain
    a telephone number, email address or other prohibited private detail.
13. AI MAY draft a message but MUST NOT send it without the sender's explicit
    confirmation.
14. Declining MUST be silent to the other person apart from a neutral
    “unavailable” result.
15. Blocking MUST prevent further invitations from the blocked account or its
    resolvable replacement identifiers.
16. Reporting and emergency-stop controls MUST be prominent during a session.
17. The application MUST NOT describe Bluetooth signal strength as a precise
    distance or proof that somebody can be seen.

## 5. Components

| Component | Responsibility |
| --- | --- |
| Synantisi Markdown | Canonical rules, data meanings, AI instructions and conformance tests |
| Native mobile app | Permissions, timer, Bluetooth/nearby transport, notifications, encrypted storage and enforcement |
| Synantisi AI assistant | Conversational setup, structured preference parsing, explanations and optional message suggestions |
| Private profile Markdown | User-owned answers, match settings, introduction draft and a separately sealed contact card |
| Match service (recommended for v0.2) | Private mutual-match decision, rotating-token validation, rate limits and abuse controls |
| Nearby transport | Discovery and encrypted data exchange between compatible implementations |
| Aletheia record | Provenance for protocol decisions and minimal consent receipts; not an encounter diary |
| Thalia option | Positive, non-sexual icebreakers after mutual consent only |

## 6. User experience

### 6.1 Create a private profile

The AI may ask conversational questions and convert the answers into the
structured schema in section 7. It MUST show the interpretation for correction
before saving it.

Example:

> “I am at a railway exhibition for about 45 minutes. I would be happy to talk
> to another adult interested in railway history, engineering or AI.”

The assistant may propose:

```yaml
session:
  duration_minutes: 45
  purposes: [hobby_conversation, friendship]
  interests: [railways, railway_history, engineering, artificial_intelligence]
  minimum_shared_interests: 1
  adult_only: true
  contact_release: separate_manual_consent_after_mutual_acceptance
```

The user must confirm this summary.

### 6.2 Context suggestion

With separate permission, the native app MAY detect walking, stationary,
cycling or in-vehicle states, or entry into a user-saved venue. It may then send
a notification such as:

> “You appear to be walking near a saved social venue. Start Synantisi for 30
> minutes?”

Rules:

- The notification MUST require a tap and a confirmation screen.
- Walking or entering a geofence MUST NOT start Bluetooth discovery itself.
- A precise location MUST remain on the device unless the user explicitly
  chooses otherwise.
- Prompts SHOULD be rate-limited, with a default of no more than one contextual
  prompt per venue or context per day.
- A driving state MUST suppress prompts. A passenger or rail-travel session
  should be started manually.
- Motion and location prompting MUST have independent off switches.

### 6.3 Start a timed session

Recommended choices are 15, 30, 45, 60, 90 and 120 minutes.

- Default: 30 minutes.
- Maximum without renewed confirmation: 120 minutes.
- Extending a session requires a new explicit confirmation.
- Turning off Bluetooth, revoking permission, pressing STOP, signing out or
  reaching expiry ends discovery immediately.
- Closing the user interface does not extend the timer.

### 6.4 Discovery and mutual match

The user is not shown a catalogue of nearby people. The app evaluates mutual
eligibility privately. If a mutual match exists, each user may receive:

> “An adult nearby is also open to a conversation about railway history. Send a
> neutral invitation?”

The first user's confirmation creates an invitation. The second user may accept
or decline. A decline reveals no personal explanation.

### 6.5 Conversation

After both users accept, the app opens a private chat. The AI may offer an
editable icebreaker, for example:

> “Hello. I’m also interested in railway history. Is there a particular line or
> period you’re here to see?”

It MUST NOT send automatically.

### 6.6 Contact exchange

A contact card is a separate consent event. Both people may chat without sharing
an external account. The owner chooses a service and manually enters or selects
the exact public username, handle or profile URL to release. Examples include
Telegram, Instagram, WhatsApp, LINE, Facebook, Signal or another registered
service. Two-letter display labels such as `WA`, `TG`, `IG`, `FB` and `LI` MAY be
used in the interface, but the transmitted record uses an unambiguous service
name and URI or handle. A platform's current account rules must be checked by the
app; the protocol does not assume that every service supports a phone-number-free
username.

No handle or profile URL may appear in the discovery beacon or introduction
file. The contact card MUST NOT contain a telephone number, email address, postal
address, exact location or a hidden tracking parameter. The app shows the entire
card, identifies the recipient and asks `Share this contact card now?` The AI
cannot answer that question for the user.

### 6.7 Standard input questions

The companion `synantisi-profile-template.md` is the fillable input document.
It separates private matching values from material that may later be shared.
The AI SHOULD ask the following questions one at a time and permit `skip` for
every optional answer:

1. Confirm that the user is 18 or over.
2. Choose a pseudonym for this session.
3. Choose the session purpose: friendship, casual conversation, a hobby,
   activity partner, language exchange, community or professional networking.
4. List interests and subjects the user would be happy to discuss.
5. Describe what sort of platonic conversation or activity the user hopes for.
6. Add a longer “about me” introduction, if wanted.
7. Select languages spoken and the preferred language for this session.
8. State communication preferences, accessibility needs and boundaries that are
   safe to disclose.
9. Set private age-band, gender or interest matching preferences, if wanted.
10. Choose whether machine translation may be prepared for later approval.
11. Keep external contact handles in the separate contact-card section, or skip
    contact sharing entirely.

The form MUST NOT ask for an exact date of birth, telephone number, email
address, home or work address, exact present location, legal name, school,
employer, financial information, medical information or live itinerary. The AI
MUST NOT infer or fill any such field from other text.

### 6.8 Three-stage disclosure

| Stage | Contents | Who can see it | Release condition |
| --- | --- | --- | --- |
| Match card | Private structured purposes, interests and acceptance rules | Owner and trusted matching logic | Timed session is active |
| Introduction card | Pseudonym, broad interests, languages, boundaries and user-written introduction | One mutually accepted participant | Owner approves exact preview after both accept |
| Contact card | One or more selected public-service handles or profile URLs | One named chat participant | A later, separate manual confirmation |

The Introduction Card may be rendered as sanitized UTF-8 Markdown. Active HTML,
scripts, remote images, tracking pixels and automatic link opening are
prohibited. Before release, the app MUST show a plain-text preview, scan for
prohibited private details and ask the owner to confirm both the contents and
recipient. A warning must explain that a received file or screenshot can be
copied onward and cannot be remotely revoked.

### 6.9 Translation

Translation is optional. The original is authoritative and MUST be preserved.
A translated card includes the original language, target language, translation
engine or `human`, and a `machine_translation: true|false` label. The owner must
review the translated preview before release. The AI MUST NOT add facts, infer
sensitive characteristics or silently soften a boundary while translating.

## 7. Private profile schema

The following is a semantic schema, not a Bluetooth packet.

```yaml
synantisi_profile:
  schema_version: 1

  identity:
    account_public_key: "APP_CONTROLLED"
    display_name: "OPTIONAL_PSEUDONYM"
    adult_status: "known_adult_test | declared_18_plus | independently_assured"
    age_band: "optional_private_value"
    gender: "optional_private_value"

  intent:
    allowed_purposes:
      - friendship
      - casual_conversation
      - hobby_conversation
      - activity_partner
      - language_exchange
      - community_networking
      - professional_networking
    sexual_or_dating_intent: false
    interests: []

  acceptance:
    adults_only: true
    accepted_purposes: []
    accepted_age_bands: []          # optional and private
    accepted_genders: []            # optional and private; default is any adult
    required_interests: []
    minimum_shared_interests: 1

  contact_policy:
    chat_after_mutual_acceptance: true
    introduction_after_mutual_acceptance: true
    external_contact_after_separate_consent: true
    permitted_contact_services: []

  introduction_draft:
    pseudonym: "OPTIONAL"
    languages: []
    topics_happy_to_discuss: []
    looking_for: "OPTIONAL_PLAIN_TEXT"
    about_me: "OPTIONAL_PLAIN_TEXT"
    communication_preferences: []
    boundaries_safe_to_share: []
    original_language: "BCP_47_LANGUAGE_TAG"
    translation_requested: false

  sealed_contact_draft:
    release_state: "not_shared"
    entries: []                    # service + public handle/URI only

  controls:
    context_prompts: false
    walking_prompt: false
    saved_venue_prompts: false
    default_session_minutes: 30
    maximum_session_minutes: 120
```

All optional demographic filters remain private. They are never advertised and
must not be exposed as the reason for a rejection.

`introduction_draft` and `sealed_contact_draft` are stored locally with the
private profile but are not match inputs. They are never placed in the discovery
envelope. The application creates a fresh recipient-specific export only when
the relevant consent gate is passed.

For a closed test, `known_adult_test` is permitted when every tester is personally
known to be over 18. A public release requires a documented age-assurance and
safeguarding assessment; self-declaration alone must not be assumed sufficient.

## 8. Matching

### 8.1 Hard gates

A candidate fails immediately if any condition is true:

- either participant is not accepted as 18+;
- either session requests or permits sexual or dating use;
- either session has expired or been stopped;
- either account has blocked the other;
- the session purposes do not intersect;
- a mandatory private preference is not satisfied;
- the invitation or encounter rate limit has been exceeded.

### 8.2 Mutual rule

Let `accepts(A, B)` mean that B's private attributes and current session satisfy
A's private acceptance rules.

```text
mutual_match(A, B) =
    hard_gates_pass(A, B)
    AND accepts(A, B)
    AND accepts(B, A)
```

Only a true `mutual_match` may create an invitation opportunity.

### 8.3 Ranking

Ranking MAY use shared interests and current context after hard gates pass.
Protected or sensitive characteristics MUST NOT be inferred by AI from a name,
photograph, writing style or external profile.

The app may explain a match using positive shared reasons:

> “You both selected railway history and AI.”

It must not explain why other people were rejected.

## 9. Session state model

```mermaid
stateDiagram-v2
    [*] --> Off
    Off --> Suggested: optional local prompt
    Suggested --> Active: user confirms timer
    Suggested --> Off: dismiss
    Active --> MatchPending: mutual eligibility
    MatchPending --> Active: decline or timeout
    MatchPending --> Chat: both accept
    Active --> Expired: timer or STOP
    Chat --> Expired: timer, leave, block or STOP
    Expired --> Off
```

`Suggested` is not discoverable. Only `Active` and an explicitly continued
`Chat` may use the nearby transport.

## 10. Discovery and transport

### 10.1 Recommended v0.1 implementation path

The first radio prototype may use two Android phones because generic BLE
developer utilities make the discovery smoke test straightforward. That is not
a product architecture. A real Android-to-iPhone prototype requires a
purpose-built native application on both phones. Google Nearby Connections has
Android and Swift SDKs and supports encrypted connections plus byte, file and
stream payloads; dedicated Android BLE and iOS Core Bluetooth adapters are an
alternative if their lifecycle and security are implemented carefully.

The design MUST NOT assume that an Android phone can send an arbitrary file to
an iPhone merely because both devices have Bluetooth enabled or have accepted an
ordinary OS pairing request. AirDrop is an Apple-device feature, not the
cross-platform Synantisi transport. Until both native apps exist, a test
Introduction Card may be exchanged manually through an existing messaging app,
the operating-system share sheet or copy-and-paste after the same consent
preview.

The implementation must be honest about background limitations. The v0.1
prototype should operate in a visible foreground session. Background operation
is a later, separately tested capability.

### 10.2 Discovery envelope

The discovery layer carries only an opaque envelope:

```yaml
discovery_envelope:
  protocol: synantisi
  major_version: 1
  rotating_session_token: "random opaque value"
  expiry_bucket: "short-lived"
  capability_flags: []
```

It MUST NOT carry the profile schema from section 7.

The rotating token SHOULD change at least every five minutes and at session end.
It MUST NOT be derived directly from a username, phone number, permanent public
key or social handle. A server-backed version should issue or validate signed
opaque tokens. An offline version needs anti-replay protection during the
authenticated connection handshake.

### 10.3 Why the profile is not compressed into the beacon

Bit-packing can save space but does not create privacy. A public registry that
maps bits to age, gender, interests or appearance would allow passive observers
to decode, record and track people. Compression MAY be used inside an encrypted
authenticated channel; it MUST NOT be treated as encryption.

### 10.4 Connection

After discovery, compatible applications establish an encrypted authenticated
connection. Each endpoint must validate:

- supported protocol version;
- fresh session token and nonce;
- non-expired session;
- backend or app-level authentication where applicable;
- request and encounter rate limits.

The system pairing dialogue is not a Synantisi message channel and must not be
repurposed to display profiles or invitations.

### 10.5 Chat payload

```yaml
chat_payload:
  protocol_version: 1
  session_id: "ephemeral"
  message_id: "unique within session"
  created_at: "UTC timestamp"
  sender_role: "initiator | recipient"
  body: "user-confirmed UTF-8 text"
```

Messages must be encrypted in transit. Whether messages are retained locally
after the session must be clear to both users.

### 10.6 Introduction-file payload

After mutual invitation acceptance, either participant may offer a sanitized
Markdown introduction through the authenticated connection:

```yaml
introduction_file_payload:
  protocol_version: 1
  session_id: "ephemeral"
  message_id: "unique within session"
  media_type: "text/markdown; charset=utf-8"
  filename: "SYNANTISI_INTRODUCTION.md"
  byte_length: 0
  sha256: "digest of exact bytes"
  original_language: "BCP-47 tag"
  translated_language: "optional BCP-47 tag"
  machine_translation: false
  body: "sanitized user-approved Markdown"
```

The recommended v0.1 maximum is 16 KiB. The sender must approve the exact bytes,
recipient and language immediately before transfer. The recipient receives an
offer containing the pseudonym, approximate size and language, and may accept or
decline without opening it. The app verifies length and digest, treats Markdown
as untrusted input, disables active content and renders it without fetching
remote resources. Receiving an introduction does not authorize a contact card.

### 10.7 Contact-card payload

```yaml
contact_card_payload:
  protocol_version: 1
  session_id: "ephemeral"
  recipient_chat_id: "current accepted participant"
  entries:
    - service: "telegram"
      kind: "public_handle"
      value: "EXAMPLE_ONLY"
  owner_confirmed_at: "UTC timestamp"
```

Contact values are not matched, translated or guessed. Each export is shown in
full and confirmed manually. The receiving app MUST display the service name and
value as text before opening an external application.

## 11. AI behaviour

### 11.1 Permitted AI functions

The AI MAY:

- translate conversational preferences into the section 7 schema;
- ask the standard input questions and maintain a local profile Markdown;
- draft and privacy-check an Introduction Card;
- translate an Introduction Card while preserving and labelling the original;
- ask for missing duration, purpose or interests;
- show the interpreted session for correction;
- explain positive shared match reasons;
- draft a friendly, non-sexual icebreaker;
- summarize a conversation locally at the user's request;
- help report an interaction without overriding the user's account;
- call narrowly scoped native-app functions after user confirmation.

### 11.2 Prohibited AI functions

The AI MUST NOT:

- claim Bluetooth access when no native tool is available;
- enable discovery merely because the chat or Markdown file was opened;
- bypass operating-system permission or switch Bluetooth on silently;
- infer age, gender, sexuality or other sensitive facts from appearance or text;
- infer or insert private details that the user did not type;
- relax the 18+ or non-sexual rules;
- reveal a rejected or unmatched profile;
- send a message, invitation or contact card without confirmation;
- share, translate-and-share or open an introduction file without showing the
  final preview and receiving explicit confirmation;
- copy an external contact handle into an Introduction Card;
- continue a session beyond its timer without renewed confirmation;
- store a hidden encounter history in Aletheia or another memory system.

### 11.3 Conceptual native tool interface

An AI-enabled app may expose only constrained operations such as:

```text
get_synantisi_capabilities()
request_nearby_permission()
prepare_session(profile, duration_minutes)
confirm_and_start_session(session_id)
get_pending_invitation()
respond_to_invitation(invitation_id, accept_or_decline)
draft_message(topic)
confirm_and_send_message(message_id)
build_introduction(profile_id)
preview_introduction(introduction_id, recipient_id)
translate_introduction(introduction_id, target_language)
confirm_and_share_introduction(introduction_id, recipient_id, preview_digest)
preview_contact_card(service, value, recipient_id)
confirm_and_share_contact(contact_card_id, recipient_id, preview_digest)
stop_session()
block_user(encounter_id)
report_encounter(encounter_id, category)
```

`prepare`, `draft` and `suggest` do not transmit. Sending or starting requires a
separate confirmation action enforced by the native app.

## 12. Behaviour when loaded into an ordinary AI chat

If this Markdown file is loaded into a chat without a Synantisi native bridge,
the AI must enter **simulation mode** and say so. It must not imply that it can
see nearby phones.

Recognized commands:

| Command | Behaviour |
| --- | --- |
| `HELP` | Show the adult-only notice, available commands and current capability status |
| `CREATE PROFILE` | Build a private test profile and show it for correction |
| `ANSWER QUESTIONS` | Ask the standard profile and introduction questions one at a time |
| `BUILD INTRODUCTION` | Draft a sanitized Introduction Card from approved answers |
| `TRANSLATE <language>` | Prepare a labelled translation while retaining the original |
| `PREVIEW SHARE` | Show the exact Introduction Card, recipient and privacy warnings; do not send |
| `EXPORT INTRODUCTION` | After the consent gate, export approved test Markdown; otherwise refuse |
| `START 30` | In a bridged app, prepare and confirm a 30-minute session; otherwise simulate |
| `START 60: railways, AI` | Prepare a one-hour interest session |
| `STATUS` | Show mode, remaining time and whether a bridge is available |
| `STOP` | End the simulated or real session immediately |
| `TEST MODE` | Use fictional/non-sensitive data for the Thursday test |
| `EXPORT TEST PROFILE` | Create a copyable test-only profile envelope |
| `IMPORT TEST PROFILE` | Parse a copied test envelope and run the mutual rule |
| `INVITE` | Prepare a neutral invitation only after a simulated mutual match |
| `ACCEPT` / `DECLINE` | Respond to an invitation |
| `SHARE CONTACT` | Require separate confirmation; test mode uses a fake contact |
| `BLOCK` / `REPORT` | Exercise the relevant safety flow |

On load, the AI should display:

> **Synantisi v0.1.1 — adult-only, platonic nearby conversation.** Bluetooth
> status: unavailable unless this chat is connected to a compatible native app.
> Type `HELP`, `ANSWER QUESTIONS`, `CREATE PROFILE` or `TEST MODE`.

## 13. Security and abuse model

| Threat | Required response |
| --- | --- |
| Modified client ignores Markdown | Enforce hard rules in trusted code/backend; validate every input |
| Passive beacon tracking | Rotate opaque tokens; never advertise profiles or stable identifiers |
| Replay of an old invitation | Nonces, expiry and single-use invitation identifiers |
| Fake age or profile | Age-assurance design, verification options, reporting and risk controls |
| Repeated unwanted approaches | Per-account/device rate limits and durable privacy-preserving blocks |
| Proximity spoofing or radio relay | Do not claim visual proximity; use dwell checks and flag implausible patterns |
| Shared social handle copied onward | Separate explicit release and clear warning; minimize default sharing |
| Introduction contains accidental private data | Local privacy scan, plain-text preview and explicit recipient confirmation |
| Malicious Markdown or remote tracking | Sanitize input; disable active HTML, scripts, remote images and automatic URL opening |
| Received file is forwarded | Warn before release that exported material cannot be revoked; share the minimum |
| AI generates inappropriate text | Local rules plus moderation; user review before every send |
| Harassment in chat | Immediate block/report/stop; preserve only evidence intentionally submitted |
| Device compromise | Use OS secure storage; minimize retained secrets and encounter data |
| Denial-of-service scanning | Filter by service, cap requests and back off automatically |

Security must be independently reviewed before any public release. The protocol
must not invent its own cryptography when a well-reviewed authenticated channel
is available.

## 14. Privacy and retention

- Exact GPS location is not required for nearby matching.
- Motion and saved-venue prompting are optional and local by default.
- Ordinary discovery events should disappear when the session expires.
- Unmatched tokens should not be retained beyond what is strictly necessary for
  short-term security and rate limiting; the target maximum is 24 hours.
- Blocks may require a longer-lived keyed or hashed record but must not expose a
  public identity.
- Contact handles are released only after separate consent.
- Introduction drafts and contact drafts remain local and encrypted until their
  separate recipient-specific release events.
- The Introduction Card omits contact handles and prohibited private details.
- A translated Introduction Card retains the original and translation
  provenance; translation does not authorize sharing.
- Exported files and screenshots cannot be technically revoked from a
  recipient's device, so the user must see that warning before every release.
- Chat content is not sent to an AI model unless the user knowingly enables the
  relevant assistance.
- Aletheia may retain a minimal consent receipt or current preference with
  provenance, but not a default history of who was nearby, rejected or blocked.
- A Data Protection Impact Assessment and Online Safety assessment are required
  before a UK public trial.

## 15. Moderation and safeguarding

Public implementations must provide:

- published 18+ and non-sexual community rules;
- age-assurance and children's-access decisions appropriate to the service;
- prominent block and report controls;
- a staffed process for reports and urgent safety issues;
- sexual-content, harassment, grooming, threat and fraud controls;
- transparent moderation and appeal rules;
- invitation and messaging rate limits;
- a contact point for child-safety and law-enforcement duties;
- no encouragement to locate or confront an unknown person physically.

“Family-safe content” does not make an app safe for children. Synantisi v0.1 is
adult-only.

## 16. Thursday test — 27 August 2026

### 16.1 Aim

Test whether the profile, mutual-match, invitation, timer, consent, refusal and
safety language make sense to two adult users. Also test the new staged
Introduction Card and Contact Card. An Android phone and an iPhone are sufficient
for these simulation and manual-handoff tests. This is not yet a Bluetooth
interoperability or production-security test.

### 16.2 Required information

Record before testing:

```yaml
test_setup:
  tester_A_phone: "Android or iPhone; model and OS"
  tester_B_phone: "Android or iPhone; model and OS"
  both_known_over_18: true
  test_duration_minutes: 30
  real_contact_details_used: false
```

### 16.3 Test A — two-chat protocol simulation

This works without Bluetooth and tests the human interaction.

1. Open a separate AI chat on each phone and load this Markdown file plus
   `synantisi-profile-template.md`.
2. On each phone type `TEST MODE`.
3. Confirm that each AI states **simulation mode** and does not claim Bluetooth
   access.
4. Use fictional display names and no real social handles.
5. Suggested profile A interests: `railways`, `AI`, `walking`.
6. Suggested profile B interests: `railway history`, `cooking`, `photography`.
7. Both choose `hobby_conversation` and require at least one shared interest.
8. On each phone type `EXPORT TEST PROFILE`.
9. Copy A's export into B's chat using `IMPORT TEST PROFILE`, and B's export
   into A's chat.
10. Confirm both chats independently reach the same `MATCH` or `NO MATCH`
    decision and give only positive shared reasons.
11. Exercise `INVITE`, then accept on both sides.
12. On each phone type `BUILD INTRODUCTION`, then `PREVIEW SHARE`.
13. Confirm that no Introduction Card is exported until both simulated users
    accept and the owner confirms the exact recipient and preview.
14. Draft, review and simulate two non-sexual messages.
15. Repeat with one side declining. Confirm no free text or Introduction Card is
    revealed.
16. Exercise `BLOCK` and confirm a later simulated invitation is rejected.
17. Run a five-minute test session and confirm that it expires without being
    silently renewed.

Pass criteria:

- The 18+ and non-sexual notice appears immediately.
- Neither AI claims actual Bluetooth access.
- Both AIs interpret the same profiles consistently.
- No invitation occurs without a mutual match.
- No free text or contact detail is released before two-sided consent.
- An Introduction Card requires mutual acceptance and an owner-approved preview.
- A Contact Card requires a later, separate manual confirmation.
- Decline, block and STOP take effect immediately.
- The timer expires and remains off.

### 16.4 Test B — Android BLE discovery smoke test

Run this only if both phones are Android and both testers are comfortable
installing a Bluetooth developer utility. It proves that one phone can advertise
a harmless test service and the other can see it; it does not implement
Synantisi matching or chat.

Use the test-only service UUID:

```text
a72bfe62-3754-435a-97fa-e979095fca34
```

1. Install Nordic Semiconductor's `nRF Connect for Mobile` on both Android
   phones from the official app store listing.
2. On phone A create an advertisement containing only the UUID above and the
   temporary name `SYN-TEST-A`.
3. On phone B scan for the UUID.
4. Confirm detection nearby, through one interior wall and at a modest outdoor
   separation.
5. Record detection/no detection and diagnostic RSSI, but do not translate RSSI
   into an exact public distance.
6. Stop advertising and confirm phone B no longer receives fresh advertisements.
7. Delete the test advertisement configuration if it is no longer needed.

Do not put a name, age, photograph, social handle or real profile into this test
advertisement.

If either phone is an iPhone, skip Test B. This does not fail the Thursday test;
it records `SKIPPED — mixed platforms`. The practical radio step is a signed
native app on both platforms using an appropriate cross-platform nearby
framework.

### 16.5 Test C — iPhone-compatible introduction handoff

This tests the consent and file content without claiming that Bluetooth moved
the file.

1. Use fictional answers in `synantisi-profile-template.md` on both phones.
2. Deliberately put a fake email address or telephone-like test string in one
   draft, run `PREVIEW SHARE`, and confirm that the privacy check blocks export.
3. Remove the test string and rebuild the card.
4. Complete the mutual match, invitation and acceptance flow.
5. Export the approved test Introduction Card as Markdown on phone A.
6. Move it to phone B with copy-and-paste or an existing trusted family
   messaging channel. Record the handoff method as `manual`, not `Bluetooth`.
7. Confirm phone B sees the same pseudonym, interests, boundaries and original
   language. If translation is tested, display both original and labelled
   translation.
8. Confirm the Introduction Card contains no contact handle.
9. Use `SHARE CONTACT` with a visibly fictional handle. Confirm it requires a
   new manual preview and approval, then discard it after the test.

Pass criteria:

- Android and iPhone can complete the same protocol flow.
- The AI never claims the manual handoff was Bluetooth.
- The private-detail test is caught before export.
- The received Introduction Card matches the approved preview.
- Contact sharing remains separate and manual.

### 16.6 Test record

```yaml
synantisi_test_record:
  date: 2026-08-27
  test_A_simulation: "PASS | PARTIAL | FAIL"
  test_B_ble_discovery: "PASS | SKIPPED | FAIL"
  test_C_introduction_handoff: "PASS | PARTIAL | FAIL"
  handoff_method: "manual | native_nearby_app | none"
  timer: "PASS | FAIL"
  mutual_match_consistency: "PASS | FAIL"
  consent_gate: "PASS | FAIL"
  private_detail_scan: "PASS | FAIL"
  introduction_preview: "PASS | FAIL"
  separate_contact_consent: "PASS | FAIL"
  decline_and_block: "PASS | FAIL"
  confusing_points: []
  safety_concerns: []
  changes_requested: []
```

## 17. Conformance tests

| ID | Requirement | Expected result |
| --- | --- | --- |
| SYN-AGE-001 | Profile is under 18 or age status absent | Session creation fails closed |
| SYN-SEX-001 | Sexual, dating or hookup intent is requested | Session is refused and rules are shown |
| SYN-TIME-001 | Session reaches expiry | Discovery and invitations stop |
| SYN-TIME-002 | AI requests silent extension | Native app refuses; user confirmation required |
| SYN-MOTION-001 | Walking or venue transition occurs | At most a prompt; session remains off |
| SYN-PRIV-001 | Discovery envelope is inspected | No profile, handle, stable ID or exact location present |
| SYN-CONSENT-001 | Only one person accepts | Chat remains closed |
| SYN-CONSENT-002 | Both accept | Chat may open over authenticated encrypted transport |
| SYN-CONTACT-001 | One person requests contact sharing | No contact released until the owner separately confirms |
| SYN-CONTACT-002 | Contact card contains a telephone number or email | Export fails closed and identifies the prohibited field |
| SYN-INTRO-001 | Introduction offered before mutual acceptance | Export and transfer are refused |
| SYN-INTRO-002 | Introduction contains address, exact location or external handle | Export fails closed and requests removal |
| SYN-INTRO-003 | Approved introduction is altered after preview | Digest changes and a fresh preview/confirmation is required |
| SYN-TRANS-001 | Machine translation is prepared | Original is retained, translation is labelled and nothing is sent |
| SYN-FILE-001 | Markdown contains active HTML, script or remote image | Content is stripped or rejected; no remote resource is fetched |
| SYN-BLOCK-001 | A blocks B | Further invitations from resolvable B identifiers fail |
| SYN-AI-001 | AI drafts a message | Message remains unsent until explicit confirmation |
| SYN-CAP-001 | No native bridge exists | AI announces simulation mode and makes no Bluetooth claim |
| SYN-PROX-001 | Strong signal is observed | UI says nearby; it does not claim exact distance or visibility |
| SYN-REPLAY-001 | Expired token or invitation is replayed | Request is rejected |
| SYN-DECLINE-001 | A declines B | B receives no private reason or free text |

## 18. Aletheia compatibility

Synantisi is a separate protocol. It must not be inserted into the canonical
Aletheia specification as though it were an Aletheia transport.

Aletheia may record:

- why the 18+ and non-sexual decisions were made;
- the current user-approved profile and its superseded versions;
- consent receipts with minimal identifiers and expiry;
- test evidence, conflicts, interpretations and protocol changes;
- implementation conformance results.

Aletheia should not record ordinary nearby encounters, rejected people, precise
locations or chat content by default. A relevance score of zero should result in
non-retention unless a lawful safety reason requires otherwise.

### Decision register

| Decision | Status | Rationale |
| --- | --- | --- |
| SYN-DEC-001: service is 18+ only | Accepted | Avoid adult-minor discovery and reduce safeguarding risk |
| SYN-DEC-002: service is strictly non-sexual | Accepted | Purpose is friendship, interests and conversation |
| SYN-DEC-003: sessions are timed and off by default | Accepted | Consent, privacy and battery protection |
| SYN-DEC-004: motion/location may prompt but never activate | Accepted | Context assistance without covert broadcasting |
| SYN-DEC-005: no personal profile in beacon | Accepted | Reduce passive tracking and disclosure |
| SYN-DEC-006: AI cannot autonomously invite or send | Accepted | Human agency and consent |
| SYN-DEC-007: Synantisi remains separate from canonical Aletheia | Accepted | Different purpose and technical layer |
| SYN-DEC-008: Thursday starts with simulation, then optional BLE smoke test | Accepted | Separates UX evidence from radio evidence |
| SYN-DEC-009: profiles use three-stage disclosure | Accepted | Matching, introduction and external contact need different consent levels |
| SYN-DEC-010: shared introductions are sanitized Markdown | Accepted | Allows useful detail without executable or tracking content |
| SYN-DEC-011: contact handles are manual and separate | Accepted | Prevent accidental identity release and exclude telephone numbers |
| SYN-DEC-012: mixed iPhone/Android test uses manual handoff | Accepted | Tests protocol honestly before native cross-platform transport exists |

## 19. Thalia compatibility

Thalia may provide a positive, situational and non-sexual icebreaker only after
a mutual match and explicit invitation consent. The user must review it before
sending. Thalia must not joke about age assurance, consent, rejection, stalking,
sexual content or a person's protected characteristics.

## 20. Implementation roadmap

1. **v0.1 — current:** canonical draft, fillable Markdown profile, two-chat
   simulation, consent-gated introduction handoff and optional Android BLE
   discovery smoke test.
2. **v0.2 — Android proof of concept:** two Android phones, visible timed
   sessions, opaque tokens, deterministic mutual match and consent-gated chat.
3. **v0.3 — privacy service:** rotating signed tokens, rate limits, blocks,
   report flow and documented retention.
4. **v0.4 — Android/iPhone interoperability:** signed native apps, authenticated
   nearby byte/file transfer, and foreground/background behaviour tested on
   supported OS versions; no claimed parity until measured.
5. **v0.5 — conformance and safety review:** independent security review, DPIA,
   Online Safety assessment, age-assurance decision and public test criteria.

## 21. Open questions

- Should the first native prototype be entirely offline or use an internet
  matching service for stronger profile privacy?
- What level of age assurance is proportionate for a public release?
- Should chat disappear at session end by default or remain locally at both
  users' request?
- Should gender and age-band preferences remain in v0.2, or should the first
  prototype match only by purpose and interests?
- What maximum Introduction Card size and local retention period should the
  first native prototype use after user testing?
- Which current iPhone model and iOS version will be available when native
  interoperability testing begins?
- What is the final name and trademark position for Synantisi?

## 22. Technical and regulatory references

- Bluetooth SIG, *Bluetooth Low Energy Primer*:
  https://www.bluetooth.com/bluetooth-le-primer/
- Bluetooth SIG, *Supplement to the Bluetooth Core Specification — Data Types*:
  https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/CSS_v11/out/en/supplement-to-the-bluetooth-core-specification/data-types-specification.html
- Android, *BluetoothLeAdvertiser*:
  https://developer.android.com/reference/android/bluetooth/le/BluetoothLeAdvertiser
- Android, *Communicate in the background*:
  https://developer.android.com/develop/connectivity/bluetooth/ble/background
- Android, *Activity Recognition Transition API*:
  https://developer.android.com/develop/sensors-and-location/location/transitions
- Apple, *Core Bluetooth background processing*:
  https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html
- Apple, *CMMotionActivityManager*:
  https://developer.apple.com/documentation/coremotion/cmmotionactivitymanager
- Google, *Nearby Connections overview*:
  https://developers.google.com/nearby/connections/overview
- Google, *Nearby Connections for Swift — exchange data*:
  https://developers.google.com/nearby/connections/swift/exchange-data
- Google, *Nearby Connections for Swift — discover devices*:
  https://developers.google.com/nearby/connections/swift/discover-devices
- Apple, *Transfer files between iPhone and other devices*:
  https://support.apple.com/guide/iphone/transfer-files-between-devices-iph339bafff3/ios
- Apple, *Use AirDrop on iPhone to send items to nearby Apple devices*:
  https://support.apple.com/guide/iphone/use-airdrop-to-send-items-to-nearby-devices-iphcd8b9f0af/ios
- ICO, *Data protection by design and by default*:
  https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/data-protection-by-design-and-by-default/
- Ofcom, *Dating and social discovery: online safety risks and rules*:
  https://www.ofcom.org.uk/online-safety/illegal-and-harmful-content/dating-and-social-discovery-know-the-online-safety-risks-rules-and-how-to-comply
- Apple, *App Review Guidelines — User Generated Content*:
  https://developer.apple.com/app-store/review/guidelines/
- Google Play, *Child Safety Standards for social and dating apps*:
  https://support.google.com/googleplay/android-developer/answer/14747720
- Nordic Semiconductor, *nRF Connect for Mobile*:
  https://www.nordicsemi.com/Products/Development-tools/nRF-Connect-for-mobile

## 23. Version history

### 0.1.1 — 25 August 2026

- Added the standard-question input flow and companion profile template.
- Split disclosure into private Match, Introduction and Contact Cards.
- Prohibited telephone numbers and other private details in shared cards.
- Added privacy preview, translation provenance and untrusted-Markdown rules.
- Added consent-gated Introduction Card byte/file payloads for native apps.
- Made the Thursday test work honestly with one Android phone and one iPhone by
  using a manual Markdown handoff; retained Android-only BLE as optional.
- Kept commercial book recommendations outside the canonical protocol.

### 0.1.0 — 25 August 2026

- Established 18+ and strictly non-sexual boundaries.
- Made discovery timed, off by default and explicitly confirmed.
- Allowed motion/location suggestions but prohibited automatic activation.
- Separated AI conversation from native Bluetooth authority.
- Prohibited personal data in discovery advertisements.
- Defined mutual matching, two-sided consent and separate contact release.
- Added security model, conformance tests and Thursday test procedure.
- Kept Synantisi separate from the canonical Aletheia protocol.