Confirm external backend trust changes in the desktop app
- Dominant language
- Rust
- Stars
- 54.2k
- Forks
- 6.2k
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 240
Description
**What problem would this solve?**
The desktop app currently applies external-backend connection settings as soon as its renderer submits a generic settings update. Changing the backend origin or credentials changes which service the app trusts, but the user does not get a distinct review-and-confirm step for that trust change.
**What would a good outcome look like?**
Users can clearly review and approve an external-backend trust change before the desktop app persists it or reconnects. The design should define which process owns validation and authorization, what exact origin or server identity is shown, and how cancellation and rollback behave.
**Possible approaches**
- Use an explicit Apply flow with main-process schema validation and a native confirmation showing the exact normalized backend origin and any available identity or fingerprint.
- Separate external-backend trust settings from ordinary renderer-managed preferences.
- If silent renderer-authorized changes are intentional, document that renderer authority and the compatibility constraints that prevent an explicit confirmation.
The design should account for settings import, automation, and existing external-backend users without committing to implementation before maintainers choose the intended trust model.
**Additional context**
- [x] I have verified this does not duplicate an existing feature request
Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).
Contributor guide
Research direction
The issue concerns the desktop app's external-backend connection settings. Start by examining the code that handles settings updates in the renderer and main processes, particularly where backend origin or credentials are applied. Look for existing validation logic and how the app currently reconnects. Determine what constitutes a 'trust change' and how to present it for user confirmation, considering settings import and automation scenarios.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend-api-design, desktop, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100