6529-Desktop

Overview

6529 Desktop App supporting Windows, MacOS and Linux

Native notification previews

Desktop notifications on Windows, macOS, and Linux show readable plain text from drop Markdown. Headings, list bullets and numbering, link labels, mentions, emoji, and code remain readable. Emphasis and strikethrough markers, media URLs, and empty lines are removed. Blockquotes use curly double quotes (alternating with single quotes when nested); inline code uses curly single quotes. Multiline code remains plain text.

Formatting happens before the operating system clips the preview. Empty previews show attachment filenames, a media attachment label, or the usual default message. Drop content and Markdown rendering inside the app are unchanged.

Structure

electron-src

This folder holds the code specific to ElectronJS

renderer

This is a subtree of 6529seize-frontend repository (https://github.com/6529-Collections/6529seize-frontend)

Usage

6529seize-frontend

Get Updates from 6529seize-frontend repository

Checkout branch 'pull-web' and merge main into it (make sure your local main is up to date)

git checkout pull-web
git merge main

Bootstrap the repo-scoped 6529 wrapper once from the repo root:

./bin/6529 bootstrap

Then open a new shell, or activate the current one immediately:

source <(./bin/6529 bootstrap --print-export)

Install dependencies for both the Electron repo and the renderer/ subtree:

6529 install

Do not cd renderer for bootstrap or installs in this repo. The supported entrypoint is the root wrapper only.

Run the following command to fetch new changes from branch main of 6529seize-frontend:

6529 pull-web

The command refuses to run outside the long-lived pull-web branch and checks the desktop renderer contract after the subtree import. In particular, Electron wallet sessions must remain client_type=desktop, use the secure main-process nativeAuth bridge, and retain working Cancel/Escape behavior while a signature is pending. Authentication must stay below Core wallet unlock/request prompts, cancelled signatures must not commit later, and a Core connector must never reuse another wallet's stored address. The Core connector chooser must remain wide enough for compact active/switch wallet states, must render inside the connection context those states consume, and must share the Core request prompt's responsive 40rem maximum width and min(78dvh, 40rem) maximum height. Neither modal uses a fixed height; long bodies scroll internally while request actions remain fixed. Route error fallback UI must remain independent of application providers. The /browser-connector transfer page must also remain isolated from app-global Quick Direct Messages, cookie consent/analytics, version notices, and automatic wallet-auth prompts. Restore those desktop adaptations if the guard fails; do not remove or weaken the guard.

The Core renderer does not mount the web frontend's environment badges or favicon manager in any app mode. Desktop environment/backend information is shown by the native titlebar instead, so do not add a second badge below the logo or favicon links to the renderer layout during conflict resolution.

Core-only /core routes do not expose page sharing because they have no public browser equivalent. On other shareable routes, Electron uses BASE_ENDPOINT for public links and shows a globe-labeled Open in 6529.io instead of the redundant Open in 6529 Desktop action; the public page opens in the system browser.

⚠️ Note: there might be conflicts that need resolving

Packages

Renderer dependencies are installed from renderer/package.json.
After pulling frontend changes (or on a fresh clone), run:

6529 install

Checklist

• start from latest main
• checkout branch pull-web
• merge main into pull-web
• run 6529 pull-web
• resolve conflicts
• keep the root package version and related version metadata identical to current main; never bump the desktop version on pull-web
• run 6529 install
• update tailwind.config.js with any incoming changes from renderer/tailwind.config.js
• merge any relevant renderer/next.config.ts changes into root next.config.ts
• ensure renderer/next.config.ts is removed; this repo uses the root Next config overlay
• run 6529 run guard:desktop-renderer-contract

Running locally - dev

Use:

6529 install
6529 run dev

or if running on a Windows machine:

6529 install
6529 run dev-win

Optional dependency security check:

6529 run audit-deps

The 6529 shim is repo-scoped. After bootstrap it is only injected while your current working directory is inside this repository tree; it is not intended to become a machine-global command.

CI and GitHub Actions now use the same root pnpm flow. There is no separate npm bootstrap path for Windows signing or CloudFront invalidation jobs.

Normal desktop builds run the Core-owned Electron test suite before compiling the renderer. That suite includes a contract test outside renderer/, so a future frontend subtree sync cannot silently remove desktop authentication or modal-escape behavior, hide Core wallet prompts behind authentication, accept a late cancelled signature, cross-wire Core wallet addresses, or reintroduce global application UI on the isolated browser connector. It also preserves the shared responsive chooser/request envelope, its required connection-context nesting, a provider-independent route error fallback, compact Core wallet active/switch states, fixed request actions, and public-origin page sharing in Electron.

Building and Publishing

⚠️ IMPORTANT: Before building and publishing a new version of the app, make sure to update the version in package.json. If you skip this step, the previous version may be overwritten and the electron-updater will not function correctly.

Perform that version update only on an explicitly requested release branch created from main and named for the version. Release from that branch, then merge it back to main. Never update the desktop version as part of a pull-web renderer sync; pull-web must retain the version from current main.

Desktop Backend Targets

Desktop distribution scripts take an optional backend target argument:

• default or live: use the live backend
• test: use the staging/test backend

The backend target is separate from the app environment (local, staging, or production). The app environment still controls the package config, protocol scheme, update channel, and splash/titlebar app label. The backend target controls the canonical public web origin, API and WebSocket endpoints, plus the staging access header when building against Test. The embedded renderer still runs on localhost; public page sharing uses the canonical web origin instead of exposing that internal address.

Live backend:

BASE_ENDPOINT=https://6529.io
API_ENDPOINT=https://api.6529.io
WS_ENDPOINT=wss://ws.6529.io

Test backend:

BASE_ENDPOINT=https://staging.6529.io
API_ENDPOINT=https://api.staging.6529.io
WS_ENDPOINT=wss://ws.staging.6529.io

Examples:

6529 run dev                     # Dev app, Live backend; label: Dev / Live
6529 run dev test                # Dev app, Test backend; label: Dev / Test
6529 run dist-mac-local          # Local app, Live backend; label: Local / Live
6529 run dist-mac-local test     # Local app, Test backend; label: Local / Test
6529 run dist-mac-staging        # Staging app, Live backend; label: Staging / Live
6529 run dist-mac-staging test   # Staging app, Test backend; label: Staging / Test
6529 run dist-mac-production     # Production app, Live backend; no label suffix

Production app builds must not target the Test backend. Commands such as 6529 run dist-mac-production test fail immediately before build work starts. The same optional live/test argument applies to the Windows, macOS, and Linux dist-* scripts.

Test backend builds require a local staging access key:

# .env.local, never committed
STAGING_API_KEY=your-staging-access-key

.env.local is gitignored. The key is baked only for test backend builds. For desktop builds it is written to Electron's private main-process runtime config, not the renderer/public runtime bundle. Live backend builds intentionally omit STAGING_API_KEY, even if it exists in the local shell or .env.local.

Public GIF provider keys are read from local environment variables and baked into the renderer runtime config for desktop builds. config/public-runtime.json keeps an empty placeholder for the Giphy key and remains the tracked fallback for non-secret public defaults. Keep real GIF key values in .env, never in config/public-runtime.json. Keep .env.local for machine-specific local-only values such as STAGING_API_KEY. Both root .env and .env.local are gitignored:

# .env, never committed
GIPHY_API_KEY=your-giphy-api-key

Rebuilding SQL

This project uses better-sqlite3 When changing between building different platforms, you need to rebuild this package first by running:

6529 run rebuild-sql

Use the following steps to build for each platform:

Windows

Build

Staging

6529 run dist-win-staging-upload

Production

6529 run dist-win-production-upload

The above commands will:

• build the project (renderer + electron-src)
• run electron-builder which will create Windows related artifacts
• upload artifacts to S3 at location 6529bucket/6529-staging-core-app/win-unsigned/ or 6529bucket/6529-core-app/win-unsigned/

Sign

Use Build All Platforms GitHub workflow

• Branch: select your branch
• Environment: select between Staging or Production
• Version: type version to build (must match the new version in package.json)
• Flow: Sign Windows

MacOS

Staging

6529 run dist-mac-staging

Production

6529 run dist-mac-production

Packaged versions: arm64 (silicon), x64 (intel)

Linux

Use Build All Platforms GitHub workflow

• Branch: select your branch
• Environment: select between Staging or Production
• Version: type version to build (must match the new version in package.json)
• Flow: Linux

Publish Links

Once all 3 platforms are built, we publish the downloads links per platform / packaged version in html pages saved on S3. To do this use Use Build All Platforms GitHub workflow

• Branch: select your branch
• Environment: select between Staging or Production
• Version: type version to build (must match the new version in package.json)
• Flow: Publish

The above will extract the latest download links per platform and create html pages per platform for this new version on s3 in the following format: https://d3lqz0a4bldqgf.cloudfront.net/6529-core-app/<os>/links/<version>.html You should get 3 html links (one per platform) which can be shared on Brain in the 6529 Desktop Releases Wave. Note: the above github workflow will create links both to s3 and arweave and add them to the htmls automatically.