Skyzai Communication Mesh: A Shared Node Fabric for People, Models, and Machines

warning

Proposed design, not a live service — discussion draft v0.3 (merged series), 26 September 2026. This paper frames research questions and candidate boundaries. SPECTRE's repository holds a routing skeleton; no live Skyzai messenger, consensus network, VPN, CDN, or inference cloud is claimed.

Abstract

Skyzai is exploring whether a shared node fabric can carry direct one-to-one conversations, broadcasts, multi-source aggregation, many-to-many routes, ledger consensus, and eventually inference. This proposal separates the physical node network, SPECTRE, from the protocols that use it. A machine may host both a Hashgraph consensus process and application routing, but message confidentiality, packet delivery, ledger finality, and service payment keep distinct guarantees.

The first user-facing experiment is a voice-first messenger with ephemeral messages. The existing Communicator plan uses Nostr as a bootstrap until SPECTRE runs; a messenger on that path does not show that MESH routing works, so the network is measured separately. Broadcasts and milestones with content delivery, and then inference, follow only after delivery, privacy, operator cost, and recovery can be measured. The central research question is whether local observations about neighboring links can improve packet delivery without changing consensus rules, weakening message privacy, or creating a central topology controller.

1. Architecture boundary

People · models · agents · organizations · robots
                    │
  FLOW 1:1 · RELAY 1:N · AXIOM N:1 · MESH N:N        communication shapes
                    │
  MESH routing: adaptive next-hop choice for application packets
                    │
  SPECTRE: proposed physical node and transport commons
     ├─ Hashgraph consensus process   (separate protocol; orders the shared ledger)
     ├─ message relay / cache
     └─ optional VPN / CDN / inference services
  Skyzai composes the organism and user-facing services over SPECTRE.

SPECTRE is the proposed physical node network and transport commons: machines, links, peer discovery, telemetry, and packet transport. MESH is its many-to-many routing primitive. Hashgraph consensus is a separate protocol that may run on some of the same operator nodes and orders the shared ledger. Some operators may run both MESH routing and ledger membership, but neither role follows from the other, and the first SPECTRE operators could come from an initial ledger-node fleet. This is a candidate decomposition, not an adopted implementation; keys, membership, message formats, consensus rules, data retention, and service accounting need separate specifications.

2. Hashgraph ordering and MESH routing

The 2016 Hashgraph paper describes nodes gossiping with randomly selected peers, recording gossip history in a hashgraph, and deriving virtual votes from that history. Its model allows up to just under one-third of members to be colluding attackers who may delay or delete any message, provided that a member that keeps resending to another member eventually gets one through. That is a retransmission assumption, not a promise that a single message arrives. It also assumes secure signatures and hashes. The base bound counts members; a stake-weighted version is given too, with an invite rule offered as one example of Sybil resistance. An open network must state which count and which admission rule it uses. Fairness depends on members being online: a partitioned minority's view stops counting without any visible signal.

These results apply to the specified consensus algorithm. They do not automatically cover a new router. The safe first experiment leaves event validity, voting, and finality unchanged and keeps Hashgraph's random-peer gossip intact. MESH routes application packets independently. A later experiment could test adaptive paths for consensus gossip, but it must first establish that the delivery assumptions and security proof remain valid. Route-scoring output must not set voting weight, stake, event validity, or finality. “Same nodes” means one physical fleet may host both functions; it does not make consensus and routing one protocol.

3. Four communication shapes

Shape	Working name	Intended job	Open boundary
1:1	FLOW	Bilateral channel; first use is direct one-to-one messaging, with privacy properties defined for each delivery mode	Settlement is a separate capability with its own trust boundary, keys, state, and audits.
1:N	RELAY	Public or permissioned broadcasts, milestones, live or retained feeds	Audience, membership, retention, moderation, and delivery guarantees differ by mode.
N:1	AXIOM	Rank many candidates for one recipient, or combine inputs into one result	Ranking and aggregation have different objectives; neither is truth, consensus, or ledger finality.
N:N	MESH	Route among network peers over multiple paths; many publishers' public posts are an application style here	The routing primitive inside SPECTRE; it does not replace Hashgraph.

These meanings are settled for the research. Some older pages still describe FLOW only as settlement, RELAY as “uncensorable,” or AXIOM as “settled truth” or consensus; those descriptions are out of date and pending correction.

4. One-to-one messaging and how long each copy lasts

The first messenger should use established cryptography rather than introduce a new encryption protocol. Evaluate Signal's PQXDH and Double Ratchet for direct conversations, Sesame for asynchronous multi-device sessions, and MLS (RFC 9420) for encrypted groups. These remain research candidates, not a final selection. Without verifying each other's identity keys, for example by comparing a safety number or QR code, two people get no cryptographic assurance about who they are talking to, and a compromised key directory can substitute keys. None of these specifications defines recovery after someone loses every device; any recovery method trades some forward secrecy for availability.

Nostr can be evaluated for interoperability. NIP-04 is marked deprecated and unrecommended. NIP-17 defines a draft/optional encrypted-chat format built from NIP-44 and NIP-59. NIP-44 does not provide forward secrecy or post-compromise security, exposes IP and date metadata, and, despite its padding, only partially hides message size. NIP-17's “disappearing messages” are relay expiry, not forward secrecy. NIP-59 distinguishes stored asynchronous gift wraps from live-only kind 21059 events that relays must not store, and asks relays to serve stored gift wraps only to authenticated recipients; that protects recipient metadata but does not hide the sender's IP address or timing from the relay.

Voice needs its own decision. A voice note is a stored, encrypted attachment and inherits the message protocol's limits; a live push-to-talk stream is a real-time media session that needs its own transport security. No NIP specifies live voice. Push-notification services also see delivery timing and device identifiers, and message content unless notifications carry no readable preview.

The product rule distinguishes a transient message from durable intent:

transient message → APU processing → automatically saved intent record
       expires       (plain text,         persists independently;
                      transient)          records who asked, can be undone

When a user talks to APU, APU may automatically save a useful note, task, or reminder. The intent persists; the raw message, audio, transcript, and model output do not. Each change records whether the person asked for it or APU inferred it, and can be undone; merges and deletes are made undoable or confirmed first. APU is not a party to a conversation between two people unless someone addresses APU or explicitly asks it to act on a message. When it is addressed, its inference endpoint and model provider can see that turn in plain text. Non-retention is not non-processing. The saved note is the one object that outlives the message, so the service must state whether it is encrypted at rest, who can read it, and how it is corrected, exported, or deleted. “Ephemeral” covers several separate properties — relay retention, device copies, backups, recipients' copies, and APU processing — and each needs its own statement. Relay deletion cannot erase a recipient's copy, screenshot, or backup.

5. Local learning on MESH

The current source-level prototype calculates a weighted energy score, samples peers from a Boltzmann distribution, and includes a uniform random-peer mode. It does not establish measured network improvement or a deployed per-neighbor learner. The function meant to update scores from outcomes exists but is not connected, and it adjusts only global weights. The monitor meant to switch to random-peer routing when the network degrades is placeholder code, so no automatic fallback exists yet. Peer reports are taken as given; a signature field is not verified. The direct-route path bypasses scoring, and a second, separate path selector serves the VPN design.

The research hypothesis is a small local model per node and traffic class. A node records outcomes such as delivery success, latency, loss, queue depth, retries, staleness, cost, and available capacity. A route scorer ranks candidate peers or paths. Local successes may strengthen a preference; failures and stale evidence may weaken it. Calling this “neurons that fire together, wire together” is an analogy until the update rule, reward, decay, and stability are specified.

Compare random-peer routing, deterministic shortest path or ETX, Q-routing, the existing weighted energy score, and a learned energy model with bounded exploration. Test route concentration, poisoning, Sybil behaviour, eclipse attacks, adversaries that tune their self-reported numbers, congestion, privacy leakage, and recovery. Because route learning deliberately moves away from random peer choice, it can concentrate one pair's traffic on a few nodes; that traffic-analysis risk must be measured against a random baseline. Peer-reported telemetry is evidence to evaluate, not truth. Erlang/OTP supervision may help isolate and restart components; it does not prove packet throughput.

6. RELAY, AXIOM, and later services

RELAY should distinguish public signed events, permissioned group fanout, live streams, and retained feeds. One publisher's milestone fanout fits RELAY; discovery of and interaction with many publishers' public posts is a MESH application style with its own persistence and indexing questions. Milestones are signed, versioned events with provenance and an explicit audience. A CDN cache policy is separate from event publication; forwarding does not prove every subscriber received an event.

AXIOM research should distinguish personalized selection from aggregation. A TikTok-like feed ranks many candidate posts for one recipient; a reducer combines attributable inputs into one result. These need different objectives and safeguards. Study relevance, user control, provenance, exposure concentration, and manipulation resistance for ranking; define validation rules, algorithm version, missing-participant state, uncertainty, and correction path for aggregation. Neither output is consensus merely because many nodes forwarded the source material.

The proposed user sequence is voice-first messenger → broadcasts and milestones / CDN → model inference. The proposed node-service sequence is separate: consensus participation → optional VPN / CDN → inference hosting. The node-service sequence is not a path every node must follow: ledger admission, forwarding, third-party exit, caching and model serving are separately qualified roles. A node is not automatically a VPN; third-party egress requires operator opt-in, exit-policy disclosure, and abuse handling. A reward or service receipt is not proof of profitable demand. Open-model variants, world models, and robotics workloads each need model provenance, data rights, quality, safety, hardware, price, and result-verification requirements.

7. Threats, research, and evaluation

The paper keeps one threat model and data lifecycle for the whole series. It covers malicious, colluding, eclipsing, and Sybil nodes; route poisoning; partition and stale topology; key compromise and key-directory substitution; device loss; relay retention and traffic analysis; push-notification services; APU endpoint and model-provider exposure; the saved-note store; recipient screenshots and backups; denial of service; and operator exit failure.

Two processes on one machine are one fault domain, so the evaluation also reports the co-hosted ledger's queue delay and event delivery under simultaneous application load. The architecture hypothesis weakens if a conventional centralized or federated messenger meets the same delivery, privacy, cost and governance goals more reliably. Before claiming a working mesh, compare reproducible topologies and workloads. Report delivery ratio, p50/p95/p99 latency, throughput, path stretch against the shortest-path route, route churn, overhead bytes, energy and cost per delivered unit, fairness, recovery time, model convergence, and metadata exposure. Include colluding, malicious, stale, and unavailable nodes. Simulated gains are simulation results until independently reproduced on a described testbed.

The research sequence keeps stable numbers: Paper 0, system and threat boundaries; Paper 1, consensus/routing separation; Paper 2, route-learning baselines; Paper 3, FLOW privacy and data lifecycle; Paper 4, RELAY broadcast and CDN; Paper 5, AXIOM selection and aggregation; Paper 6, MESH at network scale; Paper 7, node economics and inference; Paper 8, node runtime and interoperability. Each paper states a baseline and a result that would stop or revise its hypothesis. This begins with a small messenger path, not with a universal protocol or a network-wide intelligence claim.

References

• Baird, The Swirlds Hashgraph Consensus Algorithm, SWIRLDS TR-2016-01.
• Boyan and Littman, Packet Routing in Dynamically Changing Networks: A Reinforcement Learning Approach (Q-routing), NeurIPS 1993.
• Signal: PQXDH, Double Ratchet, Sesame.
• IETF, Messaging Layer Security, RFC 9420.
• Nostr: NIP-04, NIP-17, NIP-44, NIP-59 (content encryption only: no forward secrecy, and relays see IP addresses and timing).
• Reynolds, Flocks, Herds, and Schools, ACM SIGGRAPH 1987 — local-neighbor analogy only.
• Erlang/OTP Design Principles.