Mastodon exposes a moderation/administration API under /api/v1/admin/* with these subcategories:
- Accounts
- Canonical email blocks
- Dimensions
- Domain allows
- Domain blocks
- Email domain blocks
- IP blocks
- Measures
- Reports
- Retention
- Trends
That's roughly 30+ additional endpoints requiring admin-scoped tokens (admin:read/admin:write), a distinct entity namespace (Admin::Account, Admin::Report, ...), and a user base (moderation tooling) different from Hunter's typical client use case.
Question to settle before any implementation: should Hunter cover the Admin API at all, and if so, in-tree (e.g. a Hunter.Admin.* namespace) or as a separate package?
Options:
- In-tree
Hunter.Admin.* — one dependency for bot/tooling authors, but roughly doubles the API surface to maintain
- Separate
hunter_admin package built on Hunter's request layer
- Out of scope — document the decision and close
Part of the Mastodon 4.6 API parity effort.
References
Mastodon exposes a moderation/administration API under
/api/v1/admin/*with these subcategories:That's roughly 30+ additional endpoints requiring admin-scoped tokens (
admin:read/admin:write), a distinct entity namespace (Admin::Account,Admin::Report, ...), and a user base (moderation tooling) different from Hunter's typical client use case.Question to settle before any implementation: should Hunter cover the Admin API at all, and if so, in-tree (e.g. a
Hunter.Admin.*namespace) or as a separate package?Options:
Hunter.Admin.*— one dependency for bot/tooling authors, but roughly doubles the API surface to maintainhunter_adminpackage built on Hunter's request layerPart of the Mastodon 4.6 API parity effort.
References