v1.0.5

Changes

chore: drop macos intel build from release workflow - @TRC-Loop in #37

Removes the Intel entry from the macOS release matrix; releases now ship Apple Silicon only. Updates the README download instructions to match.

chore: flatten release changelog into one list - @TRC-Loop in #43

Collapses the Features / Bug Fixes / Other Changes sections in the auto-generated release notes into a single flat list. GitHub doesn't support alphabetical sorting within a category, so entries stay in merge order, but since PR titles already carry their conventional-commit type prefix (feat:, fix:, ...), same-type PRs merged together still tend to cluster.

feat: add mailbox button in the Mailboxes settings tab - @TRC-Loop in #41

Settings > Mailboxes only let you edit or remove existing mailboxes; there was no way to add one from there (the empty state literally pointed at "the Mailbox menu" instead). Adds an "Add mailbox…" button that opens the existing add-mailbox wizard (lazy-loaded like the other settings modals) right from the tab, and refreshes the list and sidebar once a mailbox is added.

feat: add privacy mode choice to onboarding - @TRC-Loop in #46

Adds a new onboarding step, right after the feature highlights, where the user picks between two existing settings combined into one decision:

• Fully Private (Recommended): generated avatars only (no Gravatar/BIMI lookups), remote images in mail always blocked until loaded per message.
• Normal: sender photos from Gravatar/verified domain logos, remote images load automatically without asking.

Each card states plainly what it turns on/off. Selecting applies immediately (setAvatarSource + setAlwaysLoadImages, both already existing settings-store functions used by the Settings panel), matching the rest of onboarding's "every pick applies live" behavior. The current selection is derived from those two settings rather than stored separately, so re-running onboarding shows the actual active mode, not a guess.

i18n across en/de/fr/nl/es.

feat: add website and docs links to About settings - @TRC-Loop in #42

Adds Website (pelton.app) and Docs (docs.pelton.app) buttons next to the existing GitHub/Report an issue/Contributors links in Settings > About, opening in the system browser like every other link there.

feat: export as a modal with mailbox and signature categories - @TRC-Loop in #38

Replaces the inline export checkboxes/button in Settings > Import/Export with a modal (styled after the image-allowlist modal), reached from a single Export button. Also expands what can be exported.

• New ExportModal.svelte, lazy-loaded like the allowlist modal.
• Two new export/import categories: Mailboxes (account server config only, no passwords/tokens, those stay in the OS keyring) and Signatures.
• Import gets matching checkboxes for the new categories, shown only when the picked file actually contains them; importing mailboxes skips any email already present locally to avoid duplicates, same dedupe for signatures by name+kind.
• i18n across en/de/fr/nl/es, including a hint that imported mailboxes need their password re-entered since credentials never leave the keyring.

feat: localize the native application menubar - @TRC-Loop in #45

The native menu bar (built in Go, before the webview or any frontend i18n exists) stayed hardcoded in English regardless of the app's language setting.

• New internal/desktop/menu_i18n.go: a Go-side translation table for every menu label, covering en/de/fr/nl/es (falls back to English for anything else).
• buildMenu now reads the current language setting and looks up strings from there instead of hardcoding them.
• New App.RebuildMenu() swaps in a freshly-built menu via wails runtime.MenuSetApplicationMenu; SetSetting calls it whenever the language key changes, so switching language (in onboarding or Settings) updates the menu immediately instead of only on next launch.
• The Mail menu's enabled/disabled state (whether a message is open) is now tracked on the App struct (mailActionsEnabled) so a menu rebuild restores it instead of resetting every item back to disabled.

Not translated: macOS's built-in menu.EditMenu() (Cut/Copy/Paste/Select All/Undo/Redo) ships with fixed English labels from wails itself with no override hook.

feat: optional encrypted password export for mailboxes - @TRC-Loop in #47

Extends the Mailboxes export/import category (from the export modal PR) with an opt-in way to carry credentials along too, instead of always requiring a re-login after importing.

Export

• New checkbox under Mailboxes: "Also include passwords (encrypted)", which reveals a password + confirm field (min 8 chars, must match).
• Each account's stored credential (loaded from the OS keyring the same way sync already does) is JSON-encoded and sealed with AES-256-GCM, keyed by a value derived from that password via scrypt (N=2^15) with a fresh random salt per account. Nothing is ever written in plain text; accounts with no stored credential are exported without one, not blocked.
• This password is never Pelton's own anything - it only exists to protect this one file, and there's no recovery if it's forgotten (same tradeoff as any password-encrypted export/zip).

Import

• The inspect step now reports whether the picked file carries any encrypted credentials at all (hasEncryptedCredentials), so the checkbox only appears when there's something to restore.
• A wrong password fails loudly (AES-GCM's auth tag check) rather than silently skipping credentials or importing garbage.
• Both the export and import password fields are entirely optional; leaving them out preserves today's behavior exactly (mailboxes import needs sign-in again).

i18n across en/de/fr/nl/es. golang.org/x/crypto (already an indirect dependency via go-keyring/wails) is now direct for scrypt.

feat: show a persistent developer mode indicator in the status bar - @TRC-Loop in #44

When PELTON_DEV is set (the make run / wails dev loop), the app already points at a separate "Pelton-dev" data directory so a dev run never touches a real install's accounts or mail - but there was no visual sign of it in the running app, easy to forget mid-session.

Adds App.IsDevMode() on the backend (reads the same env var storage.DefaultPath already checks) and a small "DEVELOPER MODE" badge at the left of the status bar, always visible whenever it's on, i18n'd across en/de/fr/nl/es.

fix: copr srpm build failing on fedora 43/44 - @TRC-Loop in #49

The v1.0.5 Copr build (https://copr.fedorainfracloud.org/coprs/build/10709296) failed on both fedora-43-x86_64 and fedora-44-x86_64, which is why dnf install pelton found an empty repo after enabling the Copr project - nothing had actually built.

Root cause, from the Copr build log:

warning: line 21: Possible unexpanded macro in: Version:        %{_pelton_version}
error: bad date in %changelog: Thu Jan 01 1970 Pelton release automation <me@arne.sh> - 0-1
error: Bad file: /builddir/build/SOURCES/pelton-%{_pelton_version}.tar.gz: No such file or directory

Two separate bugs, both in how the spec interacts with a newer rpm (6.x, shipped in Fedora 43+):

1. Unexpanded %{_pelton_version}. The release workflow passed the version via rpmbuild --define "_pelton_version $VERSION", but that only affects that one local invocation - it's never stored inside the resulting SRPM. Copr re-runs rpmbuild -bs from the spec bundled in the SRPM as its own first build step, with no knowledge of that external define, so Version:/Source0: came out completely unresolved there. Fixed by baking %global _pelton_version <version> into the spec text itself before building, so it's self-contained.
2. %changelog's placeholder date rejected. Fedora 43+'s rpm derives SOURCE_DATE_EPOCH from the top %changelog entry by default; our static placeholder entry's fake Thu Jan 01 1970 date got rejected outright as a "bad date" by the newer parser. Disabled that derivation in the spec (_source_date_epoch_from_changelog 0, both macro spellings for safety) since we don't need reproducible-build timestamps from a placeholder changelog entry.

Also earlier in this pipeline: bug #36 (fedora-copr-rpm PR) fixed AutoReqProv/debug_package, which addressed a different failure mode. This is a second, independent bug that only shows up once the SRPM build itself can actually complete.

fix: email links not clickable in message body - @TRC-Loop in #40

The message body renders in a sandboxed srcdoc iframe (allow-same-origin only) with clicks intercepted by a parent-script listener that hands the URL to BrowserOpenURL. Reported as completely dead: clicking a link did nothing.

I verified the click-interception JS pattern itself works correctly in a real browser engine (scripted repro: same sandbox/CSP/listener/regex, click dispatched, preventDefault + URL handoff both fired as expected). That points at the listener never getting attached in time in the live app rather than a logic bug — most likely load firing (or the listener registering) after the point a click was expected to work, which is engine/timing-dependent and wasn't caught by build/typecheck.

Two independent fixes, so either one failing doesn't leave the user stuck:

• The iframe sandbox now also allows allow-popups allow-top-navigation-by-user-activation, so a genuine user click on a target="_blank" link (which the sanitizer already adds for external links) can trigger the browser's own new-context navigation, which Wails already redirects to the OS default browser the same way it does for any other external link in the app - independent of whether our own JS listener attached.
• The listener attachment no longer relies solely on the iframe's load event. It now also polls (briefly, via requestAnimationFrame) until the srcdoc's real body is present, using a data-pelton-ready marker to tell it apart from the iframe's transient initial blank document, and (re)attaches from there. This covers mailto: links too, which don't get target="_blank" and so don't benefit from the sandbox change.

fix: flatten and alphabetize the draft release changelog script - @TRC-Loop in #48

My earlier PR #43 edited .github/release.yml, but that file only configures GitHub's native "Generate release notes" button/API - the actual v1.0.5 draft release was built by a completely separate mechanism, .github/workflows/draft-release.yml, which has its own hardcoded Features/Bug Fixes/Other Changes categorization in a github-script step and never reads release.yml at all. That's why the v1.0.5 draft still showed "## Other Changes" as a single section despite #43.

This fixes the actual script: removes the category split, sorts merged PRs alphabetically by title (feat: naturally sorts before fix: since the type prefix is part of the title), and renders one "## Changes" section.

Full Changelog: v1.0.4...v1.0.5