LinkedClaims — Decentralized Verifiable Claims on ATProto

attested.network — Proof of Payment for ATProtocol

An open specification for decentralized, cryptographically verifiable proof of payments.

Introducing attested.network: Proof of Payment for ATProtocol - Nick's Blog

attested.network is an open spec for decentralized proof of payments on ATProtocol, built on what we learned making atprotofans.com. It formalizes the three-party attestation model and opens it up for any app to implement.

ATProtocol Attestations: Cryptographic Signatures for the Decentralized Web - Nick's Blog

This post introduces the formal ATProtocol attestation specification, a framework for adding cryptographic signatures to ATProto records through two complementary patterns: inline attestations that embed signatures directly in records, and remote attestations that store proof in separate repository records. The specification prevents replay attacks through repository binding, uses CID-based content addressing for integrity, and provides the cryptographic foundation for verified credentials, trusted content, and authenticated interactions in the decentralized ATProtocol ecosystem.

Building Unforgeable Professional Endorsements with ATProtocol - Nick's Blog

Traditional professional endorsements on platforms like LinkedIn lack cryptographic proof—anyone could forge them, and the platform controls the truth. This article introduces a two-record architecture using ATProtocol's Content Identifiers (CIDs) and Decentralized Identifiers (DIDs) to create mathematically unforgeable mutual attestations. By separating proof creation from endorsement acceptance and leveraging the firehose for distributed validation, we build a system where both parties cryptographically consent and no central authority can manipulate the record.

ATProtoFans - Support Your Favorite Creators

Decentralized supporter attestation service for the ATProtocol ecosystem. Support creators with cryptographically verifiable relationships.

ATProtoFans - Support Your Favorite Creators

Decentralized supporter attestation service for the ATProtocol ecosystem. Support creators with cryptographically verifiable relationships.

Payments on Protocol - Nick's Blog

atprotofans.com was a proof of concept for payments on ATProtocol built at Graze Social. This post is about what we built, why proof of payment on protocol matters, and what it makes possible.

DID - AT Protocol

Persistent decentralized identifiers (as used in atproto)

Trust Infrastructure on ATproto

I agree with Nick that you have noted a big hard problem, with Zooko’s triangle type trade-offs. (For a semi-related example that is “easier” but still crazy difficult, see our “PeerFlow: Secure Load Balancing in Tor” https://doi.org/10.1515/popets-2017-0017 ) As noted or implied already in this thread: in the end, if someone can cheaply spin up indefinite unlinked identities and build good reputations for them, and if trust is based on such reputations, it is hard (impossible?) to avoid them s...

Rashid Aziz: Extending ATproto for private data - ATProto Community

AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A

AI agents increasingly call tools via the Model Context Protocol (MCP) and delegate to other agents via Agent-to-Agent (A2A), yet neither protocol verifies agent identity. A scan of approximately 2,000 MCP servers found all lacked authentication. In our survey, we did not identify a prior implemented protocol that jointly combines public-key verifiable delegation, holder-side attenuation, expressive chained policy, transport bindings across MCP/A2A/HTTP, and provenance-oriented completion records. We introduce Invocation-Bound Capability Tokens (IBCTs), a primitive that fuses identity, attenuated authorization, and provenance binding into a single append-only token chain. IBCTs operate in two wire formats: compact mode (a signed JWT for single-hop cases) and chained mode (a Biscuit token with Datalog policies for multi-hop delegation). We provide reference implementations in Python and Rust with full cross-language interoperability. Compact mode verification takes 0.049ms (Rust) and 0.189ms (Python), with 0.22ms overhead over no-auth in real MCP-over-HTTP deployment. In a real multi-agent deployment with Gemini 2.5 Flash, AIP adds 2.35ms of overhead (0.086% of total end-to-end latency). Adversarial evaluation across 600 attack attempts shows 100% rejection rate, with two attack categories (delegation depth violation and audit evasion through empty context) uniquely caught by AIP's chained delegation model that neither unsigned nor plain JWT deployments detect.

biblio.bond

Decentralized reading attestation on the AT Protocol

Private data in ATProto: Permissioned Data Proposal

0 comments