Finish or redesign GitHub authorization for plugin discovery

[howdeploy]

Context

GitHub-based plugin discovery (the Plugin Showcase) and GitHub OAuth Device Flow were merged through #16 and #17. The implementation entered the codebase, but the public user flow was not brought to a clear, release-ready conclusion.

This issue is intended to collect maintainer and community feedback on whether this feature should remain, become genuinely optional, or be removed until there is a stronger product need.

Current behavior

In Settings → Plugins:

• A user can inspect and install a plugin from a public GitHub repository URL.

• Plugin Showcase search is blocked by the UI until the user authorizes CanvasTTY with GitHub.

• Clicking Sign in with GitHub starts an OAuth Device Flow.

• A build without a configured project OAuth Client ID fails with an implementation-level error such as:

  Error invoking remote method 'github-auth:start':
  Error: GitHub OAuth is not configured (missing client id).
  

• The UI does not clearly explain before authorization why a GitHub account is required, what benefit authorization provides, what access is requested, or why public plugins cannot be browsed anonymously.

There is also a mismatch between the UI policy and the underlying implementation:

• PluginManager.searchShowcase() already contains an anonymous REST Search API fallback when no OAuth token is available.
• PluginSettingsSection prevents showcase search without githubAuthorized, so users cannot reach that fallback through the UI.
• The OAuth request currently asks for no additional scopes, so its practical purpose is access to public GitHub data with authenticated API limits, not access to private repositories.

Relevant code:

• src/main/services/GithubAuthService.ts
• src/main/services/PluginManager.ts
• src/main/ipc/registerIpc.ts
• src/renderer/src/features/plugins/PluginSettingsSection.tsx
• src/shared/contracts.ts
• electron.vite.config.ts
• .github/workflows/release.yml

Problem

An optional plugin-discovery feature currently behaves like a mandatory account connection without making the value or trust boundary clear to the user.

For a public desktop application, end users should never need to provide a personal access token, OAuth Client Secret, or their own developer credentials. If CanvasTTY keeps OAuth, the project owns and ships the public OAuth client configuration; each user only authorizes their own GitHub account.

At the moment, the feature has several unresolved product and UX questions:

• Is GitHub authorization actually necessary for browsing public plugins?
• Is Plugin Showcase valuable enough to justify account authorization and the associated maintenance burden?
• Should authorization be optional and used only to raise GitHub API limits?
• Should the current GitHub-as-registry approach remain, or should discovery wait for a curated catalog?
• If OAuth remains, is Device Flow still the right UX for an Electron desktop app, or should a browser redirect with PKCE be used?

Proposed product direction

The preferred baseline for discussion is:

1. Public plugin discovery works anonymously by default through the existing public REST fallback.
2. GitHub authorization, if retained, is explicitly optional and presented as a way to improve API limits or enable a future account-specific capability.
3. CanvasTTY explains the reason, requested access, local token storage, and disconnect/revoke path before opening GitHub authorization.
4. If the community does not see enough value in Plugin Showcase, remove or hide the unfinished showcase/OAuth flow for now while preserving direct installation from a public repository URL.

If maintainers instead decide that OAuth must be mandatory, the feature needs to be completed end to end: project-owned OAuth app configuration, release-time validation, user-facing rationale, graceful cancellation/retry, and actionable errors. A public release must not expose a missing Client ID as an end-user problem.

Expected user experience

• Direct installation from a public repository remains available without GitHub login.
• Opening Plugins does not immediately create an unexplained account requirement.
• Before any OAuth launch, the UI states exactly why CanvasTTY wants GitHub access and what changes after authorization.
• Network failures, rate limits, user denial, cancellation, and unavailable OAuth configuration produce actionable user-facing states rather than raw IPC errors.
• No flow asks the user for a Client Secret, personal access token, or developer credentials.

Acceptance criteria

• Maintainers/community choose and document one product contract: anonymous discovery, optional OAuth, mandatory OAuth, or removal of Showcase until later.
• Renderer gating and PluginManager behavior implement the same contract.
• A public release never fails with GitHub OAuth is not configured (missing client id) after a normal user click.
• The authorization rationale, access level, token handling, and disconnect/revoke behavior are explained in the UI and documentation if OAuth remains.
• Anonymous public plugin installation continues to work.
• Search has explicit loading, empty, rate-limited, unavailable, denied, and cancelled states as applicable.
• Release configuration validates every credential/configuration value required by the chosen flow.
• Tests cover anonymous search, authorized search, missing configuration, cancellation, denial, network failure, and rate limiting.
• docs/plugins.md and translations describe the final behavior without requiring end users to configure developer credentials.

Community feedback requested

Please comment on the workflow you would expect as a CanvasTTY user:

• Browse public plugins without signing in, with optional GitHub authorization for higher limits.
• Sign in to GitHub before using plugin discovery, with a clear explanation of why.
• Keep direct repository installation only and remove/hide Plugin Showcase for now.
• Prefer another discovery model, such as a curated registry.