Declared-combination qualification and ordinary-user friction are the immediate cross-component work. Streaming, privacy, reachability, browser use, external evidence and federation retain their own acceptance gates.
◐Reliability
Qualify every declared platform combination
HardeningThe live reliability baseline has passed its bounded observation gate. The broader finish line now tests each supported client, Directory and local Management combination, including failures and recovery, instead of inferring support from a few successful setups.
Next: Freeze one complete artifact set, provision the five declared target lanes, then run the support and risk-derived cases without skips, flakes or release waivers.
Technical detail: The generated qualification projection currently separates source review, artifact freeze, API qualification, target runners, 268 declared support cells, 6,626 risk-derived executions, 14 representative workflows and six component artifact sets. The Management set now includes a real client fallback-refusal task. A bounded PASS does not prove every theoretical environment.
Focus areas: artifact sets · target runners · support matrix · fault and recovery evidence (4 workstreams).
○Execution
Implement negotiated response streaming without breaking buffered calls
PlannedThe reliability timer no longer blocks streaming work, but streaming is not advertised as available today. Existing calls must continue to return one buffered result unless an application explicitly uses the future streaming interface.
Next: Implement the same ordered partial/final lifecycle in Rust, Python and TypeScript, then test cancellation, timeout, backpressure and errors after partial output before changing any support claim.
Technical detail: The framing specification defines partial and terminal RESPONSE semantics, but the current SDK/node path remains terminal-only. The implementation gate preserves buffered call() by collecting a valid response sequence internally and does not manufacture partial output for buffered backends.
Focus areas: stream negotiation · cross-SDK parity · buffered compatibility · backend evidence (4 workstreams).
◐Local management
Keep the Management Foundation local and evidence-driven
HardeningThe Management Foundation 0.11.0 developer preview can prepare and verify local first-run work, but it is not a deployed management service and has not passed representative administrator testing.
Next: Collect at least 20 distinct representative observations for each ordinary administrator workflow, reach 95% unassisted success within its time budget, then fix reproducible friction before freezing the artifact set and API boundary.
Technical detail: Management retains the existing local controller authority and iicp.management-bootstrap-workflow.v1 serialized boundary. No Directory discovery, remote fleet authority, production target or cross-domain control is implied by the preview.
Focus areas: first-run friction · authorized-local sandbox · representative administrators · artifact qualification (4 workstreams).
◐Privacy & security
Finish the privacy-first encryption cutover
HardeningYour client now avoids nodes that cannot receive encrypted requests. Today the visible mesh is key-ready; the next job is keeping that true as more people update, leave, rejoin and run new nodes.
Next: Keep encryption keys present on every useful provider, verify encrypted round-trips regularly, remove the temporary key-field alias, and make older compatible nodes upgrade without operator friction.
Technical detail: The directory now has a prepared cutover to emit only canonical cx_public_key for confidentiality routing. SDK consumers retain a short compatibility fallback when talking to older directories, provider paths advertise CX keys, and strict clients skip keyless nodes by default. Repeatable encrypted round-trip verification remains the stronger proof beyond key advertisement.
Focus areas: payload confidentiality · key advertisement · fail-closed migration (3 workstreams).
◐Relay & reachability
Turn relay from experimental into dependable infrastructure
HardeningHome and laptop nodes can now recover better when direct reachability is unavailable by using a paced tunnel or relay path. This helps adoption, but relays are not yet something we ask users to treat as guaranteed infrastructure.
Next: Keep relay availability visible, finish relay bind/security work, test tunnel fallback across Docker and home-network cases, and make recovery predictable before calling it stable.
Technical detail: Current clients/directories keep direct-first reachability handling, host-wide Cloudflare Quick Tunnel pacing/cooldown, supervised temporary-failure retry, and directory resilience fields that distinguish heartbeating from public-routable nodes. Sleep/low-power recovery has worked in live use, but relay remains best-effort and experimental; relay trust/attestation, authenticated bind, relay-path confidentiality, tunnel rotation and abuse handling remain active concerns.
Focus areas: relay health · relay bind security · CGNAT onboarding · automatic tunnel fallback (4 workstreams).
◐Browser node
Keep browser AI useful while marking provider mode experimental
HardeningUsers can try IICP from the browser and can run a local WebGPU model. Sharing that browser model back into the mesh is not release-stable yet.
Next: Continue testing the browser consumer path, local WebLLM runtime, and relay-backed provider path across more browsers, devices and network conditions.
Technical detail: The website includes a browser-native consumer client, WebLLM runtime, relay discovery, and browser provider glue. Provider mode depends on relay availability and is intentionally kept behind Expert-mode affordances.
Focus areas: browser consumer · WebLLM runtime · browser provider glue (3 workstreams).
◐SDK & operator experience
Make setup and self-healing reliable for more real operators
HardeningPublic SDKs are current and the visible nodes are compatible. Older compatible nodes should be able to upgrade themselves, but broader operator testing is still needed.
Next: Run more fresh-install, Docker self-update, NAT, tunnel, relay and upgrade checks with independent operators before declaring release stability.
Technical detail: Current SDKs combine fail-closed key readiness, direct-first tunnel fallback, Docker cloudflared availability, serve-mode updater support, Rust Docker self-update, host-wide Quick Tunnel pacing/cooldown, and supervised retry after temporary route failures. Before calling this production-stable, it still needs updater convergence, encrypted round-trip evidence and wider population testing.
Focus areas: fresh install · self-update · operator onboarding · Docker runtime parity (4 workstreams).
○Self-verification
Make network claims checkable instead of brand-trusted
PlannedIICP should let users and clients check important claims: who served the request, what a node promises, what it retains, where routing went, and whether a fallback happened.
Next: Broaden signed node manifests from integrity evidence into operator-bound/known-operator evidence, add durable revocation lists, and keep routing receipts plus fallback disclosure moving toward machine-checkable proofs.
Technical detail: Reduced pattern set from the self-verification approach: signed manifests, first operator-bound policy-manifest status, capability challenges, retention declaration checks, routing receipts, directory neutrality proof, multi-directory cross-checks, policy hash pinning, local policy enforcement, public conformance suite and fork continuity pack.
Focus areas: signed manifests · routing receipts · directory neutrality · forkability (4 workstreams).
○Compliance readiness
Turn GDPR and EU AI Act readiness into usable controls
PlannedIICP has technical privacy controls and a beta transparency baseline. The next step is identifying responsibility for current data processing, completing the formal privacy information, making rights easier to use, and checking AI notices against the rules that apply from 2 August 2026.
Next: Complete the current-infrastructure GDPR controller and Articles 13/14 analysis; assess each maintained AI surface against the Commission's final Article 50 guidelines; keep the signed operator-key rights path usable; and extend known-operator and transfer-aware routing across clients.
Technical detail: Technical controls include prompt-free directory routing, a breach runbook, operator-key DSR actions, AI-risk classification, DPIA/processor-transfer baselines, routing policy profiles, strict browser region filtering, signed policy manifests and first operator-bound status. IICP remains an unfunded, non-commercial research project, not a service, but that label is not a blanket GDPR or AI Act exemption. Current-infrastructure controller analysis, approved legal bases, retention periods, recipient/transfer details and a deployment-specific Article 50 assessment remain open; operator terms, DPAs, organizational details and qualified legal review are additional gates before any future service offering.
Focus areas: GDPR controller facts · Article 50 applicability · operator rights · transfer-aware routing (4 workstreams).
◇Federated directory
Publish the Rust preview without enabling federation
GatedThe Rust directory source is available for operator evaluation. Independent public replicas still wait until the core protocol and operations are stable.
Next: Collect independent Rust operator evidence first; enable federation only after migration, rollback, partition and recovery gates pass.
Technical detail: The Rust v0.1.15 operator preview, signed event log, redirect handling and replica lifecycle pieces exist. Publication is not activation: public federation remains gated because recovery and compatibility changes would otherwise need coordination across independent replicas.
Focus areas: replica registration · 307 integration · federated directory release gate (3 workstreams).