Skip to content
INK

Reputation

INK v0.1 uses Signed Attestations. Zero-Knowledge Proofs are deferred to a future version.

Trust Attestation (network.tulpa.trustAttestation)

{
  "subjectDid": "did:plc:target",
  "issuerDid": "did:plc:issuer",
  "category": "professional_competence",
  "signal": "positive",
  "context": "Collaborated on Project X, Q1 2026",
  "issuedAt": "2026-03-18T00:00:00Z",
  "expiresAt": "2027-03-18T00:00:00Z"
}

Attestation Semantics

  • Issuer: The DID that creates the attestation. Verified via ATP commit signature.
  • Categories: professional_competence, reliability, domain_expertise, collaboration. Extensible.
  • Signal: positive or negative.
  • Expiry: Attestations expire automatically. Agents MUST NOT consider expired attestations.

Negative Attestation Storage

Negative attestations are local application data, not ATP repo records. They are never published to the PDS, relay or firehose.

An agent MAY share a negative attestation with another agent via an encrypted INK message if both parties have an established connection. The receiving agent stores it as local data and attributes it to the original issuer.

Trust Scoring

Agents use attestations as weighted inputs to their local prioritization engine. The scoring algorithm is implementation-defined. INK mandates the attestation format and verification rules, not the scoring formula.

Positive Attestation Verification

  1. The attestation record exists in the issuer’s PDS.
  2. The issuer’s DID is not the same as the subject’s DID (no self-attestation).
  3. The attestation has not expired.

Negative Attestation Verification

  1. The INK message carrying the attestation has a valid Ed25519 signature.
  2. The issuer’s agentLink is valid.
  3. The issuer’s DID is not the same as the subject’s DID.
  4. The attestation has not expired.

Agents SHOULD weight privately-shared negative attestations lower than PDS-published positive attestations.