Chat security — Netrina NYC

1. Invitation and rendezvous

The browser creates a 128-bit random room identifier and a separate 256-bit random secret with Web Crypto’s cryptographically secure random generator. The nsm2 invitation contains both values and a rendezvous timestamp 15 seconds after creation. The timestamp is public scheduling information; it adds no secrecy. The code is kept in page memory, never placed in the URL, cookies, browser storage, analytics or a site database by this chat. Copying it places it on your clipboard and sharing it gives it to the application and people you choose. Anyone holding the invitation can join. Existing nsm1 invitations are accepted without a countdown; all participants must use the current transport version.

2. Discovery and encryption

The implementation pins @trystero-p2p/torrent and @trystero-p2p/core to 0.25.4. Trystero derives an AES-256-GCM signalling key from SHA-256(secret + ':' + appId + ':' + roomId), imports it as a non-extractable Web Crypto key and encrypts session descriptions with fresh random IVs. The app identifier is netrina-secret-moon-v1. The default channel uses the random room identifier; other channel names are appended to that identifier. Public room names and website text are never used in place of the random secret.

After discovery, messages travel over browser WebRTC data channels protected by DTLS. Encryption is supplied by the browser and the pinned transport, not a new cryptographic algorithm. BitTorrent trackers arrange peer discovery; they are not a distributed message archive, torrent file, DHT chat database or virtual machine. There is no Netrina chat-message server or stored offline delivery.

3. What others can see

The transport selects up to three public trackers from open.ftorrent.com, tracker.webtorrent.dev, tracker.openwebtorrent.com, tracker.btorrent.xyz and tracker.files.fm:7073/announce. Trackers can observe source network addresses, times, room-related identifiers and encrypted signalling. Google STUN and Cloudflare STUN help with network discovery. These services and connected peers may observe your public IP address. Service operators control their own logs and retention. This is a regular HTTPS website, not Tor and not an anonymity system. No TURN relay is configured; some NATs, firewalls and mobile networks will prevent connections.

4. Membership and personal messages

All participants who know the invitation can enter any channel within that invitation. A nickname is an unverified alias. The user list includes a short connection identifier to distinguish duplicate names; this identifier is not a verified real-world identity or a security fingerprint. Personal messages target the selected peer’s data channel; they are not broadcast to the whole room. Different channels have distinct transport room identifiers. Changing channel leaves the previous channel and clears this device’s transcript. Create a new invitation and share it with a smaller group if membership must change. There is no ban, revocation, automatic secret rotation or application-level group ratchet.

5. Message lifetime and limitations

The UI keeps at most 200 recent entries in page memory. Disconnecting, closing the chamber, leaving the page or reloading clears the local conversation; this is not a forensic erasure guarantee. Briefly switching to another app keeps the interface, but browsers may suspend or terminate connections. Recipients can copy, capture or record everything they receive. Compromised devices, browser extensions, malicious same-origin scripts, stolen invitations and dishonest participants are outside the confidentiality guarantee. You must trust the website delivering the application. No claim of unbreakability, post-quantum security or a particular number of years to decrypt is made.

6. Why news pages are not secret keys

Counting letters in a public paragraph produces reproducible public data, often with very few possible values and many collisions. An observer can collect the same page or test likely pages and timestamps. Hashing these counts does not manufacture secret entropy. Personalised pages, edits, languages, caching and delivery delays can also give participants different input. This implementation therefore does not scrape websites or derive encryption keys from public text.

7. Validation status

Automated checks cover invitation parsing, random-secret generation, real signalling encryption and rejection of a wrong key or altered ciphertext, message validation, duplicate suppression, rate limiting, exact-peer delivery and disconnect handling. These checks do not constitute an independent cryptographic audit. Real-world connections between separate phones on different networks remain to be verified; successful connection in 15 seconds is not promised.