Mark/mesh-seed

Fork 0

AUTH-002: OAuth2 Integration #138

New issue

Closed

opened 2026-04-11 05:48:19 +00:00 by Mark · 2 comments

Mark commented

2026-04-11 05:48:19 +00:00

Owner

Required

Google OAuth login
GitHub OAuth login
Discord OAuth login
User profile mapping

Acceptance Criteria

OAuth flow works for all providers
User accounts auto-created
Profile info synced
Token exchange working

## Required - Google OAuth login - GitHub OAuth login - Discord OAuth login - User profile mapping ## Acceptance Criteria - [ ] OAuth flow works for all providers - [ ] User accounts auto-created - [ ] Profile info synced - [ ] Token exchange working

Mark added the

feature-request

label

2026-05-12 23:53:05 +00:00

Mark added

blocked:needs-decision

and removed

feature-request

labels

2026-05-21 02:09:26 +00:00

Mark removed the

blocked:needs-decision

label

2026-05-28 07:19:09 +00:00

Mark added the

blocked:needs-decision

label

2026-06-07 05:26:59 +00:00

Mark commented

2026-06-07 05:26:59 +00:00

Author

Owner

⏸ Needs Decision

What needs to be decided?

Should the spec be adjusted or is this still worth doing? If yes, remove the blocked:needs-decision label and the triage will approve it.

Blocking factors:

Spec misaligned — doesn't align with project direction

Scope: medium Risk: medium Spec: misaligned Type: feature
Summary: Add OAuth2 login support for Google, GitHub, and Discord providers with user profile mapping and token exchange.
Suggestion: If auth is needed for the API gateway admin layer, implement via Authlib/Flask-Dance on the existing Flask gateway; externalize provider client IDs/secrets to env/config; store user profiles in a new substrate/user.py module. However, this issue is fundamentally outside the project's documented scope.
Rationale: SCOPE=medium: OAuth2 requires a new auth subsystem (provider handlers, user model, token management, profile sync) estimated at 8-15 files. The existing API gateway (Flask) provides a natural integration point but has no auth infrastructure today. RISK=medium: OAuth2 is security-sensitive — callback URL validation, state/CSRF tokens, token storage, and provider-specific quirks — but it's purely additive and doesn't touch the core mesh substrate (ledger, backplane, bidding, worker spawning). SPEC=misaligned: The project is a distributed mesh computing system with agent orchestration and ledger-based economics. AGENTS.md documents infrastructure bidding, worker spawning, capability execution, and intent routing. There is zero mention of user accounts, web logins, profiles, or authentication anywhere in the spec or existing codebase. The API gateway exists solely for mesh network operations (prometheus metrics, WebSocket intents). Adding user-facing OAuth introduces an entirely new domain that doesn't align with any documented project goal. TYPE=feature: additive capability with no bug fix or security patch involved.

To unblock: Remove the blocked:needs-decision label. The triage will apply the appropriate outcome based on your choice above.

## ⏸ Needs Decision **What needs to be decided?** - **Should the spec be adjusted or is this still worth doing?** If yes, remove the `blocked:needs-decision` label and the triage will approve it. **Blocking factors:** - **Spec misaligned** — doesn't align with project direction --- **Scope:** medium **Risk:** medium **Spec:** misaligned **Type:** feature **Summary:** Add OAuth2 login support for Google, GitHub, and Discord providers with user profile mapping and token exchange. **Suggestion:** If auth is needed for the API gateway admin layer, implement via Authlib/Flask-Dance on the existing Flask gateway; externalize provider client IDs/secrets to env/config; store user profiles in a new substrate/user.py module. However, this issue is fundamentally outside the project's documented scope. **Rationale:** SCOPE=medium: OAuth2 requires a new auth subsystem (provider handlers, user model, token management, profile sync) estimated at 8-15 files. The existing API gateway (Flask) provides a natural integration point but has no auth infrastructure today. RISK=medium: OAuth2 is security-sensitive — callback URL validation, state/CSRF tokens, token storage, and provider-specific quirks — but it's purely additive and doesn't touch the core mesh substrate (ledger, backplane, bidding, worker spawning). SPEC=misaligned: The project is a distributed mesh computing system with agent orchestration and ledger-based economics. AGENTS.md documents infrastructure bidding, worker spawning, capability execution, and intent routing. There is zero mention of user accounts, web logins, profiles, or authentication anywhere in the spec or existing codebase. The API gateway exists solely for mesh network operations (prometheus metrics, WebSocket intents). Adding user-facing OAuth introduces an entirely new domain that doesn't align with any documented project goal. TYPE=feature: additive capability with no bug fix or security patch involved. **To unblock:** Remove the `blocked:needs-decision` label. The triage will apply the appropriate outcome based on your choice above.

Mark added the

blocked:preflight

label

2026-07-31 04:26:46 +00:00

Mark closed this issue

2026-08-11 03:53:43 +00:00

Mark commented

2026-08-11 03:53:43 +00:00

Author

Owner

AUTH-002 OAuth2 Integration — spec misaligned, closing as wontfix

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Mark/mesh-seed#138

No description provided.

Rows
Columns