SOS Shantur #883

Here are the exact items I’ll need your help with:

1. Tauri auto-update and signing — PR #786

#786

Tauri will become the self-updating desktop edition. Electron will remain the portable edition for now.

The intended release formats are:

• Windows: signed Tauri NSIS installer;
• macOS x64 and arm64: signed Tauri updater archives;
• Linux: a self-updating AppImage alongside the existing .deb;
• WinGet remains available as an installation and distribution channel, but CodeNomad will no longer invoke WinGet internally to update itself.

This requires a definitive production Tauri updater signing key pair. This is a Tauri/minisign updater key, rather than an operating-system code-signing certificate.

We need to agree who will retain the private key and then configure these GitHub Actions secrets:

• TAURI_UPDATER_PUBKEY
• TAURI_SIGNING_PRIVATE_KEY
• TAURI_SIGNING_PRIVATE_KEY_PASSWORD

The private key must be backed up securely. Losing it would prevent future versions from updating installations that trust that key. The test key used during development must not be used in production.

I would also like to validate the final macOS arm64 desktop updater on an owned Apple Silicon machine before the public release.

2. Open-source Remote Control relay — PR #668

#668

The relay must be deployed from the Cloudflare account that owns the neuralnomads.ai zone.

The deployment requires:

• the RemoteControlHost Durable Object with its SQLite migration;
• the remote.codenomad.neuralnomads.ai custom domain;
• the *.remote.codenomad.neuralnomads.ai wildcard route;
• confirmation that the GitHub Actions Cloudflare token has the required Worker, Durable Object, route and zone permissions;
• confirmation or provisioning of the correct CLOUDFLARE_ACCOUNT_ID;
• appropriate Cloudflare usage alerts and limits.

No CodeNomad port is exposed publicly. The desktop application creates an outbound WebSocket connection, and application traffic is encrypted end to end between the paired browser and the user’s CodeNomad instance. Cloudflare routes opaque encrypted frames and sees routing metadata, sizes and timing, but not the CodeNomad requests or responses.

Why this does not compete with CloudNomad

This PR provides a narrow open-source capability: pairing a browser with a user’s own running CodeNomad instance. It does not provide CloudNomad accounts, organizations, hosted workspaces, managed authentication, billing, GitHub integration, administration or a general cloud control plane.

The intended relationship is:

• CodeNomad Remote Control offers a simple, self-hosted/outbound relay mode;
• CloudNomad remains the managed product and owns account-level services, signaling, TURN, GitHub webhooks and other proprietary cloud capabilities;
• CloudNomad can use WebRTC as its primary data path, through direct ICE and then TURN;
• the encrypted WebSocket relay can remain a standalone OSS option and later serve as a fallback when WebRTC cannot connect;
• the pairing, encryption and local authorization layers can eventually be shared without making the open-source desktop application depend on CloudNomad.

In short, Remote Control provides transport to an existing user-owned instance; CloudNomad provides the managed product around it.

3. GitHub Pages help site — PR #859

#859

The repository currently has no active Pages site. An administrator needs to perform the one-time setup:

1. Open Repository Settings → Pages.
2. Under Build and deployment, select GitHub Actions as the source.
3. If the github-pages environment has deployment protection rules, allow deployments from dev.

The workflow will then publish the English help site from dev at:

https://neuralnomadsai.github.io/CodeNomad/

No additional hosting service, custom domain or deployment secret is required.

4. iOS source handoff and native validation — PR #861

#861

This PR is currently source preparation only. It does not claim to provide a linked iOS application, an IPA, device validation or App Store readiness.

The next stage requires your involvement because it needs a supported, owned Mac and iOS device:

1. Review the source, dependency and security handoff first.
2. Agree on an unsigned, non-distribution native build procedure.
3. Build and link the locked native graph using a supported Mac with full Xcode, CocoaPods, Node and Rust.
4. Validate the Rust/Swift/Tauri boundary and lifecycle behavior.
5. Test authentication, cookies, SSE, navigation restrictions, TLS failures, recovery, background/resume behavior, accessibility and draft preservation on a real device.

The existing ios:build command must not be used as the initial validation command because it requests an App Store Connect export. We should first define a separate unsigned validation path.

Apple signing certificates, the Apple developer account, provisioning profiles, App Store export and store submission would be a later and separately authorized step. We also need to assess whether the companion provides enough native functionality for App Review guideline 4.2.

Let me know when you are available. I can prepare a short checklist and walk through each repository, Cloudflare and Apple-side action with you.