gmatch

Download

Version 1.6.4 · file gMatch-1.6.4-portable.exe · 110,818,200 bytes (105.7 MiB) · built 2026-10-25T00:23:00Z (UTC).

Download the portable executable

Verify the SHA-256 below against the downloaded file before running it:

22f83283be21757059132e49b37add7341a2142330bb423c270fffb9aabb5928

And the SHA-512 as an independent second check:

8716d857f2ef4f4100fee05213518c1b7489dd2a3ddb8d948d3281010b3f934ce2ad1b48a7bedc12b181fb56976ea9866e19fef0d07f6d41e3ef0839d4b58966

Hashes, byte count and build date are derived mechanically from the published asset — release.json is generated by site/build-release.mjs from the exact file, never hand-typed.

Code signing

The binary is not Authenticode-signed, so Windows SmartScreen may show its generic warning for unknown publishers. The integrity guarantee is the digest you compute yourself from the bytes GitHub serves for that asset.

Verify on Windows

Open PowerShell and run (adjust the path if needed):

Get-FileHash "$env:USERPROFILE\Downloads\gMatch-1.6.4-portable.exe" -Algorithm SHA256

Compare the Hash value with the SHA-256 above. If it differs by even one character, delete the file and report it through the abuse page. Use -Algorithm SHA512 for the second digest.

Updates

The app checks this site's release.json shortly after start and once a day after that, with the public node's manifest as a fallback if this host is unreachable. A newer build is downloaded, checked against the published SHA-256 and byte count, and installed only on an explicit Install & Restart action. If the swap is blocked, the running build is kept and every step is written to %APPDATA%\@gmatch\desktop\main.log.

What it is

A desktop client built around local-first data and peer-to-peer transport:

• A feed of media you publish, with a per-post audience;
• One-to-one and group conversations, sealed end to end and addressed through rotating masks;
• A watch party with persistent rooms;
• A card and idle-game arcade that runs entirely locally;
• Servers: your own node, a friend's, or the built-in public world — all probed, none assumed online;
• Report-driven moderation: a moderator sees a reported item only when the person involved discloses that one item.

There is no sign-up, e-mail or phone number. Your account is a keypair generated on your own machine; the app asks you to export a backup because nobody can reset a key that never left your device.

Watch party

• Cinema grid: persistent 16:9 rooms with live member counts and room status.
• Persistent rooms: a room stays in the directory when everyone leaves, so a group can reconvene without recreating it.
• Background playback: renderer throttling and occlusion checks are relaxed so playback continues while you are in another window.
• Low-latency room chat: ephemeral messages sized for watch-along conversation.

Servers and the public world

• Local node by default: a packaged install starts its own node, so feed, chat and media data live on the machine that produced them.
• gmatch Node: the maintainer's full node, built into the Servers list, probed on screen and joined in one click. A fresh install can meet people without an invite; the row is drawn offline when the probe fails, and nothing is simulated.
• Anyone can run another node: host your own from the desktop app, or join a friend's by address (and password, if they set one) — it is a different server, with its own database and its own admin. The directory carries metadata only — name, description, endpoint hint, owner public key, password flag and counts — never content.
• The courier: the hosted relay moves sealed mail, TURN credentials and directory rows, and answers 404 on stateful routes. It is infrastructure, never a data base.
• Direct when possible, relay when not: two clients try a direct WebRTC path first; the relay carries frames meanwhile. The UI says which path is in use — direct only after the data channel is validated, relay when a direct hole cannot be punched.

Security model

What a relay, the public node and an observer can and cannot see:

• Content travels sealed. Messages, media and room frames are encrypted before they leave your machine; the relay forwards opaque envelopes addressed to rotating tokens.
• API calls are sealed too. Identity headers and request bodies are encrypted to the node's transport key, so an observer sees ciphertext, not which route or record you touched.
• Media at rest is encrypted. Cached images are stored with AES-256-GCM under a local key that never leaves the machine, bounded by a size cap; private keys live in the OS vault (DPAPI on Windows).
• Media transfers are end-to-end encrypted (swarm-v1). The requester advertises a fresh ephemeral X25519 key per transfer, the sender seals a per-transfer data key to it, and every chunk is XChaCha20-Poly1305 with associated data binding the object, transfer, chunk index and requester key. A relay sees ciphertext and sealed keys.
• A full community node stores its community's data. That is the trade for running a world: the host of the node you join can read the database it keeps. The courier keeps none, and the public node is adminstered like any other community.
• Self-hostable. Your machine can be the node; friends join by address, and the public directory carries metadata only.

Read the full white-box report: security audit.

Cryptography, in plain terms

• Identity: an Ed25519 signing keypair and an X25519 encryption keypair generated on first start. Your public identifier is a SHA-256 digest of the public key. Private keys never leave the device.
• One-to-one messages: ECIES (X25519 + BLAKE3 + XChaCha20-Poly1305). Only the holder of the recipient's private key can open a message — not the relay, not the sender afterwards.
• Group rooms: the content key is created once and shipped inside the sealed 1:1 invite; each message is group-sealed once and then ECIES-copied to every member's mailbox, so the node relays ciphertext it cannot open. A leave raises the epoch — an equal epoch never replaces a key, a higher one does.
• Signed, versioned state: posts, edits, deletions, reactions, follows and profile fields are signed operations with monotonic per-actor sequences. Replicas resolve conflicts deterministically, and a deletion withdraws the stored bytes instead of hiding them.
• Media swarm: per-transfer ephemeral keys and AEAD chunk sealing (above); content hashes are verified before anything is persisted, and a replayed chunk is an idempotent no-op.
• Masks and metadata: peers address rotating delivery tokens, never raw addresses, and images are stripped of EXIF/GPS, XMP and text containers before they are shared.
• The honest limit: cryptography protects content in transit and at rest; it does not protect an unlocked computer or a leaked key backup.

Masks and metadata

• Mask-only addressing. Conversations, receipts and room invites are addressed to opaque delivery tokens; host names and account ids never appear in the peer layer.
• Rotation. The permanent address is derived from the public key; each session also derives a fresh token whose epoch travels sealed inside message bodies, so the relay cannot link yesterday's traffic to today's.
• Images carry pixels only. Metadata containers (EXIF/GPS, XMP, ICC, text chunks) are stripped across JPEG, PNG, GIF and WebP on every path; tags live in the database, never in the file. Video containers remain a documented exception.
• Addresses never render raw. Server coordinates shown in the UI are masked; the real value is used only to connect.

Topology

• Peer-first. Clients on the same node find each other through it, then talk directly over WebRTC; clients on different nodes meet through the directory and then try a direct path.
• Relay as a floor, not a ceiling. When a direct path fails or its deadline expires, frames keep flowing over the node so the mesh still works behind NAT. A later success promotes to direct; the state is never faked.
• No central data store. The public node is one community among many; the courier stores no content tables, and any node can be replaced by a peer.
• Updates come from this site's release.json and are hash-verified before installation.

Moderation model

• Report-driven only. There is no bulk view of private conversations. A moderator sees a reported item only when the person involved discloses the key for exactly that item, and the node verifies that the disclosure opens nothing else.
• Bounded grants. The moderation panel requires a passcode and an allowlisted identity; the grant expires, and every action is written to an append-only audit log.
• Community nodes are administered by their own host. The software defines what the panel exposes; a host with raw database access is trusted by their community, which the encryption disclaimer states plainly.

Known limits

• Network edge: any server (and its CDN) sees the client IP at the TCP layer. The application never stores, echoes, logs or renders an IP; that is the boundary of what application code can do.
• Traffic analysis: without onion routing, an observer can correlate timing and volume. Padding and jitter reduce it; they do not eliminate it.
• Hard NAT: the relay keeps the mesh working when a direct hole cannot be punched. Cross-network symmetric-NAT behaviour is documented as a runbook and has not yet been exercised end to end.
• Video metadata (mp4/webm) is not stripped — a parser limitation recorded in the audit.
• No forward secrecy yet: account keys are static; ratcheting is planned hardening.
• The audit is static (white-box, reproducible checks), not an external dynamic penetration test.
• Local compromise: malware or physical access to an unlocked machine defeats client-side cryptography.

Legal documents

• Terms of Service: eligibility, self-custodied keys, prohibited conduct, termination.
• Privacy Policy: which data exists, legal bases, your rights.
• Community rules: what the software enforces technically, not only rhetorically.
• Abuse & reports: how reporting and voluntary disclosure work.
• Content records: who publishes your media, and what that means.
• Encryption & self-custody disclaimer: the limits of what the operator can do for you.
• Security audit: the full white-box report.

Document version: 2026-09-11.2. Changes are recorded in legal/changelog.html. Inside the app (Settings → Legal) users read and confirm the current version.

Privacy at a glance

• This page: static HTML, zero JavaScript, zero external fonts, zero cookies, zero analytics. No request leaves this origin.
• The app: no account is created anywhere, no personal data is collected, no telemetry is emitted. Only sealed envelopes with an expiry cross the network.
• On your machine: OS-encrypted key storage, AES-256-GCM for cached media, and local exercises of your access, deletion and portability rights.

Questions

Why a desktop executable instead of a website?

So media and conversations never transit or rest on a third-party web host. The client runs on your machine and talks to peers or to a node you choose.

Can I recover my account if I lose my key?

No, by design. Nobody — including this project — can enter an account whose key is gone, which is why the app insists on a key backup.

Any telemetry, ads or sign-up?

No. Zero analytics, zero cookies on this page, zero registration in the app.

What does the public node store?

It is a full community node: the posts, media and conversations of the community that joins it, under the same encryption rules as any other node. The courier stores no content — only sealed envelopes with an expiry and rotating delivery tokens.

Does the server see my IP?

Any network edge sees it, as with any website visit. The application never stores, logs or displays it, and conversations address rotating masks rather than addresses. See known limits.

How do I report abuse or a mismatched download?

Through the app (Settings → Help) or the abuse page.