Sharing, collaboration & protected sources

Cynario encrypts scenario content in the browser before shared content leaves your device. The decryption key stays in the URL fragment (#…), which browsers do not send in ordinary HTTP requests.

That is a narrower and more useful claim than “there is no server.” Static hosts, catalog hosts, signaling services, relays, and container deployments can all exist. They may handle ciphertext and ordinary request or connection metadata; they should not receive the link-fragment key or scenario plaintext.

Ways to share

Encrypted play links

Create a link for a participant. The hosted or relayed payload is encrypted with AES-256-GCM, while the key is carried in the link fragment. Anyone who receives the complete link can decrypt the scenario, so treat the link itself as a secret.

Live collaboration

Live collaboration is available for co-authoring. Peers still treat incoming data as untrusted, and the app applies bounded validation rather than assuming everyone in a room is benign. Connection infrastructure can observe normal network metadata even when it cannot read encrypted scenario content.

Protected static sources

Main can publish a scenario-only protected static source for Marketplace-style distribution. It can be hosted as static files or from a container without giving the host the decryption password.

On feat/content-logic, Protect & share emits catalog v3 packages with uploaded media and Scenario-cover metadata encrypted until unlock. It verifies the real hosted source before a participant link is handed out. Readers remain compatible with catalog v1/v2; this media/cover flow is awaiting promotion to main.

Plain Marketplace sources and public covers

Plain sources intentionally expose listing metadata and Scenario files to their host. A verified Scenario-owned cover is also public listing artwork. Its URL must share the index origin; Cynario fetches it without credentials and requires bounded bytes, passive-raster MIME/file magic, and the published SHA-256 before rendering a Blob URL. Cross-origin app/source hosting therefore needs CORS; same-origin hosting avoids it. Readable Scenario structure remains behind the explicit spoiler reveal and ordinary import inspection.

File export

A Scenario can travel as readable JSON for review/versioning, or as .cynario.zip when its content-addressed cover/media bytes must travel too. Imported files still pass through Cynario’s local import gate before they are saved or played.

What signatures establish

Catalog hashes can show that fetched bytes match the bytes a publisher declared. An Ed25519 signature can show that the holder of a particular private key signed those bytes. Neither fact, by itself, proves the legal name or real-world identity of a person. Identity comes from how you obtained and verified the public key.

Safety does not depend on a signature: signed and unsigned scenarios go through the same import, logic, and rendering boundaries.

Honest limits

• A leaked complete share link is effectively a leaked decryption key.
• Hosts and relays can see normal request, timing, IP, and connection metadata unless another layer hides it.
• Encryption protects content in transit and at rest on an untrusted host; it does not make a participant device trustworthy.
• Local or signed result files can establish integrity and key possession, not that a particular human completed a run fairly.

See Security & trust for the full boundary model.