What is Aster?

Aster is an identity-first RPC framework for distributed systems. It replaces the hostname-and-infrastructure model of conventional RPC with cryptographic identity, peer-to-peer transport, and content-addressed service contracts.

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.

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. The 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. It supports three modes: XLANG (cross-language, tagged types), NATIVE (single-language, maximum performance), and ROW (zero-copy random access).

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

Aster is Python-first. The Python implementation is the reference exemplar, and all features are validated there before being ported to other languages.

Language	Status
Python	Reference implementation (active development)
Rust	Planned (Phase 2)
JVM (Java/Kotlin)	Planned (Phase 3)
.NET (C#/F#)	Planned (Phase 3)
Go	Planned (Phase 4)
JavaScript/TypeScript	Planned (Phase 4)

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.