You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(docs): align docs site with launch playbook four-layer framing
Rewrite docs homepage hero to mirror aster.site: eyebrow now says
'Peer-to-peer RPC framework', tagline is the durable thesis, lead
paragraph rolls in the pain catalog + 'identity in the connection'
line, and the hero metrics strip now names iroh, Apache Fory,
BLAKE3, and four-gate auth instead of generic labels.
Primary CTA is 'Build Mission Control' matching aster.site; secondary
is 'Try it in 60 seconds'. Kills the broken TypeScript CTA and the
gRPC-killer framing from the hero. Launchpad and language strip
language cards now link to the right destinations. 'AI-native'
section kicker reframed as 'MCP integration' per playbook vocabulary.
Overview docs: what-is-aster.mdx and why-aster.mdx both now open
with the durable thesis and 2026 agent example before any mention
of identity-first framing or gRPC comparisons.
Quickstart sidebar order: python quickstart, Mission Control
walkthrough, then What's next. sidebar_label overrides make the
progression explicit.
Config: tagline + footer + navbar GitHub link all point at the
repo instead of the org and match the aster.site durable phrase.
Copy file name to clipboardExpand all lines: docs/overview/what-is-aster.mdx
+4-2Lines changed: 4 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,13 +4,15 @@ title: What is Aster?
4
4
slug: /overview/what-is-aster
5
5
---
6
6
7
-
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.
7
+
**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.**
8
+
9
+
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.
8
10
9
11
## The core idea
10
12
11
13
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.
12
14
13
-
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.
15
+
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.
Copy file name to clipboardExpand all lines: docs/overview/why-aster.mdx
+9-1Lines changed: 9 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,15 @@ title: Why Aster?
4
4
slug: /overview/why-aster
5
5
---
6
6
7
-
## The assumptions are breaking down
7
+
## The durable problem
8
+
9
+
**Machines need to authenticate to other machines, often on behalf of a user.** More code now runs on more machines than people, and the gap is widening. Today the answer to machine-to-machine authentication is API keys, mTLS certificates, IAM roles, service mesh sidecars, or OAuth proxies -- five different mechanisms, none of them designed for machines, all of them bolted onto transport that doesn't care about identity.
10
+
11
+
Aster's answer is to put identity *in* the connection. Every endpoint has an ed25519 keypair, the QUIC handshake authenticates both sides cryptographically, and a four-gate authorization model enforces capability-based access before your code runs. No shared secrets, no central authority, no OAuth proxy in the middle.
12
+
13
+
The 2026 vivid example is AI agents: an agent on machine A wants to call a tool on machine B without a hosted proxy, without rotating API keys, with access scoped to specific methods. The same engineering covers IoT fleets, edge compute, multi-tenant microservices, and anything else where the machine is the principal and the user is the delegating authority.
14
+
15
+
## The cloud-native assumptions are breaking down
8
16
9
17
gRPC, Thrift, and the broader cloud-native RPC ecosystem were built on a set of assumptions that made sense for data-center services behind load balancers:
Copy file name to clipboardExpand all lines: docs/quickstart/mission-control.mdx
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,7 @@
1
1
---
2
2
id: mission-control
3
3
title: "Build a Control Plane"
4
+
sidebar_label: "Mission Control walkthrough"
4
5
slug: /quickstart/mission-control
5
6
sidebar_position: 2
6
7
description: "Build a real-world control plane with four RPC patterns, session-scoped agents, capability-based auth, and cross-language interop — in under an hour."
0 commit comments