Repository navigation
Releases: EmptyCode0x86/OffCode-Tor-Chat-E2EE
Releases · EmptyCode0x86/OffCode-Tor-Chat-E2EE
Release list
OffCode Tor Chat 0.3
Info: https://github.com/EmptyCode0x86/OffCode-Tor-Chat-E2EE
https://www.dev-offcode.com/TorChatPage.html
VER: 0.1.3
- 19/10/2026
Changes
New: Feed
-
Public Feed: A new, optional Feed tab where people can write short text posts, comment and like. The server owner turns it on in Server Manager (Enable feed). It is off by default. -
Feed is public: Anyone who has the .onion address can read the Feed. Posts are not end-to-end encrypted like chat messages, so don't post secrets. They are still stored encrypted on the server's disk. -
Who can post: Reading needs nothing. To post, comment or like you need a recovery code. It works like an anonymous ID: no account, email or personal data. You can delete your own posts with it. -
Generate code without a room: New visitors can now create a recovery code straight from Profile. You no longer have to create a room first. -
Moderation: The server owner can remove any post from Server Manager (Remove selected post). -
Clean text only: Emojis and hidden or invisible characters are not allowed, which stops tricks that hide or flip text. -
Terms updated: The Terms of Service now say the Feed is public and moderated by the server owner. Server Manager asks you to accept them again on next start.
Security
-
Stricter page security: The chat page now tells the browser exactly what it may load and run, and blocks everything else. This makes it much harder for injected code (XSS) to run. Some of these protections work only in Chromium-based browsers. Tor Browser ignores them, which is expected. -
Extra privacy headers: Pages and server responses are no longer cached, aren't indexed by search engines, and don't trigger extra DNS lookups. -
Codes stay in this tab by default: Recovery codes and room management codes are now forgotten when you close the tab. Turn on Remember on this device in Profile if you want to keep them. Older saved codes are moved safely and you get a notice about it. -
Safer file names: Downloaded file names can no longer use hidden characters to disguise the real file type (for example a fake ".jpg" that is really a program). -
Connection checks: The server only accepts live connections from its own address. If that check blocks something, the chat still works over a slightly slower fallback connection. -
Replay protection: The app now detects and ignores messages that someone records and sends again later, or that carry a fake time. If many are ignored, you see one short summary line instead of a flood of notices. -
Encryption keys kept out of reach: Raw room keys are no longer left in the app's memory where other code could read them, and they are wiped after use. -
Encryption update (protocol v3): Encryption is tied more tightly to each room, sender and message time, and file encryption got the same upgrade. Note: this version is not compatible with older ones. Old rooms and messages are wiped on the first start, and everyone needs the update. -
Matching safety numbers: When someone leaves and rejoins, both people now see the same new safety number, plus a reminder to compare it again. -
Cleaner images: Hidden data such as location and leftover cropped image data is removed from shared images more reliably. -
Honest limits: In open rooms and in password rooms with three or more people, the app can't prove which member sent a message. Treat these rooms with that in mind. -
Startup check screen: Redesigned. The chat only opens on your own computer or a real .onion address, in a browser that supports secure encryption. If it stays blocked in Tor Browser, set the Security Level to Standard or Safer and reload. -
Checked key exchange: Keys received from the other person are checked before use, and broken or fake keys are rejected. -
Strict message format: Each message is bound to its room, its sender and its send time. Messages in unknown or old formats are rejected instead of guessed at. -
Password handling: Room passwords are converted to one standard form, so the same password typed on different devices works the same way. -
Safer file transfer: Files are split into encrypted pieces with fixed size limits (maximum 32 MiB per file). Each piece is checked, and damaged or extra pieces are rejected.
Server Manager
-
Vanguards data in a safe place: Vanguards (extra Tor protection) now keeps its data in your AppData folder. It survives updates and is never included in release packages. -
Generate new address: Works only when Tor and Vanguards are stopped, and the dialog tells you what to stop. Old address keys and Tor's saved state are then securely overwritten. -
Smoother Vanguards start and stop: Vanguards starts as soon as Tor is ready and stops in the right order when Tor is turned off. -
Less log noise: Guests no longer trigger pointless invite errors, and the remaining errors are shown on a single line. -
Reset guard data: New button on the Connection tab. Use it only when Tor and Vanguards are both stopped. It clears Tor's saved entry-point data (a backup is kept too). Tick the box to also clear Vanguards' data. Your .onion address and keys stay the same. If connections keep failing, Server Manager offers this reset once per hour. -
Cancel a stuck Tor start: Turning Tor off, pressing Stop or closing the window while Tor is starting cancels it cleanly. If Tor has not finished starting after 5 minutes, it is cancelled automatically and shows as Stopped. Stop also works while the chat server is starting. -
No leftover background programs: If Server Manager closes unexpectedly, the Tor, Vanguards and chat server processes it started are shut down. Any left over are cleaned up on the next start. Other programs, including Tor Browser, are never touched. -
Clear port warning: If the Tor control port or chat port is already used by another program, Server Manager shows that program's name and process ID before starting anything. -
Tidier Tor log: Shows when your .onion address is published to the Tor network. Routine connection messages are hidden, and a guard failure is reported only once per run. -
New window look: Named "TorChat Server Manager" with the onion icon. Minimum window size is 900 x 600. Settings on the Connection tab are collapsed under an expandable section. -
Windows app: The Windows release is a single "TorChat Server Manager.exe" file. Its settings and data are kept in %AppData%\TorChat_ServerManager_MP. -
Confirmation boxes: Popups wait for your answer without freezing the window. For example, Remove selected post no longer hangs the app. -
Error log: Unexpected errors are saved to crash.log in the data folder. It never contains admin keys, encryption keys or message text. -
Vanguards included: The Windows release comes with its own Python, so you don't need to install Python to use the Vanguards option. -
Safe releases: Release builds are checked so private files (keys, admin data, local settings) are never included.
Platforms
-
macOS: Tor Chat now works on macOS. -
Linux (Ubuntu Desktop): Tor Chat now works on Ubuntu Desktop. -
Ubuntu Server: Not supported yet. Support for Linux / Ubuntu Server is in progress and will be added later.
OffCode Tor Chat 0.2
Info: https://github.com/EmptyCode0x86/OffCode-Tor-Chat-E2EE
https://www.dev-offcode.com/TorChatPage.html
VER: 0.2
- 10/10/2026
Changes
- Create rooms in Server Manager: Use Create room with a name only. That adds an open public room. You own it with the Admin key (paste into Profile Restore on the onion site). Remove selected room still works as before.
- Admin key: Server Manager keeps one recovery code for rooms you create there. It is the same kind of code as Profile on the site. Copy it, then Restore in Tor Browser. The i button next to the key explains this. The key is not stored in config.ini. Wiping SQL data does not delete it.
- Limit website room creation: Maximum Number of Rooms caps how many public rooms people can create from the onion page. Disable Room Creation blocks all website creates immediately. You can still create rooms from Server Manager.
- Save and Windows startup: Save stores ports, Tor, room limits, and Start server on startup. If that box is on, Save also starts Server Manager at Windows logon. ChatServer (and Tor if you saved it on) then start without extra dialogs. Uncheck and Save to turn logon start off.
- Faster onion page: Fewer fonts and a smaller download. The chat page should load quicker over Tor. Still no CDN.
- Locked 1:1 after reload: Messages from a previous join in a locked two-person room show as a previous-session note. They do not decrypt with the room password. Encryption itself is unchanged.
- Leave a room: Leaving or being removed clears the chat on screen (messages, draft, safety number, images). You are not logged out. Recovery codes in the browser stay.
- Safety number: Locked 1:1 now shows eight groups of five digits. Both people need this update. Compare the numbers in person or in another app.
- Tor flood protection: The Hidden Service can slow down floods (intro DoS and Proof-of-Work) when it is under load. Needs Tor 0.4.8 or newer (this bundle is). Docker uses the same settings.
- Admin tools stay off Tor: Server Manager talks to ChatServer on a private local port. Visitors on the .onion cannot see health or room-admin tools.
- Harder to fingerprint the host: Time in headers is rounded, and build timestamps are not sent with the page. CSS and fonts still cache so the page stays reasonably fast.
- Invite guessing: Invite lookups are limited across the whole server, so spinning new Tor circuits cannot hammer invites as cheaply.
- Hidden and closed rooms: A failed join takes a similar amount of time whether the room exists or not, so timing does not give that away.
- Official Tor files: Server Manager checks bundled Tor against a known hash. If it does not match, Tor does not start. It does not download a replacement.
- Message times: Times are rounded to the minute. Rejected messages all say the same thing, so the error text does not explain why.
- Where the chat runs: The UI only opens on localhost or a real Tor v3 .onion address, and only if the browser can do Web Crypto. Otherwise it stays blocked.
- Pinned message: The room creator can pin one message. Everyone sees that pin; the server does not learn the text. The pin expires with the message.
- Disable Room Creation: Checkbox in Server Manager. When on, nobody can create rooms from the onion site. You can still Create room from Server Manager.
OffCode Tor Chat 0.1
Info: https://github.com/EmptyCode0x86/OffCode-Tor-Chat-E2EE
https://www.dev-offcode.com/TorChatPage.html
VER: 0.1
- 12/08/2026
Changes
- FileSeal: Client wraps a random DEK with the room/hybrid CryptoKey (AES-GCM + AAD), encrypts the file in 256 KiB plaintext chunks, and uploads opaque ciphertext via PUT /api/attachments/{id}/chunks/{n} with HMAC X-Transfer-Token.
- Manifest v2: Compact envelope (wrap + salts + downloadToken) still goes through E2EE SendEncrypted; legacy v1 Base64 envelopes remain readable.
- Limits: Max 32 MiB per file; hub Begin/Complete/Cancel; SQLCipher attachment_transfers + disk under the data dir; TTL/orphan cleanup with messages.
- Policy: attachments_disabled still blocks Begin; text-only PayloadB64 gate unchanged for disabled rooms.
- Generate new code: Profile button + hub RebindCreatorSecret(old, new) rebinds all room_creators rows to the new SHA-256 hash and revokes the old code immediately. Restore alone does not invalidate server bindings.
- Hash model docs: Creator/manage/invite tokens use SHA-256 of high-entropy secrets; join proof uses PBKDF2. Weak-restore warning in Profile UI.
- Invite tokens: Stored as SHA-256 only; plaintext returned once on create/rotate; client caches last link; startup migrates legacy plaintext rows.
- JoinRoom owner-proof: Server verifies manageToken / creatorSecret only when joins are closed or a hidden room lacks a valid invite; client sends recovery only when this browser likely owns the room (manage token, owned-room cache from create/My rooms/restore, or My rooms page). Owner bypass logs + caller SystemNotice.
- GetMyRooms IncludePublic: Separate rate limit (5 / min) vs hidden-only My rooms (20 / min).
- Recovery docs: Profile + README treat recovery as a capability token (Settings, listing, closed rejoin).
- Attachments disabled: Text-only PayloadB64 gate tightened to ~16 KiB (blind size gate; not content-type).
- Restore recovery code: After saving the code, client calls GetMyRooms(includePublic: true) and shows a toast listing Hidden (My rooms) vs Public (Public rooms) room ids (or “none” / empty-server message).
- API: GetMyRoomsRequest.IncludePublic; ListRoomsForCreator(secret, hiddenOnly).
- Owner bypass on JoinRoom: When joins_closed (and for hidden rooms, disabled invite), the creator can still join by sending manageToken and/or Profile creatorSecret. Other members stay blocked. Password joinProof still required for locked rooms.
- Client: joinRoom / reconnect attach ownership proof from localStorage recovery + per-room manage token.
- API: IRoomInviteService.IsOwner; optional fields on JoinRoomRequest.
- Disable attachments: Creator Room Settings toggle (attachments_disabled in SQLCipher). Members get AttachmentsPolicy on join / toggle; Attach button gated in room-attachments.js. Server enforces a text-only PayloadB64 size cap when disabled (blind relay cannot inspect ciphertext kind).
- Hub / registry: SetAttachmentsDisabled, InviteStatusResponse.AttachmentsDisabled, registry getters/setters, DB migration.
- Room Settings UI: Wider two-column layout (Membership | Attachments; Slow mode compact row; Invite / Lock / Delete full width); denser hints and spacing.
- Max members: Creator Room Settings toggle (max_members in SQLCipher, 0 = off, else 2–50). Enforced in RoomPresenceService.Join; public "Room is full.", hidden generic "Cannot join room.". Existing members stay if the cap is lowered.
- Announcement / read-only: Creator Room Settings toggle (read_only). Only the creator may SendEncrypted / BeginAttachmentUpload; owner tokens are extra hub args (not persisted). Members get a disabled composer (room-readonly.js).