Toju / Zoracord

Desktop chat app with three parts:

• src/ Angular client
• electron/ desktop shell, IPC, and local database
• server/ directory server, join request API, and websocket events

Install

1. Run npm install
2. Run cd server && npm install
3. Copy .env.example to .env

Config

Root .env:

• SSL=true uses HTTPS for Angular, the server, and Electron dev mode
• PORT=3001 changes the server port

If SSL=true, run ./generate-cert.sh once.

Server files:

• server/data/variables.json holds klipyApiKey
• server/data/variables.json also holds releaseManifestUrl for desktop auto updates

Desktop auto updates

The packaged Electron app now reads a hosted release manifest from the active server's /api/health response.

Release flow:

1. Build the desktop packages with npm run electron:build or the platform-specific Electron Builder commands.

2. Upload one version folder that contains the generated latest.yml, latest-mac.yml, latest-linux.yml, and the matching installers/artifacts.

3. Generate or update the hosted manifest JSON with:

   npm run release:manifest -- --feed-url https://your-cdn.example.com/metoyou/1.2.3

4. Set releaseManifestUrl in server/data/variables.json to the hosted manifest JSON URL.

GitHub / Gitea release assets

If you publish desktop builds as release assets, use the release download URL as the manifest feedUrl.

Examples:

• GitHub tag v1.2.3:

  https://github.com/OWNER/REPO/releases/download/v1.2.3

• Gitea tag v1.2.3:

  https://gitea.example.com/OWNER/REPO/releases/download/v1.2.3

That release must include these assets with their normal Electron Builder names:

• latest.yml
• latest-mac.yml
• latest-linux.yml
• Windows installer assets (.exe, .blockmap)
• macOS assets (.dmg, .zip)
• Linux assets (.AppImage, .deb)

You should also upload release-manifest.json as a release asset.

For a stable manifest URL, point the server at the latest-release asset URL:

• GitHub:

  https://github.com/OWNER/REPO/releases/latest/download/release-manifest.json

• Gitea: use the equivalent latest-release asset URL if your instance supports it, otherwise publish release-manifest.json at a separate stable URL.

If you want the in-app "Specific version" option to list older releases too, keep one cumulative manifest and merge the previous file when generating the next one:

 `npm run release:manifest -- --existing ./release-manifest.json --feed-url https://github.com/OWNER/REPO/releases/download/v1.2.3 --version 1.2.3`

The manifest format is:

{
	"schemaVersion": 1,
	"generatedAt": "2026-03-10T12:00:00.000Z",
	"minimumServerVersion": "1.0.0",
	"pollIntervalMinutes": 30,
	"versions": [
		{
			"version": "1.2.3",
			"feedUrl": "https://your-cdn.example.com/metoyou/1.2.3",
			"publishedAt": "2026-03-10T12:00:00.000Z"
		}
	]
}

feedUrl must point to a directory that contains the Electron Builder update descriptors for Windows, macOS, and Linux.

Automated Gitea release queue

The Gitea workflows in .gitea/workflows/release-draft.yml and .gitea/workflows/publish-draft-release.yml keep the existing desktop auto-update flow intact.

On every push to main or master, the release workflow:

1. Computes a semver release version from the current package.json major/minor version and the workflow run number.
2. Builds the Linux and Windows Electron packages.
3. Builds standalone server executables for Linux and Windows.
4. Downloads the latest published release-manifest.json, merges the new release feed URL, and uploads the updated manifest to the draft release.
5. Uploads the desktop installers, update descriptors, server executables, and release-manifest.json to the matching Gitea release page.

The draft release uses the standard Gitea download path as its feedUrl:

 `https://YOUR_GITEA_HOST/OWNER/REPO/releases/download/vX.Y.Z`

That means the current desktop auto-updater keeps working without any client-side changes once the draft release is approved and published.

To enable the workflow:

• Add a repository secret named GITEA_RELEASE_TOKEN with permission to create releases and upload release assets.
• Make sure your Gitea runner labels match the workflow runs-on values (linux and windows).
• After the draft release is reviewed, publish it either from the Gitea release page or by running the Publish Draft Release workflow with the queued release tag.

Main commands

• npm run dev starts Angular, the server, and Electron
• npm run electron:dev starts Angular and Electron
• npm run server:dev starts only the server
• npm run build builds the Angular client
• npm run build:electron builds the Electron code
• npm run build:all builds client, Electron, and server
• npm run lint runs ESLint
• npm run lint:fix formats templates, sorts template props, and fixes lint issues
• npm run test runs Angular tests

Server project

The code in server/ is a small Node and TypeScript service. It handles the public server directory, join requests, websocket updates, and Klipy routes.

Inside server/:

• npm run dev starts the server with reload
• npm run build compiles to dist/
• npm run start runs the compiled server