What is Aster?
Aster is a peer-to-peer RPC framework. Machines need to authenticate to other machines, often on behalf of a user, and Aster makes that safe — without a central authority and without shared secrets.
The 2026 vivid example is AI agents calling tools on remote machines: an agent on machine A wants to invoke a function on machine B, you don't want a hosted proxy in between, you don't want to rotate API keys, and you want the call to be scoped to specific methods. That's exactly what Aster solves. The same engineering also covers IoT fleets, edge compute, multi-tenant microservices, and anything else where the machine is the principal and the user is the delegating authority.
The core idea
In traditional RPC, a service call goes to a network address: a hostname, a port, a load balancer. The identity of the thing you are talking to is an afterthought, bolted on via TLS certificates or OAuth tokens.
Aster inverts this. Every endpoint has an ed25519 keypair. The public key is the address. When you dial a service, you dial a cryptographic identity -- not a hostname, not an IP address, not a DNS record. The underlying transport resolves that identity to a network path, handles NAT traversal, and establishes an end-to-end encrypted QUIC connection. No infrastructure required. Identity is in the connection, not bolted on.
Three independent layers
Aster is composed of three layers, each of which can be understood and used independently:
Transport: iroh QUIC. The connection layer is iroh, which provides QUIC over UDP with built-in NAT traversal, relay fallback, and connection migration. Every endpoint is identified by its ed25519 public key (called an EndpointId). You can use iroh's transport directly, without Aster's RPC layer.
Serialization: Apache Fory, with a JSON escape hatch. The default wire format is Apache Fory, a high-performance cross-language serialization framework. Fory serializes native language objects directly -- no IDL compilation step, no generated code. Aster exposes three modes: XLANG (cross-language, tagged types, the default), NATIVE (interoperability second to performance), and JSON (human-readable on the wire). JSON mode is the way out of the classic gRPC debugging trap: when something is going wrong in production and you reach for tcpdump or wireshark, you get readable payloads instead of opaque protobuf bytes. It is also the mode the dynamic proxy client (client.proxy("ServiceName")) speaks, so you can call any Aster service from the shell without generating a typed client first.
Contract: language-native service definitions. Services are defined using the idioms of your language -- decorators in Python, annotations in Java, attributes in C#, macros in Rust. There is no .proto file, no code generation step. The framework extracts a canonical service definition from your code and hashes it with BLAKE3 to produce a contract_id that uniquely identifies the service interface.
What makes Aster different
Peer-to-peer, not client-server. There are no mandatory servers. Any endpoint can serve and consume services. Relay servers exist as a fallback when direct connections fail, but they are not proxies -- they are part of the NAT traversal infrastructure, not the application architecture.
End-to-end encrypted by construction. Every connection is authenticated by the QUIC handshake using ed25519 identity. There is no separate TLS termination step, no certificate authority, no key distribution problem. You know who you are talking to because the transport proves it.
NAT traversal built in. iroh handles hole-punching and relay fallback transparently. Services behind NATs, firewalls, and carrier-grade NATs are reachable without port forwarding, VPNs, or load balancers.
Cross-language wire protocol. Fory's XLANG mode produces tagged, self-describing payloads that any language can decode. A Python service and a Java client exchange native objects over the same wire format without code generation or schema compilation.
Built-in trust model. Aster includes a four-gate authorization model rooted in an offline ed25519 key. Enrollment credentials, attribute-based access control, and capability requirements are part of the framework, not external dependencies.
Content-addressed contracts. A service's contract_id is the BLAKE3 hash of its canonical definition. The same interface defined in any language produces the same hash. This enables version-safe discovery, compatibility checking, and cross-language interop verification without a central schema registry.
Decentralised service registry. Service discovery is built on iroh's data primitives: iroh-docs for mutable state (leases, aliases), iroh-blobs for immutable artifacts (contract bundles), and iroh-gossip for real-time notifications. No Consul, no etcd, no DNS.
RPC after hostnames
The phrase "RPC after hostnames" captures the design intent. Conventional RPC frameworks assume stable network addresses, centralized infrastructure, and certificate authorities. Aster assumes none of these. Connections go to who, not where. The network path is the transport's problem, not the application's.
This is not "gRPC but faster." It is a fundamentally different model, built for environments where the assumptions of cloud-native infrastructure do not hold: edge computing, IoT networks, multi-cloud meshes, air-gapped systems, and peer-to-peer applications.
Language support
Python and TypeScript are shipping 0.1.2 as first-class bindings today, sharing the same Rust core and wire protocol. Java, .NET, Kotlin, and Go are in progress. Rust is planned.
| Language | Status |
|---|---|
| Python | Shipping 0.1.2 (first-class) |
| TypeScript | Shipping 0.1.2 (first-class) |
| Java | In progress |
| .NET (C#/F#) | In progress |
| Kotlin | In progress |
| Go | In progress |
| Rust | Planned |
All language implementations share the same wire protocol and produce identical bytes on the wire. A service written in any supported language can interoperate with clients in any other.