Skip to content

Phase 3: Roadie access policy and redirect configuration for Beeper authentication #1

@chubes4

Description

@chubes4

Goal

Configure the Roadie agent so non-technical team members can authorize and use it remotely from Beeper via the new browser-based login flow.

This issue covers the agent policy / platform configuration portion of the full-stack implementation.

Context

The auth and bridge mechanics live in:

  • Extra-Chill/data-machine
  • Extra-Chill/data-machine-chat-bridge
  • Extra-Chill/mautrix-data-machine

This repo should own the Roadie-specific policy layer:

  • who can access Roadie
  • whether access is explicit or filter-based
  • redirect allowlist configuration
  • any Roadie-specific UX or constraints

Phased approach

Phase 3A — Agent policy

  • Confirm the canonical Roadie agent slug and deployment target
  • Confirm Roadie exists and is active in the intended site scope
  • Decide whether access should be granted by:
    • explicit agent access rows
    • datamachine_can_access_agent filter logic
  • Ensure at minimum that qrisg and indigxld can authorize and use Roadie

Phase 3B — Redirect allowlist

  • Add the Beeper / bridge callback URI(s) to Roadie allowed_redirect_uris
  • Validate production and local/dev callback patterns separately if needed
  • Verify authorize flow succeeds without weakening redirect validation broadly

Phase 3C — Product / trust UX

  • Ensure the consent screen reads clearly as "Authorize Roadie"
  • Ensure Roadie display name and agent metadata are sane for end users
  • Ensure token labels / logs make bridge-issued tokens understandable and auditable

Phase 3D — Validation

  • Validate qrisg happy path
  • Validate indigxld happy path
  • Validate denied user path
  • Validate revoke / logout behavior if Roadie access changes

Deliverables

  • Roadie is actually authorizable by intended team members
  • redirect allowlist is configured correctly
  • Roadie policy is explicit and maintainable
  • Beeper auth succeeds for allowed users and fails cleanly for disallowed users

Dependencies

  • Depends on browser PKCE login flow in Extra-Chill/mautrix-data-machine
  • Depends on bridge auth/contract stabilization in Extra-Chill/data-machine-chat-bridge

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions