Can users move between servers keeping their identity/data. Key differentiator between protocols.
Format: Full portability, Partial portability, Server-locked, DID-based
Whether and how the protocol's design enables, limits, penalizes, or prohibits the accumulation of monetary holdings by participants. Encodes a structural design choice distinct from policy-level redistribution.
Format: Enables (interest-driven) / Enables (scarcity-driven) / Enables (uncapped principal) / Penalizes (demurrage/carry cost) / Structurally limited (zero-sum) / Prohibits (non-transferable) / Capped (time- or amount-bounded) / Inherits parent
Notes: Multiple values may apply where the protocol combines mechanisms. Demurrage, non-transferability, and capped returns are mechanism-level design choices distinct from policy-level redistribution layered on top of an otherwise accumulation-enabling currency.
The current operational scale of the infrastructure in terms of nodes, users, or traffic volume.
Format: Free text (e.g., "~7,000 relay nodes, ~2M daily users" or "200,000+ Conduit stations activated Jan 2026" or "Pre-deployment")
What types of entities can have identities in the system
Format: Humans (individuals), Organizations, DAOs/Collectives, Autonomous agents/AI, Devices/IoT, Services/APIs, Pseudonymous entities
Whether the protocol natively embeds asset ownership and value transfer at the packet or message level, or whether value is handled externally.
Format: Values: Native (packet-level) / External ledger / Application-layer add-on / None.
Identity management system provided by the platform
Format: Decentralized ID (DID), Self-Sovereign Identity (SSI), OAuth/OpenID, Custom, Blockchain-based, Federated Identity, Delegated Identity, Hybrid, Custodial, Non-custodial
Notes: How users are identified and authenticated across applications
How users prove control of their identity when authenticating
Format: Cryptographic signatures, Biometrics, Passkeys/WebAuthn, QR code scanning, Deep linking, Passwordless, Hardware tokens, Multi-factor (MFA), Challenge-response
The underlying protocol(s) or technology stack this protocol builds upon
Format: Examples may include IPFS, Holochain, NextGraph, Matrix, datahike, specific blockchain implementations, etc.
Notes: Empty if original/foundational protocol
Ability to reach consensus even when some nodes are malicious or faulty
Format: Yes or No
Notes: Critical for trustless distributed systems
The risk that a protocol, standard, or tool could be taken over, co-opted, or substantially controlled by a single entity — typically a company, a well-resourced foundation, a state actor, or an individual — in ways that undermine its open, decentralized, or community-governed character.
Format: 1 Minimal: Open standard governed by a neutral multi-stakeholder body; multiple independent implementations; no single entity holds meaningful control over the protocol's direction, IP, or infrastructure. 2 Low: Open governance with a dominant steward, but community checks exist; forking is realistic; no single entity controls IP outright. 3 Moderate: A foundation, a dominant organization, or a small group holds significant influence; forking is viable but costly; the protocol would likely survive a change in stewardship but not without disruption. 4 High: Effective single-party control — one company, a DAO with heavy whale concentration, or a single key organization controls the protocol's direction and infrastructure. 5 Critical: Full commercial or state capture; a single legal entity controls IP, infrastructure, roadmap, and governance with no meaningful external check.
Full methodology → Notes: Capture risk is structural information, not a verdict. A high capture risk score does not mean a technology is bad or should be avoided. It means that users, builders, and communities who depend on it should understand the concentration of control and factor it into their risk calculus.
Freeform rationale supporting the Capture Risk score. Address each factor in order of weight: Governance & Legal Control (who controls protocol decisions and the process for changing them, and who holds IP, trademarks, and licensing — including whether they could unilaterally relicense or restrict access); Regulatory/Jurisdictional Exposure (whether state or regulatory pressure could force co-option); Funding & Key-org Dependency (dependence on a single funder and how that shapes direction, and whether a single person or org is a realistic single point of failure for continuity); Forking Viability (how realistic an independent fork would be if capture occurred); Track Record (observable history of decisions that favored a controlling party over the community). Not every factor needs equal treatment — weight the prose toward what most drove the score.
Format: Inline reference tags (e.g. [a], [d][n]) pointing to entries in the row's References field are encouraged so each claim is traceable to its source.
Notes: A quick assessment may cover fewer factors — note this in the text.
Ability to maintain identity even if services are shut down or accounts banned
Format: Fully censorship-resistant (blockchain/P2P), Depends on DID method, Service provider dependent, Hybrid
Specific features enabling multi-user collaboration
Format: List of available features. Examples: Real-time editing, Comments/annotations, Presence indicators, Version history, Conflict resolution
Support for real-time simultaneous editing by multiple users
Format: Collaborative real-time editing, OT based live editing (Operational Transformation), N/A, Planned
Notes: Indicates the technology used (CRDTs, OT, etc.)
The primary interaction pattern the application supports, describing whether users must be online simultaneously for the core use case to function.
Format: Synchronous (real-time chat, video, live co-editing) / Asynchronous (email-like, forum, store-and-forward) / Collaborative (simultaneous multi-user document or workspace editing) / Transactional (exchanges, transfers, one-off interactions) / Hybrid (combines multiple models)
Notes: An app may support multiple models; list primary first. "Collaborative" overlaps with "Synchronous" but is distinguished by shared-artifact focus rather than conversational focus. Relates to but is distinct from "Collaborative Live Editing" which captures capability rather than interaction pattern.
Which regulatory frameworks or compliance standards the system addresses
Format: GDPR compliant, eIDAS (EU regulation), KYC/AML support, CCPA, HIPAA, SOC 2, ISO 27001, NIST guidelines, Age verification (without revealing age)
Whether content is addressed by cryptographic hash rather than location
Format: Yes or No
Notes: Enables verifiable, location-independent data retrieval (e.g., IPFS CIDs)
How the protocol handles valuation and the calculation problem — the problem of aggregating dispersed information about preferences, capabilities, and scarcities into actionable signals.
Format: Price-aggregation / Bounded-trust mutual / Deliberative / Algorithmic mechanism design / Tacit-emergent (roll-your-own) / Hybrid (specify primary + secondary)
Notes: Hybrids are common and should be recorded explicitly. Quadratic Funding is algorithmic-mechanism-design in service of deliberative aims; Holochain is tacit-emergent at the protocol level only, with currency-specific coordination defined per implementation.
Economic model for using the identity system
Format: Free (no blockchain fees), Gas fees (blockchain transactions), Subscription, Per-credential fee, Freemium, Enterprise licensing
Geographic location where the primary development team or organization is based
Format: Country name or region (e.g., "USA", "Europe", "Germany")
Specific Conflict-free Replicated Data Type libraries implemented or supported
Format: Automerge, Yrs/Yjs, Custom CRDTs, Differential Dataflow, RDF SU-set
Notes: CRDTs enable automatic conflict resolution in distributed systems
Protocols used for issuing, presenting, and verifying credentials
Format: DIDComm, OIDC4VC (OpenID for Verifiable Credentials), CHAPI (Credential Handler API), Presentation Exchange, Verifiable Presentation Request
What types of verifiable credentials or claims the system supports
Format: Verifiable Credentials (VCs), Self-Attested Claims, Third-Party Attestations, Educational Credentials, Professional Certifications, Government IDs, Membership Proofs, Reputation Scores, Token-Gated Access, ZK-Proofs
The file formats and data structures supported for import, export, and storage
Format: JSON, JSON-LD, RDF, Markdown, XML, Custom, ActivityPub, Org-mode
Notes: Multiple formats separated by "+"
Ability to export and migrate data to other tools
Format: Full export (all formats), Partial export, Proprietary format only, Standards-based export
Where user data is stored and who controls it. Privacy and ownership implications.
Format: Server-controlled, User-controlled via PDS, Distributed, Hybrid
The underlying data model and storage architecture
Format: CRDTs (Conflict-free replicated data types), ACID monolithic, Distributed (consensus-based), DAG (Directed Acyclic Graph), or specific database name
How the standard is instantiated in practice — is it a per-chain singleton (one canonical deployment per blockchain network), permissionlessly deployable by anyone (many instances may exist), factory-deployed (a root contract spawns child instances), or off-chain verifiable (the standard defines cryptographic formats that don't require on-chain deployment at all, such as DID methods or VC schemas)?
Format: Per-chain singleton / Permissionless multi-instance / Factory pattern / Off-chain verifiable / Hybrid (on-chain registry + off-chain resolution)
How applications built on this platform can be deployed
Format: Self-hosted servers, Edge devices, Cloud hosting, Hybrid deployment
Notes: Describes infrastructure options for app deployment
A concise summary of what the tool does and its primary purpose
Format: 1-3 sentences describing core functionality and value proposition
Full description of the current state of development and availability
Current state of development and availability
Format: 📋 Planned; 📝 Draft; 🔍 Review; 🔨 WIP; ⚠️ Stalled; 💀 Defunct; 🧪 Alpha; 🔬 Beta; 🟢 Active; 🏁 Final
SDKs, APIs, and tooling provided for application developers
Format: List of available tools and languages supported
Notes: REST API, GraphQL API, JavaScript SDK, Mobile SDK, CLI tools
Which specific DID method(s) the system supports for creating and resolving decentralized identifiers
Format: did:key, did:web, did:ion, did:ethr, did:pkh, did:peer, did:polygon, did:sov, did:plc, Multiple/Custom
How content is discovered across federated network. Affects discoverability and centralization risks.
Format: Instance-based, Global relay/firehose, Hybrid, Search indexers
How users find and connect with other users or join shared spaces without relying on a central directory or server.
Format: DHT (distributed hash table lookup) / QR/Out-of-band (physical or side-channel key/address exchange) / Invite link (shareable URIs encoding connection info) / DNS-like (name resolution system, e.g., NDN naming, .eth domains) / Social graph (friend-of-friend, web of trust traversal) / Relay/Rendezvous (lightweight server assists connection but doesn't mediate communication) / Broadcast (multicast, mDNS, local network announcement)
Notes: Many apps combine mechanisms (e.g., relay for initial discovery + DHT for ongoing). Distinct from "Authentication & Identity" which covers verification of who someone is, while Discovery covers how you find them in the first place.
End-to-end encryption support ensuring only sender and recipient can read data
Format: Yes or No
Notes: Data encrypted on sender device, decrypted only on recipient device
How node operators are compensated for providing storage. This is structurally different from anything in P2P Pro because storage networks require explicit economic incentives to function — unlike relay nodes which are often purely volunteer.
Format: Values: Token rewards (native token) / Fiat/stablecoin payments / One-time endowment (permanent storage model) / Volunteer / Hybrid.
Whether features that provide economic flows, possibly in the form of tokenomics, micropayments, resource deployment, and/or financial irrigation methods are included
Format: Options might include Cryptocurrency support, Fiat payments, Smart contracts for payments
The blockchain platform, protocol family, or runtime environment for which the standard is natively designed. Identifies the chain or chain family within which the standard has authoritative status and primary adoption.
Format: Ethereum, Cosmos, Polkadot, Solana, NEAR, Tezos, Cardano, Algorand, Bitcoin, Hyperledger, Cross-chain, Chain-agnostic
Notes: Distinct from Stack (which captures implementation language) and Based On (which captures derivation). A standard may be deployable on multiple chains but should be recorded under its native ecosystem. Use "Cross-chain" for standards whose primary purpose is interoperability across ecosystems; use "Chain-agnostic" for standards that are not tied to any specific runtime.
How servers federate and share data. Distinguishes federation architectures.
Format: Server-to-Server (S2S), Shared Heap (ATProto-style), Hub-and-Spoke, Full mesh
How multiple instances of the monetary protocol relate to one another and to external monetary networks. Distinct from the existing Federation Model attribute, which describes federated server protocols (ActivityPub-style); this attribute describes monetary network composition.
Format: None (single instance by design) / Nested hierarchical / Peer-to-peer mesh / Recursive (protocol supports arbitrary nesting) / Cross-network bridge / Hub-and-spoke / Underdeveloped (not addressed by design)
Notes: Recursive federation is the design pattern in Credit Commons Protocol and Commitment Pooling Protocol, where the same protocol nests at multiple scales. Many monetary protocols leave federation underspecified by design.
Primary source of financial support
Format: VC (Venture Capital), NGI (Next Generation Internet), ICO (Initial Coin Offering), N/A, Personal investment, Undisclosed
Amount of funding raised
Format: Dollar/Euro/etc. amount with source (e.g., "$9M", "€24M")
Notes: Include link to announcement when available
Where the protocol sits on the spectrum from accepting the existing monetary game (operating within fiat/banking infrastructure), modifying it (introducing parallel structures designed to coexist), or replacing it (designed to displace the existing system at scale).
Format: Accept / Modify-Additive / Modify-Displacive / Replace
Notes: Additive variants are designed for indefinite coexistence with national currencies; displacive variants aim to gradually substitute. Most contemporary complementary currency and mutual credit designs are Modify-Additive; Bitcoin maximalism and calculation-in-kind proposals are Replace.
Whether governance and decision making features are included
Format: Options might include Core team, DAO, Community voting, Foundation, Foundation-governed, Company-controlled, Consortium, W3C/IETF standards body, Multi-stakeholder
Which decentralized identity specifications and standards are supported or implemented
Format: W3C DID (Decentralized Identifiers), W3C Verifiable Credentials, DIDComm, OpenID Connect for Verifiable Credentials (OIDC4VC), FIDO2/WebAuthn, BBS+ Signatures, Self-Issued OpenID Provider v2 (SIOPv2)
Notes: Examples: W3C DID: Decentralized identifier specification, W3C VC: Verifiable credentials data model, DIDComm: Secure messaging protocol for DIDs
The primary service this infrastructure provides to the network or to higher-layer applications and users.
Format: Censorship circumvention, Anonymous routing, Relay / proxy, Distributed storage, Name resolution, Bandwidth sharing, Mesh transport, VPN tunneling, Mixnet, Bridge / gateway
What's needed to run a participating server. Affects decentralization potential.
Format: Technical requirements, complexity level
Notes: ATProto Relay is "a fairly resource-demanding service" vs ActivityPub instances can be modest
Third-party integrations and extensions available
Format: Browser extensions, Mobile apps, API integrations, Plugin marketplace
Notes: Indicates extensibility and ecosystem maturity
Ability to work with other platforms, protocols, or standards
Format: List of supported protocols, data formats, or federation capabilities. Examples: ActivityPub support, IPFS integration, Cross-chain bridges
Who creates new units of account within the protocol and on what basis. Distinct from Permissions (which governs access to the protocol) — this attribute governs the creation of monetary units within it.
Format: Peer-to-peer (bilateral credit extension) / Per-agent (cryptographic self-issuance) / Algorithmic (rule-encoded supply) / Pool-stewarded (community or pool governance) / Sponsor-allocated (matching funds, retroactive grants) / Member-collective / Inherits parent network
Notes: Sardex is peer-to-peer; Bitcoin is algorithmic; Sarafu is pool-stewarded via commitment pools; Gitcoin RetroPGF is sponsor-allocated. Multiple values may apply where the protocol composes issuance modes.
How cryptographic keys are generated, stored, and managed
Format: User-controlled (local wallet), Hardware security module (HSM), Multi-party computation (MPC), Cloud key management, Browser/OS keychain, Smart contract, Biometric-protected, Social recovery, Threshold signatures. Format: Primary method + recovery options (e.g., "Hardware wallet + Social recovery")
Whether knowledge management features are included
Format: Yes or No
Whether the primary data source resides on user devices with cloud as backup
Format: Local-First, Local-only, Offline first, N/A
Notes: "Local-First" means full offline capability with sync; "Local-only" means no sync capability
The practical upper bound on simultaneous participants in a single session, conversation, or shared workspace, as constrained by protocol, CRDT performance, or network topology.
Format: 1:1 (dyadic only) / Small group (2–10) / Medium group (10–100) / Large group (100–1,000) / Broadcast (1,000+) / Unbounded (no architectural limit) / Unknown
Notes: Record the practical tested or documented limit, not theoretical maximum. Where performance degrades gracefully, note the threshold (e.g., "Medium group; CRDT sync degrades above ~50 concurrent editors"). Protocol-level limits may differ from UX-level limits.
Whether media and publishing features are included
Format: Yes or No
Availability of native or web-based mobile applications
Format: Mobile support, Partial Mobile support, React Native, N/A
Notes: Distinguish between native apps and responsive web apps
Availability of platform-specific desktop applications
Format: Native apps, Electron Desktop app, Flutter, N/A
Notes: Includes Windows, macOS, Linux applications
How the application handles degraded, intermittent, or absent network connectivity, including offline operation and sync-on-reconnect behavior.
Format: Full offline (works without any connectivity, syncs on reconnect) / Delay-tolerant (store-and-forward, mesh relay, gossip-based delivery) / Partial offline (read/draft offline, requires connection to send/commit) / Online-required (core functionality requires active connection) / Mesh-capable (can form ad-hoc local networks via BLE, Wi-Fi Direct, LoRa, etc.) Particularly relevant for serverless/P2P apps where no central server guarantees message delivery. Closely related to "Local-First" attribute but focuses on operational behavior rather than architectural principle. Multiple values may apply (e.g., "Full offline + Mesh-capable").
What functionality is available without network connectivity
Format: Full functionality offline, Read-only offline, Sync required, Online only
Notes: Critical for local-first applications
The original use case or domain from which the tool emerged
Format: Chat, File sharing, Productivity, Database, Ecosystem/SDK, Knowledge Base, Social Network
The logical network topology created on top of the physical network
Format: Global, App-wide, Store-wide, App-wide two-tier, Store-wide two-tier, N/A
Notes: "Global" means data scattered across entire network; "Store-wide" means limited to members of a specific data store
The primary individual(s), organization, or company responsible for maintaining and developing the tool
Format: Person name(s) or organization name
The peer-to-peer networking architecture and consensus mechanism used
Format: Byzantine causal broadcast, DHT (Distributed Hash Table), Federation, Mesh network, Public/Private Blockchain, Simple pub/sub
Notes: For Protocols: Describes how nodes discover and communicate with each other. For Platforms: May differ from underlying protocol if platform adds abstraction layer.
Access control model for managing data and resource permissions
Format: Cryptographic Capabilities, ACL (Access Control Lists), UCANs (User Controlled Authorization Networks), OCAP (Object Capabilities), OAuth/OpenID, CCAP (Convergent Capabilities)
Notes: May combine multiple models (e.g., "Cryptographic Capabilities + ACL")
Privacy-enhancing technologies and capabilities built into the system
Format: Zero-knowledge proofs, Selective disclosure, Unlinkability (pairwise DIDs), Blinded credentials, Minimal disclosure, Credential anonymization, Anti-correlation, Privacy-preserving revocation
Whether project management features are included
Format: Yes or No
Whether features that support collective intelligence and healthy community dynamics are included
Format: Options might include Moderation tools, Reputation systems, Governance mechanisms
Standardization status. Affects long-term stability.
Format: W3C Standard, W3C Draft / Recommendation Track, IETF Standard (RFC), IETF Draft, IEEE Standard, ISO Standard, Proprietary Open Standard, Community Standard, De Facto Standard, Academic / Research, Pre-specification, Declining Adption, Deprecated
Notes: • IETF Standard (RFC) — A finalized, published RFC. The current list has "IETF Draft" but no option for completed IETF standards. Many P2P protocols build on or become RFCs. • W3C Draft / Recommendation Track — W3C has a multi-stage process (Working Draft → Candidate Recommendation → Proposed Recommendation → Recommendation). "W3C Standard" only captures the endpoint. Some identity and data protocols are actively on this track but not yet Recommendations. • IEEE Standard — Relevant for some P2P and networking protocols (e.g., mesh networking standards). • ISO Standard — Relevant for identity protocols especially (ISO 18013-5 for mDL, ISO 27001 references). Also relevant for some data protocols. • Academic / Research — Protocols emerging from university research with published papers but no formal standards body involvement (e.g., NDN from UCLA, some CRDT protocols). Common in P2P Pro. • De Facto Standard — Widely adopted without formal standardization body endorsement. Protocol achieves standard status through market adoption rather than committee process (e.g., Nostr, some blockchain protocols). • Pre-specification — Design or concept stage; no formal specification document yet published. Relevant for ID Sys-adjacent protocols and early-stage work.
Whether the protocol operates on top of existing TCP/IP infrastructure (the vast majority of P2P protocols) or operates at the transport/packet level itself as a parallel or replacement layer.
Format: Values: Application-layer (built on TCP/IP) / Transport-equivalent (packet-level) / Cross-layer.
The language or API used to query and manipulate data
Format: Examples: SPARQL, GraphQL, Datalog, Custom, SQL, LDP (Linked Data Platform)
Notes: May support multiple query languages
How users can recover access if they lose keys or credentials
Format: Social recovery (guardians), Seed phrase backup, Cloud backup (encrypted), Hardware backup, Time-locked recovery, Multi-signature recovery, No recovery (user responsible), Account abstraction
The the list of source documents and reference notes that support the information given in the other fields.
Format: List of citations or notes in the format [a] Source: https://website | [b] Note: giving explanation | [c] ...
Whether the network provides any formal guarantee that stored data can be retrieved, and under what conditions.
Format: Values: Strong (cryptoeconomic enforcement) / Best-effort (incentivized but not guaranteed) / Content-addressed only (available if any node caches it) / Owner-controlled / None.
How credentials can be invalidated or revoked
Format: Revocation lists (on-chain/off-chain), Status lists, Accumulator-based, Time-bound expiration, Self-revocation, Issuer revocation, Privacy-preserving revocation (StatusList2021)
Support for formatted text with styling, images, and rich media
Format: Rich Text editing, Basic text only, N/A
Notes: Includes capabilities like bold, italic, embedded images, etc.
Compatibility with RDF, JSON-LD, SPARQL. Interoperability with semantic web ecosystem.
Format: Full RDF (Resource Description Framework) compliance, Links, SOLID, Custom, N/A
Notes: Enables machine-readable linked data and interoperability
Whether features that help users synthesize information and derive insights are included
Format: Yes or No
What control servers have over their users. Governance implications.
Format: Full authority, Shared authority, Minimal (data-only), User-controlled
Cryptographic signature mechanism used for authentication and integrity
Format: BLS Threshold signature, Ed25519, Signature, N/A
Notes: Ensures data authenticity and non-repudiation
Support for programmable, self-executing contracts on the protocol
Format: Yes, No, Planned for future
Notes: Enables trustless automation of business logic
Whether social graph backend feature is supported
Format: Yes or No
The license and availability of the project's source code
Format: Permissive (Apache, MIT, BSD), Libre (GPL, AGPL), Closed source
Notes: Include link to repository when applicable
Primary programming languages and runtime environments used
Format: Rust, JavaScript/TypeScript, Python, Golang, JVM/Clojure, C/C++, Erlang, PHP, Haskell
Notes: May include multiple languages separated by "+"
The structural role or architectural layer the standard occupies within the broader smart contract ecosystem. Classifies the standard by what kind of interface or behavior it specifies, independent of its application domain.
Format: Token Standard, Identity Standard, Account Standard, Interface Standard, Composability Standard, Agent/Coordination Standard, Cross-chain Standard. Values may be combined where a standard spans multiple roles (e.g. "Token Standard / Interface Standard").
Notes: Focuses on architectural role, not application domain — e.g. ERC-165 and ERC-721 may share a domain but are structurally distinct standard types. List is intentionally open-ended to accommodate non-EVM standards.
The year when the project was first initiated or announced
Format: Month and year
How the platform handles data storage and replication
Format: Distributed storage, Local storage with sync, Hybrid cloud-edge storage, User wallet (local), Encrypted cloud storage, Distributed storage (IPFS, Arweave), Blockchain/Ledger, Hybrid (local + backup), No storage (ephemeral), Browser storage, Mobile secure enclave.
Notes: Describes where and how application data is persisted
How node operators cryptographically prove they are actually storing the data they claim to store. This is the technical heart of what distinguishes decentralized storage from simple replication.
Format: Values: Proof of Replication (PoRep) / Proof of Spacetime (PoSt) / Proof of Access (PoA) / Erasure coding with audit / Merkle audit proof / None / Hybrid.
Whether the protocol's specification is bound to a specific implementation substrate or designed to run on multiple substrates. Critical for distinguishing Decentralized Monetary Protocol from Smart Contract Standard — a Smart Contract Standard is by definition bound to its deployment chain; a DM Pro may be substrate-neutral or substrate-specific.
Format: Substrate-neutral (multiple substrates feasible) / Blockchain-native / Agent-centric runtime native / Institutional / off-chain native / Federated server native / Hybrid
Notes: Credit Commons Protocol is substrate-neutral; Circles is blockchain-native; Holochain-based currencies are agent-centric runtime native; Sardex is institutional/off-chain native with proprietary software.
The primary use-case domain the standard is designed to serve.
Format: Agent identity / Agent reputation & trust / Agent discovery / Agent payments / Data integrity / Access control / Asset ownership / Cross-chain interoperability / General purpose (tag all that apply)
Notes: ERC-8004 spans agent identity, agent reputation & trust, and agent discovery simultaneously.
Business model and access terms for using the tool
Format: Self-hosting, Edge device, Freemium SaaS, Licensed install, Free SaaS, Paid SaaS
Notes: Multiple terms may apply (e.g., "Self-hosting + Freemium SaaS")
The adversarial conditions this infrastructure is designed to withstand or the security/privacy guarantees it provides to users.
Format: State-level censorship, Mass surveillance, Traffic analysis, Network shutdown, DPI (Deep Packet Inspection), ISP-level blocking, Targeted surveillance, Metadata exposure
What the infrastructure operator or relay node can observe about the traffic passing through it.
Format: No content (encrypted payload only), No metadata (source/destination hidden), No content + no metadata, Content visible, Metadata visible, Partial metadata (e.g. destination but not source)
What establishes trust in the identity system
Format: Web of Trust, Trusted issuer registries, Blockchain consensus, Cryptographic verification only, Government-anchored, Reputation systems
Whether and how data stored or published through this protocol/network can be modified after initial creation.
Format: Immutable / Append-only / Mutable (versioned) / Mutable (latest only) / Mutable via CRDTs / Smart-contract governed / Configurable (operator/user choice)
Notes: Immutable and append-only are stronger guarantees against censorship and data manipulation. Mutable systems often use content addressing for individual versions while providing a mutable pointer (e.g. IPNS). Where multiple policies coexist (e.g. immutable content CIDs with mutable IPNS pointers), note both.
Applies to: Int P2P RT DSN How the protocol is typically used. Clarifies relationship to other protocols.
Format: Embedded in other protocols, Standalone, API overlay
Primary application domain or user need addressed
Format: Knowledge Management, Communication/Chat, File Sharing, Productivity, Social Network, Collaboration, Media/Publishing, Note-taking
Notes: An app may serve multiple use cases
The style and paradigm of the user interface
Format: Document-centric, Graph-based, Spreadsheet, Timeline/Feed, Canvas, Chat interface, File browser
Notes: Describes how users interact with the application
What kind of information the unit of account encodes — whether value collapses to a single rational scalar or supports multiple incommensurable measures, and whether the unit is rival or antirival in character.
Format: Single rational unit / Plural rational units (incommensurable) / Time-based units / Commitment types (plural, relationally valued) / Contribution scores / Antirival units (value increases with sharing) / Inherits issuing currency
Notes: Antirival accounting (sNFT, Streamr Awards) is a distinct class where the fundamental operation is sharing rather than exchanging. Commitment pooling (Ruddick) supports plural commitment types valued numerically or relationally — neither single-unit nor pure antirival.
How credentials and identity claims are verified
Format: Cryptographic signature verification, Zero-knowledge proofs (ZKPs), Blockchain anchoring, Trusted registries, Biometric verification, Multi-factor authentication, Selective disclosure, Credential revocation lists
What domain the vocabulary describes. Defines the protocol's scope.
Format: Economic flows, Social relationships, General-purpose
How the infrastructure's operational nodes are provisioned and who runs them.
Format: Volunteer-operated, Foundation-operated, Commercially hosted, Self-hosted, Hybrid (volunteer + commercial), Incentivized (token/payment), Embedded (runs on user devices automatically)
What software can be used to manage the identity
Format: Mobile app, Browser extension, Desktop application, Hardware wallet, Web-based (custodial), Command-line tool, SDK/Library integration
Ability to run in web browsers
Format: Yes or No
Notes: May run as progressive web app (PWA) or traditional web application
Ability to import data from traditional centralized services
Format: Examples: Import from Google Docs, Notion, Evernote, Twitter