KIP — Kippit Improvement Proposals

Protocol framework for peer-to-peer networks. KIP defines the vocabulary and mechanisms that allow any network to describe itself and any node to understand what a network expects.

KIP does not define how data is exchanged, how peers connect, or what security model is used. Those are extensions.

Core

KIP	Name	Status	Description
KIP-0000	Specification Structure and Lifecycle	Draft	Document classes, required sections, status gates, conformance artifacts
KIP-0001	Core Protocol	Draft	Nodes, roles, layers, manifests, extensions
KIP-0002	Manifest	Draft	Manifest format, roles, network map
KIP-0003	Extensions	Draft	Extension identification, spec requirements, registry
KIP-0004	Extension Contracts and Composition	Draft	Capabilities, attachments, requirements, bindings, state, resolver

Document Map

• CONTEXT.md — canonical domain language
• Core and Process KIPs — universal normative model
• Extension Specifications — reusable behavior and Extension Contracts
• Profiles — use-case requirements and constraints: media sharing, encrypted backup
• Design Notes — non-normative architectural exploration
• Composition prototype — executable evidence for KIP-0004, not a normative implementation
• Implementation and conformance roadmap — evidence-backed Draft-to-Review gaps
• Use-case catalog — informative future Profile probes
• Capability Offer schema — Providers available inside one Node
• Provider Contract schema — composition interfaces for transports and Adapters
• Extension Instance schema — configured Manifest occurrence and explicit Bindings
• Participation Class schema — recursive minimum-capability expressions
• Resolved Composition schema — one Node's validated local Provider graph
• Session Agreement schema — shared wire behavior and participant obligations
• Participation fixtures — browser, desktop, and NAS offers exercised as full Nodes
• End-to-end fixtures: media Composition and Agreement; backup client, backup host, upload Agreement, and audit Agreement

Built-in Extensions

Name	Layer	Roles	Status	Description
chunk-exchange	Exchange	peer	Draft	Chunk-based file transfer between peers
kippit-tracker	Discovery	tracker, peer	Draft	WebSocket-based peer discovery and signaling
jwt-auth	Semantics	tracker, peer	Draft	JWT authentication (ES256)
aes-encryption	Semantics	peer	Draft	Data encryption (AES)
client-side-aead	Semantics	peer	Draft	Local authenticated encryption for backup without key export
storage-lease	Semantics	peer	Draft	Bounded ciphertext-retention commitment
possession-audit	Semantics	peer	Draft	Sampled retrieval evidence for retained ciphertext
key-delivery	Semantics	peer, tracker	Draft	Encryption key delivery (API, URL, peer-exchange, manual)
hls-streaming	Semantics	peer	Draft	Sequential priority, HLS manifest
resource-catalog	Discovery	peer, tracker	Draft	Browseable resource listing
resource-metadata	Semantics	peer, tracker	Draft	Per-resource metadata (name, size, type)
sync	Semantics	peer	Draft	Multi-node replication with change tracking
messaging	Semantics	peer	Draft	Real-time small data
bt-bridge	Exchange	peer	Draft	BitTorrent wire protocol compatibility
bt-tracker	Discovery	tracker	Draft	BitTorrent tracker protocol (announce, scrape)
manifest-visibility	Semantics	tracker, peer	Draft	Controls what appears in public manifest
endpoint-discovery	Discovery	peer, tracker	Draft	Endpoint map (sitemap-like)
webrtc-signaling	Connection	tracker, peer	Draft	WebRTC SDP/ICE exchange
mdns-discovery	Discovery	peer	Draft	LAN zero-config discovery

Governance & Operations (future)

Name	Layer	Roles	Description
storage-market	Semantics	peer, tracker	Discovery and commercial terms layered above storage-lease
metered-usage	Semantics	peer, tracker	Bandwidth and storage accounting
quota	Semantics	tracker	Resource limits per peer
reputation	Semantics	tracker	Peer reliability scoring
billing	Semantics	tracker	Payment for hosting/bandwidth
moderation	Semantics	tracker	Content policy enforcement
governance	Semantics	peer, tracker	Democratic/hybrid voting and rule negotiation

External extensions use repository paths (e.g. github.com/someone/cool-extension). See KIP-0003.

Transports

Transport specs define how bytes flow between nodes. Each interface in a manifest declares its transport(s).

Name	Type	Stream	Reliable	NAT	Browser	Spec
TCP	tcp	stream	yes	no	no	transport-tcp.md
UDP	udp	datagram	no	partial	no	transport-udp.md
uTP	utp	stream	yes	partial	no	transport-utp.md
HTTP	http	request-response	yes	yes	yes	transport-http.md
WebSocket	websocket	message	yes	yes	yes	transport-websocket.md
WebRTC	webrtc	message/stream	configurable	yes	yes	transport-webrtc.md
Unix socket	unix	stream	yes	N/A	no	transport-unix.md

Architecture

• protocol-layer-model.md — 5-layer model with roles (design document)
• tracker-manifest-authority.md — federation governance model (design document)

Status

Status	Meaning
Draft	Work in progress, may change fundamentally
Review	Complete, requires review
Accepted	Approved, ready for implementation
Final	Implemented and tested
Deprecated	Still identifiable, not recommended for new use
Superseded	Replaced by another normative document

Contributing

KIP specs are written in Markdown. Each KIP is a self-contained document. To propose a new KIP, open an issue or PR.

Install the schema-test dependency and run conformance examples with:

python3 -m pip install -r requirements-dev.txt
python3 -m unittest discover -s tests -p 'test_*.py' -v

The canonical digest vectors additionally require Node.js to run the minimal RFC 8785 implementation in conformance/canonical-digest.js.

The throwaway composition prototype has its own executable examples under prototypes/composition/.