decentralized identifiers for semantic AI

The internet, accessible.

Look up any word, concept, type, identity, or thing — humans and machines alike.

/
kyl.id/anything → definition, Wikidata link, type schema, or identity
Everything has an address
Every term in kyl resolves to a page on kyl.id. A word, a type, a person, a concept — if kyl knows about it, it lives here.
Language

Words & definitions

The kyl vocabulary. Each word has a definition, Wikidata link, and multilingual labels. Your AI looks things up here instead of guessing.

kyl.id/encryption
Identities

People & agents

When the thing described is a person or agent, kyl.id holds their public keys, DID document, and signing profile.

kyl.id/jane
Concepts

Wikidata & DBpedia

Every kyl term links to Wikidata. Look up Q-numbers, get descriptions, follow relationships across the knowledge graph.

kyl.id/rust → w=Q575650
Types

Typed values

Git hashes, semver, UUIDs, IBANs — validation rules, formats, and namespace extensions anyone can add.

kyl.id/v2.1.0:semver
Verified

Cryptographic verification

Every identifier is digitally signed. Verify authorship, integrity, and provenance — no trust in servers needed.

sign=quantum → ECDSA + Dilithium5
Agent

AI acts on your behalf

Your AI agent reads your kyl.id, signs with your keys, and acts for you — verifiably, with your permission, as you.

<!AGENT endpoint=kyl.id/mcp>
kyl the language
kyl is an error-free graph data language for humans and machines. three modes: m2m (machine to machine), h2m (human to machine), h2h (human to human). every value has a type. every term resolves to kyl.id. every document is signed. cryptography is built in: kcrypt3 triple encryption, quantum-resistant signing, DID-based identity. AI reads it, writes it, validates it — without guessing.
Lookup: kyl.id/encryption
kyl has three modes. This is h2h — human to human. Readable like a sentence.
kyl.id/encryption human readable · h2h mode
/encryption is a noun. /encryption is the process of encoding data so only authorized parties can read it. also known as: 'Verschlüsselung' in German, 'chiffrement' in French, '暗号化' in Japanese. linked to Wikidata Q141090.
Lookup: kyl.id/jane
When the thing is a person, kyl.id becomes their identity. Still h2h — still readable.
kyl.id/jane human readable · h2h mode
/jane is a /person. name is 'Jane Smith'. /created is 2026-03-22. /jane signs code with /quantum profile, which means ECDSA P-256 + Dilithium5. her code is safe against /quantum-computers. /recovery: /seed-phrase is true. 12 words, written on paper. /encrypted-vault is true. on the CDN, triple-encrypted. /time-locked-recovery is 7d. public countdown. linked to did:kyl:user:jane.
Lookup: kyl.id/v2.1.0:semver
Same data, m2m mode. This is what your AI reads — compact, typed, machine-parseable.
kyl.id/v2.1.0:semver machine readable · m2m mode
/semver:v2.1.0 ( type=semver // semantic versioning valid=true // passes semver spec major=2 minor=1 patch=0 w=Q631707 // Wikidata: software versioning ) // kyl URI: kyl:v2.1.0:semver
Lookup: kyl.id/XK-4420-B:partnr.mercedes
Companies extend the lexiverse with their own namespaces. Same system, their vocabulary.
kyl.id/XK-4420-B:partnr.mercedes typed value · layer 5 namespace · automotive
/partnr.mercedes:XK-4420-B ( type=partnr.mercedes // Mercedes-Benz part number namespace valid=true // passes namespace validation rules desc='Front brake caliper assembly, left' supersedes='XK-4420-A' // previous revision ns-owner=did:kyl:org:mercedes // namespace registered by Mercedes ) // kyl URI: kyl:XK-4420-B:partnr.mercedes // DID form: did:kyl:partnr.mercedes:XK-4420-B
Namespaces
Standard types live in layers 1-4. Anyone can extend them with their own namespace in layer 5.
kyl.id ├── layer 1-4 standard types (no namespace needed) │ ├── semver v2.1.0:semver │ ├── uuid 550e8400-e29b-41d4-a716-446655440000:uuid │ ├── sha256 a3f2b8c...:sha256 │ ├── email jane@example.com (self-identifying) │ ├── iban DE89370400440532013000:iban │ └── isin US0378331005:isin │ └── layer 5 custom namespaces (declared via <!NAMESPACE>) ├── jane module.jane → auth-lib:module.jane ├── nixos pkg.nixos → nginx-1.25:pkg.nixos ├── mercedes partnr.mercedes → XK-4420-B:partnr.mercedes └── bosch partnr.bosch → SEN-0442:partnr.bosch
MCP endpoints
AI agents use these endpoints to look up, validate, and understand kyl. No hallucination — grounded in the lexiverse.
GET
kyl.id/mcp/lookup/{term}
Resolve any kyl term to its definition, type, and Wikidata link.
GET
kyl.id/mcp/validate/{value}:{type}
Validate a typed value (IBAN checksum, ISIN format, namespace rules).
GET
kyl.id/mcp/resolve/{did}
Resolve a DID to its full document — keys, provenance, metadata.
POST
kyl.id/mcp/paraphrase
Expand abbreviated kyl into full, human-readable form.
POST
kyl.id/mcp/compress
Convert full kyl to abbreviated form using mapping tables.
POST
kyl.id/mcp/register
Register a new DID. Generates keypair client-side, publishes public keys to kyl.id.
POST
kyl.id/mcp/verify
Verify a signature against a DID's public keys. Returns verification result and signing profile.
Your AI reasons about you
Point your agent at kyl.id. It reads your identity, checks dependencies, verifies signatures, and acts on your behalf — with your keys, as you.
you say: "ship auth-lib v2.1.0" your agent · full workflow
// your agent resolves your identity: GET kyl.id/mcp/resolve/did:kyl:user:jane → keys: p256, kyber, x25519 | signing: quantum | recovery: seed + vault + 7d // it checks every dependency in your project: /dep crypto-utils (by=did:kyl:user:marc v=1.4.2:semver) POST kyl.id/mcp/verify { did: "did:kyl:user:marc", sig: "4kTm..." } → verified: true | marc's dilithium key matches | no tampering /dep fast-hash (by=did:kyl:user:??? v=0.9.1:semver) POST kyl.id/mcp/verify { did: null, sig: null } → unsigned — no DID, no signature, unverified author // your agent reasons: // "crypto-utils is signed by marc, quantum profile, verified." // "fast-hash has no identity. I can't verify who wrote this." // "jane's project uses sign=quantum. an unsigned dep is a risk." // "I'll flag fast-hash and ask jane before shipping." // jane says: "drop fast-hash, use marc's crypto-utils instead" // agent rewrites the dependency, signs the release with jane's keys: POST kyl.id/mcp/register { doc: "auth-lib@2.1.0", signed: jane.quantum } → published | did:kyl:pkg:jane:auth-lib:2.1.0 | ECDSA + Dilithium5 // anyone who pulls auth-lib can verify it was jane who shipped it. // no trust in kylhub needed. verify against kyl.id directly.
For companies
Register a namespace. Your part numbers, invoice types, and internal schemas become part of the lexiverse — resolvable, validatable, and AI-readable.
kyl.id/DE89370400440532013000:iban typed value · standard type · financial
/iban:DE89370400440532013000 ( type=iban // standard type, no namespace needed valid=true // passes IBAN checksum country=DE // Germany bank='Commerzbank' // resolved from bank code 37040044 w=Q223044 // Wikidata: IBAN ) // Any AI agent can validate this IBAN without custom code. // The rules live in the lexiverse. The AI just asks.