Skip to content

docs(roadmap): pin external-validation note — gateway is 1:1 prior ar… - #78

Merged
hyperpolymath merged 5 commits into
mainfrom
docs/external-validation-wiki-api-prior-art
Aug 11, 2026
Merged

docs(roadmap): pin external-validation note — gateway is 1:1 prior ar…#78
hyperpolymath merged 5 commits into
mainfrom
docs/external-validation-wiki-api-prior-art

Conversation

@hyperpolymath

Copy link
Copy Markdown
Owner

…t for proposed GitHub wiki-API anti-abuse design

While drafting a community/community feature request asking for a REST + GraphQL surface to create/seed repository wikis (re-file of #196186), the proposal's "anti-abuse considerations" section names five mechanisms that should be baked into any new write-API for an agent-collaborative world. Internal audit confirmed http-capability-gateway already implements a 1:1 mapping of every one of them in shipping code:

  • Per-author rate limits → RateLimiter (token-bucket per {client_ip, trust_level})
  • Token scope gating → SafeTrust capability lattice (formally verified in Idris2)
  • Human-attestation header → A2ML tamper-evident JSON envelopes
  • Audit metadata surface → VeriSimDB durable append-only trail
  • Org-level opt-in → YAML Verb Governance Spec compiled to ETS
  • Per-page review queue → K9-SVC SLA + breach policies
  • Bonus beyond proposal: mTLS client cert → X.509 OU → capability; stealth mode; policy versioning; atom-exhaustion DoS defence

Adds a new "External validation" section to ROADMAP.adoc capturing the mapping in table form. Explicitly NOT a commitment to externalise the gateway as a GitHub-API drop-in — MVP scope per the sections above is unchanged. The note is a reference anchor for two reasons:

  1. If a Hubber engages on the discussion thread asking "do you have prior art?" — the gateway is the answer, documented in advance.

  2. Confidence anchor for the narrow MVP — knowing the design maps cleanly onto an externally-recognised problem strengthens the argument that the narrow scope is on the right axis.

Snapshot pinned at 2026-05-28; future divergence between the discussion thread and the gateway scope is documented at the point it arises, not here.

Summary

Closes #

Type of change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 💥 Breaking change (would change existing behaviour)
  • 🕳️ Soundness fix (fixes a checker/proof false-negative)
  • 📖 Documentation
  • 🧹 Refactor / tech debt (behaviour-preserving)
  • ⚡ Performance
  • 🔧 Build / CI / tooling

How has this been verified?

Checklist

  • My commits are signed (git commit -S).
  • I ran the project's own checks/tests locally and they pass.
  • New files carry the correct SPDX-License-Identifier (code/config MPL-2.0,
    prose CC-BY-SA-4.0); I did not relicense existing files.
  • Docs are updated, and no public claim now overstates what the code does.
  • I have not introduced a soundness hole (or I have flagged where I might have).

Notes for reviewers

hyperpolymath and others added 5 commits May 28, 2026 14:49
…t for proposed GitHub wiki-API anti-abuse design

While drafting a community/community feature request asking for a REST +
GraphQL surface to create/seed repository wikis (re-file of #196186),
the proposal's "anti-abuse considerations" section names five mechanisms
that should be baked into any new write-API for an agent-collaborative
world. Internal audit confirmed http-capability-gateway already
implements a 1:1 mapping of every one of them in shipping code:

* Per-author rate limits → RateLimiter (token-bucket per {client_ip,
  trust_level})
* Token scope gating → SafeTrust capability lattice (formally verified
  in Idris2)
* Human-attestation header → A2ML tamper-evident JSON envelopes
* Audit metadata surface → VeriSimDB durable append-only trail
* Org-level opt-in → YAML Verb Governance Spec compiled to ETS
* Per-page review queue → K9-SVC SLA + breach policies
* Bonus beyond proposal: mTLS client cert → X.509 OU → capability;
  stealth mode; policy versioning; atom-exhaustion DoS defence

Adds a new "External validation" section to ROADMAP.adoc capturing the
mapping in table form. Explicitly NOT a commitment to externalise the
gateway as a GitHub-API drop-in — MVP scope per the sections above is
unchanged. The note is a reference anchor for two reasons:

1. If a Hubber engages on the discussion thread asking "do you have
   prior art?" — the gateway is the answer, documented in advance.

2. Confidence anchor for the narrow MVP — knowing the design maps
   cleanly onto an externally-recognised problem strengthens the
   argument that the narrow scope is on the right axis.

Snapshot pinned at 2026-05-28; future divergence between the
discussion thread and the gateway scope is documented at the point it
arises, not here.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@hyperpolymath
hyperpolymath merged commit 87c2adb into main Aug 11, 2026
19 of 20 checks passed
@hyperpolymath
hyperpolymath deleted the docs/external-validation-wiki-api-prior-art branch August 11, 2026 23:27
@gitar-bot

gitar-bot Bot commented Aug 11, 2026

Copy link
Copy Markdown

Important

You are using the Gitar free plan. Upgrade to unlock code review, CI analysis, auto-apply, custom automations, and more.

Gitar

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant