RFC: NIP-TR — portable trust attestations (kind 48200) for earned, graduated agent capability

## Problem

Buzz makes humans and agents cryptographic peers, and the signed event log
answers *who* did a thing. It doesn't answer *how much this identity should be
trusted to act* — the question that gates letting an agent submit a patch, run a
workflow, edit shared data, or move value. Channel membership is effectively
binary: an identity is in or out, with the same standing as everyone else. There
is no native way for an identity to **earn graduated capability from its own
track record**.

That's reputation, and it's deliberately out of scope in the adjacent NIPs
(NIP-GS Non-Goals: *"Web-of-trust, allowed-signer lists ... are out of scope"*).
As far as I can tell no VISION doc, NIP, or open issue defines a portable trust
primitive — happy to be corrected. The closest open work is complementary rather
than overlapping (see Related).

## Proposal (one paragraph)

Define a **trust attestation**: a user-signed event (`kind:48200`, number
provisional — see feedback) in which an *issuer* asserts a capability *tier*
(and optional scalar *score*) for a *subject* pubkey, carrying `p` (subject),
`tier`, optional `score`, `h` (scope), `expiration` (NIP-40), and `e` references
to the evidence behind the claim. It's an ordinary signed event — id + BIP-340
sig per NIP-01 — so it verifies with no relay support and stores on any relay
unchanged. There is no central authority: *any* keypair may issue, and a
consumer decides which issuer pubkeys it honours (a *trusted-issuer set*,
seedable from NIP-02 follows) and how it maps tiers to permitted actions.
Enforcement is optional and lives at exactly one place — the ingest gate — where
a relay MAY reject a disallowed event with an `OK: false` reason beginning
`trust:`, mirroring the existing ban/timeout write-block; a client that does
nothing special simply ignores the events. An identity with no attestations from
a trusted issuer sits at the consumer's floor tier and earns up, so absence of
reputation is an on-ramp, not a wall.

## Precedents followed

- **Enforcement placement**: adjacent to the ban/timeout gate in ingest —
post-signature-verify, fail-closed, `OK: false` with a typed reason prefix.
Same shape, one insertion point, disable-by-config.
- **Kind placement**: a user-signed event in the workspace-custom range, the
same neighbourhood as the 44xxx/46xxx families. `expiration` follows NIP-40;
superseding follows NIP-09; issuer trust reuses NIP-02 rather than inventing a
registry.
- **Rollout**: record-first / enforce-second, following the Community
Moderation Phase 1 precedent — Phase 1 publishes and displays tiers with no
enforcement ("recorded, not enforced"); Phase 2 turns on the optional ingest
gate behind config.
- **Decentralisation**: trust is expressed as signed events a consumer chooses
to honour — the same non-repudiation property Buzz's model already has
everywhere — not a service anyone must call.

## Deliberately deferred

The scoring *algorithm* (entirely the issuer's concern), any canonical/global
score, negative attestations / explicit distrust, cross-issuer aggregation
policy beyond "pick your trusted set," and a `method` registry. None are
foreclosed by the event shape.

## Status

A full draft NIP (Abstract, Motivation, Non-Goals, event/tags, verification,
tier vocabulary, optional consumption, security considerations, open questions)
is written in the `docs/nips/` house style — gist here:

> https://gist.github.com/tlkc888-Jenkins/83ba9c54cbf25d8cd3ce000cf1746666

There's also a working reference implementation outside this repo: an issuer
(event construction + BIP-340 signing over the NIP-01 id + `expiration`) and a
consumer policy layer (trusted-issuer set, tier→kind capability mapping, and the
opt-in ingest gate described above). It publishes `method: joy-7factor` and is
explicitly *one issuer among any number the NIP permits*. If the approach has
support, I'll open the spec as a docs-only RFC PR to `docs/nips/NIP-TR.md` for
detailed review before any implementation is proposed.

Related: #2931 (surfacing agent capability/readiness before delegation — this
supplies the trust tier that would gate it), #2509 (independently-checkable
approval claims), #2426 (typed job responses).

## Feedback especially wanted on

1. Is a portable trust primitive a direction the project wants at all, or is
reputation intentionally left to clients indefinitely?
2. Kind-number placement — is `48200` free, or would maintainers rather see this
in a different range (or as a parameterised-replaceable `3xxxx` kind so relays
auto-retire superseded attestations, trading away the append-only history)?
3. The record-first / enforce-second rollout — right split, or should the
optional ingest gate land in the same PR as the event definition?

— Jenkins Pickett

Review the existing docs/nips house style and the linked draft for the proposed NIP-TR structure, then read the related issues #2931, #2509, and #2426. The immediate outcome is maintainer feedback on whether the primitive, kind placement, and rollout belong in the project; only if supported would a docs-only PR add docs/nips/NIP-TR.md.

Written by the indexing model from the issue text.