AetherMesh SDK is a headless, application-independent connection and protocol layer for a future decentralized AI network. SDK scope defines its end objectives, current gaps and ownership boundaries.
Eidolon or another application owns UI, user workflows, persistent application agents and provider choice. It can connect to AetherMesh through an optional adapter. Other AI providers must not require the SDK.
The aethermesh_core namespace is retained for compatibility. Today it contains:
- Local identity, lifecycle and runtime configuration
- Capability/expert manifests and input/output schemas
- Job envelopes, results, failures and version metadata
- In-memory messages, file-backed inboxes and local peer/node registries
- Deterministic reference scheduling, execution and simulations
- Local validation, hashes, receipts, lineage and contribution accounting
- A localhost JSON API and diagnostic CLI over the reusable runtime service
- Pinned, mutually authenticated TLS direct-peer sessions with explicit trust
- An opt-in verified tiny-router learning pilot
These pieces exercise SDK contracts without claiming a distributed deployment. Authenticated direct connections exist; public discovery, remote inference streaming, distributed release authority and production consensus do not.
- Client API: explicit connect/disconnect, capability lookup, submit/result, stream/cancel, timeouts and typed failures, independent of any UI.
- Protocol: versioned peer/capability/work/result/verification records, with negotiated compatibility and bounded payload/resource policies.
- Transport adapters: discovery, authenticated sessions, message/byte transfer and retry behavior. Local fixtures remain useful conformance adapters.
- Reference node: deterministic handlers and lifecycle used for integration tests; separate this from consumer imports incrementally, preserving contracts.
- Verification and project metadata: hashes, attribution, artifact manifests, publisher authority and evidence. Keep release authority scoped to each project.
This is a target decomposition, not a claim that these modules already exist. Do not replace working primitives with empty interfaces or rename every import as part of a cosmetic cleanup.
The broader AetherMesh network may use AER (Adaptive Expert Routing) across replicated expert services. REVA describes Router → Expert → Validator → Aggregator; AEF describes the supporting Aether Expert Fabric. These are network/service roles, distinct from Eidolon's executive/manager/worker agents.
The SDK needs contracts to access and contribute to those services. The SDK does not own model-training engines, application conversation/orchestration state, full build scheduling, native installers or product dashboards.
The SDK may eventually discover source revisions, request/query build jobs and transfer verified artifacts. GitHub is an initial source/distribution option; P2P distribution is future work. Source format, signatures, channel policy, rollback protection and independent builder evidence need a separate design. See the design proposals.
A peer serving artifact bytes cannot approve releases for another project. Eidolon and AetherMesh must have separate project identities, versions, channels and authorized publishers, even if they share a transport.
Keep the current unauthenticated development API on localhost. Test schema rejection, tampered results, missing attribution and invalid state transitions. Direct peers have explicit TLS authentication and bounded resource controls. Further deployment threat modelling, privacy controls and DoS mitigation are required before exposure beyond a trusted development boundary. A local receipt is evidence of a local check, not distributed consensus.
Connecting for AI use or updates must not silently enable training, hosting, seeding, paid execution or unbounded bandwidth. Those modes require explicit application/operator policy. Existing local tests do not prove these future network properties.