# Synantisi Online Rooms — Design Draft

> Status: design only, not a live service  
> Date: 2026-09-08  
> Scope: adult-only, strictly non-sexual, platonic social discovery

## The important correction

The purpose of Synantisi is to help people meet **new people**.

Using only already-known adults is appropriate for the first technical/safety
test. It is not the intended public experience.

A mature room may therefore be publicly listed or shared by URL, provided the
service has real age assurance, moderation, block/report controls, rate limits
and a tested privacy model.

## What is a Synantisi Room?

Think of an old IRC room with a private matchmaker standing at the door.

People can enter the same event/room, but Synantisi does **not** publish
everybody's private profile to everybody else.

Example:

```text
https://swindon.org.uk/meet/room/?r=saturday-social
```

Alice joins for 30 minutes.
Ben joins for 60 minutes.
Cara joins for 30 minutes.

Their private profiles stay local.

The room receives only a small Match Card/envelope needed to decide whether two
people mutually accept one another.

If Alice and Ben do not mutually match, neither is told the other's private
preferences.

If Alice and Cara mutually match:

```text
A MUTUAL MATCH IS AVAILABLE

Shared reason:
  tuxedo cats
  house music

Exchange introductions?

[ YES ]   [ NO ]
```

Only if both press YES do the sanitized Introduction Cards cross.

That is the central Synantisi idea whether the transport is Bluetooth or the
Internet.

## Why not use Signal itself as the room database?

Signal can create group links and call links, and it is useful technology.
However it is not a perfect Synantisi matching layer:

- participants need Signal;
- joining a Signal call shares the person's Signal profile name and photo with
  everyone on the call;
- a group has a visible membership/chat context rather than Synantisi's
  private mutual-match model;
- the Synantisi server/app would not control Signal's internal matching logic.

Therefore:

**Signal = optional room/contact transport.**  
**Synantisi = matching and consent layer.**

After a mutual match, a Signal username or call link can be an excellent
Contact Card choice if both people want it.

## Better first browser-room candidate: Jitsi

Jitsi is closer to the proposed "room" experience because a meeting can be
joined from a web link and can also be embedded in a website.

A future Swindon.org.uk Synantisi event page could therefore contain:

```text
┌─────────────────────────────────────────────────────────┐
│ SATURDAY HOUSE ROOM                         20:00–22:00 │
│ 18+ · platonic · 87 people currently in room            │
│                                                         │
│ [ Join for 30 min ▼ ]  [ Start Synantisi ]              │
│                                                         │
│ Music: [ Open BBC Radio 1 / chosen public stream ↗ ]    │
├───────────────────────────────┬─────────────────────────┤
│ Optional Jitsi camera wall    │ Synantisi               │
│ microphones muted             │                         │
│ cameras optional              │ MATCH AVAILABLE         │
│                               │ tuxedo cats + house     │
│                               │ [Introduction? YES/NO]  │
├───────────────────────────────┴─────────────────────────┤
│ Text chat / accepted private chats                      │
└─────────────────────────────────────────────────────────┘
```

The Jitsi layer supplies optional browser video and ordinary room chat.

The Synantisi layer decides which private one-to-one introductions are
appropriate.

The two layers should not be confused.

## Dance Mode

A Dance Room is an **event type**, not a dating mode.

An organiser chooses:

```yaml
event:
  title: "Saturday House Room"
  starts: "20:00"
  ends: "22:00"
  music_url: "PUBLIC_BROADCASTER_OR_LICENSED_PLAYER_URL"
  camera: optional
  microphone: muted_by_default
  text_chat: true
  synantisi_matching: true
```

Participants listen to the supplied music URL themselves.

Synantisi does not capture, relay or rebroadcast the music.

This is important technically and legally, but it also keeps the design simple.

### Synchronisation caveat

Two people opening the same live radio stream will not necessarily hear the
same beat at exactly the same millisecond. Streaming buffers vary.

For an informal "everyone dance at home" room, that may be perfectly adequate.

If exact musical synchronisation becomes important later, the room would need a
shared playback clock and a music source/licence that permits that design.

## Camera and microphone rules

For Dance Mode:

- camera OFF by default or optional;
- microphone muted by default;
- a moderator-controlled room may keep audio moderation enabled;
- use text/reactions for the general room;
- private conversation opens only after mutual Synantisi acceptance.

Video is not anonymous. Turning a camera on reveals appearance and surroundings,
so the interface must say this plainly.

## Thalia

Thalia is a natural optional companion after a match.

It can receive only the approved shared reason, for example:

```text
shared interests:
- tuxedo cats
- house music
```

and offer an opener:

```text
"Tuxedo-cat summit? Mine has already appointed itself DJ."
```

The user decides whether to send it.

Thalia never gets permission to send automatically and never receives the
other person's hidden acceptance/rejection criteria.

## High-street / Bluetooth mode

The nearby case remains:

```text
START 30
```

A real signed mobile Synantisi app advertises/looks for opaque nearby session
tokens.

Two nearby active Synantisi phones can discover one another, privately compare
the necessary Match Cards, and offer an invitation only after a mutual match.

Example:

> "A nearby Synantisi participant also selected railway history and AI. Would
> you like to offer an introduction?"

The user may be in a café, station, exhibition, High Street or, in the
traditional thought experiment, crawling past somebody else in the Sahara
looking for water.

Bluetooth mode and Online Room mode are simply two transports around the same
matching/consent rules.

## Web Bluetooth

Do not depend on Web Bluetooth for the public product.

It is experimental, requires HTTPS and explicit user permission, and is not
supported by all major browsers.

A real cross-platform nearby mode still points toward a native Android/iPhone
app/bridge.

## KISS implementation path

### Phase 1 — room page without matching backend

Build the human page and event vocabulary:

```text
/meet/room/
```

It can explain:
- room title;
- start/end time;
- optional video-room link;
- public music link;
- Synantisi session duration;
- safety/consent rules.

No fake matching.

### Phase 2 — ephemeral match service

Add a tiny backend:

```text
POST /room/join
POST /room/heartbeat
POST /room/leave
POST /room/accept
POST /room/block
```

Store only:
- room id;
- rotating session token;
- minimum Match Card;
- expiry;
- consent state.

Do not expose a participant directory.

### Phase 3 — text chat after mutual acceptance

Use WebSocket/WebRTC data channel or a small chat service after both users
accept.

### Phase 4 — optional video

Integrate Jitsi through a link or iframe, or later use a more tightly controlled
WebRTC service.

## Public safety boundary

The public system cannot rely on a checkbox saying "I am 18" as the entire
safeguarding design.

Before opening stranger-facing rooms, complete:
- age-assurance decision;
- moderation;
- block/report;
- abuse/rate limiting;
- privacy/retention policy;
- event moderation roles;
- security review.

The "known adult" restriction applies to engineering tests until those controls
exist. It does not redefine Synantisi as a service for people you already know.

## Current technology notes

### Signal

Signal supports group invite links and call links. It is useful after a match
or for a privately organised event, but it requires Signal users/clients and
shares Signal profile information with call participants.

### Jitsi

Jitsi can be joined through a browser link, works on current desktop/mobile
browsers, and can be embedded with its IFrame API. It supports starting with
audio muted, moderator audio controls, cameras and text chat.

This makes it a stronger candidate than Signal for a first Dance Room visual
layer.

### WebRTC

WebRTC is the browser technology underneath real-time video/audio/data systems.
A future purpose-built Synantisi room could use it directly, but doing so means
building signalling, TURN infrastructure, moderation and room logic ourselves.

KISS says: use an existing video layer first; build only the Synantisi-specific
matching layer.

## External references

- Signal group links:
  https://support.signal.org/hc/en-us/articles/360051086971-Group-Link-or-QR-code
- Signal call links:
  https://support.signal.org/hc/en-us/articles/7860719423002-How-to-create-and-share-call-links
- Signal usernames:
  https://support.signal.org/hc/en-us/articles/6712070553754-Phone-Number-Privacy-and-Usernames
- Jitsi:
  https://jitsi.org/
- Jitsi IFrame API:
  https://jitsi.github.io/handbook/docs/dev-guide/dev-guide-iframe/
- WebRTC data channels:
  https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels
- Web Bluetooth:
  https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API