KTAPEOUTThird-party Websites, Clients and Application Access
Build your own entry into the KTAPEOUT ecosystem: an application website, read-only explorer, developer tool or compatible client. Your domain can present the same network-scoped application identity as another gateway. The project-maintained website is not required to own that identity.
This guide is explanatory. The 0.5.0 specification remains authoritative; ktape:// is the application URI scheme, not a separate consensus protocol or a website hosting service.
Understand the address
An application identity, display name, canonical URI and release are separate values. The canonical URI has the form:
ktape://<network>/app/<namespace>/<slug>@<release_id>Use the name toolchain to normalize and validate the URI. It rejects ambiguous case, percent encoding, fragments, queries and unsupported networks. An alias lookup is useful for discovery, but only a verified, network-scoped record can establish the current application binding.
Name resolution is read-only unless an explicitly authorized external adapter performs the publication flow. A browser endpoint, indexer result or local preview is not by itself Registry or L1 evidence.
Keep the Registry identity tuple explicit in application records: application_id, resource_id, release_id, artifact_id, profile_hash, covenant_id and instance_outpoint have different meanings. Do not derive one from another unless the selected Profile contract says so. The Compact Registry deed and the full deed are separate Profile families; clients MUST reject a family mismatch instead of applying a compatibility cast.
The public Testnet-10 Registry identity inputs are listed in the release-evidence/tn10/ directory. Verify the manifest and Bridge trust anchor before using a name as a trusted development reference, and obtain the required fresh readback for any publication claim.
Build your own website or gateway
You can host your own frontend and choose your own HTTPS route. For example:
Canonical identity: ktape://testnet-10/app/acme/notebook
Your HTTPS route: https://gateway.example/app/testnet-10/acme/notebookThese are illustrative addresses, not registered applications. The HTTPS route is your service's convention, not a protocol requirement. A web browser can open HTTPS directly; opening ktape:// requires a compatible handler.
An interoperable entry should follow this flow:
- Parse and validate the URI with the documented naming rules. Keep the network and optional release ID explicit.
- Resolve the binding through your chosen read-only source and verify the identity against the applicable Registry manifest and trust anchor. For TN10, start with the public identity evidence linked above.
- Preserve the distinct identity fields and verify the selected release's content commitments. Pin an explicit release when reproducibility matters; an unpinned address follows the current verified binding.
- Retrieve content through an explicitly supported storage arrangement. A name binding does not ensure that content remains available.
- Render only what your client supports. Validate Runtime compatibility before loading executable content; apply isolation and user-consent controls.
- Display the network, release and evidence scope. Keep read-only inspection, local execution and network-confirmed publication distinguishable.
Start with read-only discovery and inspection. The minimal public package provides Rust Core/Verifier/CLI sources and public contracts; it does not bundle a generic web resolver, browser URI handler, Browser SDK, Studio or provider implementation. Dynamic resolution, Runtime loading and writes require additional implementations and their own validation. Network writes also require the supported Profile/adapter path, an external signer and fresh readback described in TN10 publication.
Choose how to participate
| Contribution | Useful first deliverable | Contract to preserve |
|---|---|---|
| Website or gateway | A read-only application directory with canonical URI links | Network-scoped identity, release binding and evidence labels |
| Explorer or indexer | Searchable public Registry records and release inspection | Provenance and readback scope; an index is not authoritative evidence |
| Independent client | A schema reader, artifact inspector or CLI integration | Canonical encoding, hashes, error rules and public schemas |
| Reusable Profile, Package or Recipe | A bounded component with exact dependencies and compatibility documentation | Profile semantics, resource bounds and locked digests; publication admission is separate |
| Runtime or adapter integration | A documented capability boundary and compatibility report | Explicit provider assumptions and Profile-specific admission |
| AI developer tooling | Project instructions or editor integration using the public AI Skill | The same contracts and authority limits as human development |
| Protocol and tooling contributions | A reproducible defect report or focused improvement | The normative specification and contribution standards |
Third-party applications and services belong in their own repositories. The protocol repository publishes shared contracts and tools, rather than hosting application implementations. Describe your compatibility and supported capabilities explicitly; do not imply official endorsement.
Start with the existing public material
- Naming reference: canonical IDs and URI rules.
- Client-neutral contracts: equivalent clients and provider boundaries.
- Schemas and errors: validation inputs.
- Profile authoring and composition and locks: reusable components.
- AI Skill and setup: AI-assisted development.
- Capabilities and status: what the current candidate actually includes.
- Contribution guidance and MIT License: collaboration and reuse terms.