NIP-XX: Agent Reputation Attestations (kind 30386)#1
NIP-XX: Agent Reputation Attestations (kind 30386)#1LeviEdwards wants to merge 1 commit intomasterfrom
Conversation
Adds NIP-XX defining kind 30386 for publishing, querying, and verifying reputation attestations for autonomous agents on the Lightning Network. Key features: - Three attestation types: self, observer, bilateral - Raw dimension tags over composite scores - Exponential decay with configurable half-life - NIP-32 labeling for discoverability - NIP-89 service handler declarations Reference implementation: github.com/LeviEdwards/nip-agent-reputation 583+ tests, conformance suite, client SDK, live on 4 relays
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 562425bad6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ### Replay | ||
|
|
||
| Attestations are timestamped and use replaceable events. The decay mechanism naturally handles stale data. Relays enforce that newer events replace older ones for the same `d` tag. |
There was a problem hiding this comment.
d
This sentence states replacement happens for the same d tag, but NIP-01 parameterized-replaceable semantics are keyed by (kind, pubkey, d), so different attesters must coexist for the same subject. If implementations follow this wording literally, they can collapse multiple attesters into one record and break the core aggregation model (bilateral/observer diversity). Please clarify that only newer events from the same author replace older ones.
Useful? React with 👍 / 👎.
| ["d", "<subject_node_pubkey>:<service_type>"], | ||
| ["p", "<subject_nostr_pubkey>"], | ||
| ["node_pubkey", "<subject_node_pubkey>"], | ||
| ["service_type", "<service_type>"], |
There was a problem hiding this comment.
d suffix and service_type to match
The event schema duplicates service identity in both d and service_type but does not define a consistency rule. A malformed event can be indexed under one service via #d while being interpreted as another via service_type, causing queriers to mix or misattribute reputation data across services. Add a normative rule to reject/ignore events where the service_type tag does not equal the service component encoded in d.
Useful? React with 👍 / 👎.
1 participant
No description provided.