generated: '2026-08-27'
method: derived
source: >-
  Scope string read verbatim from Elk's published source —
  https://github.com/elk-zone/elk/blob/main/server/api/[server]/login.ts (scope: 'read
  write follow push') and the identical scope on the token exchange in
  server/api/[server]/oauth/[origin].ts. Scope semantics from the Mastodon OAuth scopes
  reference, https://docs.joinmastodon.org/api/oauth-scopes/ .
  derive-oauth-scopes.py found 0 oauth2 schemes because Elk publishes no OpenAPI.
provider: Elk
providerId: elk
docs: null
authorizationUrl: https://{server}/oauth/authorize
tokenUrl: https://{server}/oauth/token
note: >-
  THESE ARE MASTODON'S SCOPES, NOT ELK'S. Elk does not define a permission vocabulary;
  it requests a fixed, non-configurable set of top-level Mastodon scopes on every sign-in
  and never asks for less. That is a real finding about Elk's consent posture: a user
  signing into Elk cannot grant read-only access, because the client hard-codes write,
  follow and push alongside read. There is no incremental or per-feature consent.
requested_scopes:
  - name: read
    granted: always
    description: Read all account data — timelines, statuses, notifications, lists, bookmarks, filters, search.
  - name: write
    granted: always
    description: Create, edit and delete statuses and media; update account settings, lists, filters and bookmarks.
  - name: follow
    granted: always
    description: Manage relationships — follow, unfollow, block, mute, and domain blocks.
  - name: push
    granted: always
    description: Subscribe to and receive Web Push notifications for the account.
granularity:
  incremental_consent: false
  per_feature_scopes: false
  read_only_option: false
  evidence: >-
    The scope string is a hard-coded literal in both the authorize-URL builder and the
    token exchange. No code path narrows it and no setting exposes it.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com