erza

protocol sketch

erza example.com

The client should assume HTTPS, fetch a section-first erza app from a domain, and render the result as a terminal session. The transport is the new piece. The authoring model remains .erza.

flow

Minimal request model

1

Resolve a domain

`erza example.com` assumes HTTPS and asks the server for an erza app, not a browser document.

2

Fetch a screen tree

The server returns a safe section-first screen tree the client can render locally.

3

Send actions back

Links and actions post structured events back to the server while client-side history stays local.

4

Rerender in place

The client receives the next screen or a diff and updates the local terminal session.

guardrails

Keep the product boundary intact

Do not ship arbitrary backend code to the client.

Keep the wire format declarative and terminal-native.

Preserve normal backend integration over HTTPS.

Avoid inheriting browser compatibility scope by accident.

rough shape

Potential wire-format outline

GET  /app
Accept: application/erza+json

200 OK
Content-Type: application/erza+json

{
  "session": "abc123",
  "screen": { "title": "Inbox", "children": [...] },
  "actions": { "open_message": { "method": "POST", "href": "/actions/open" } }
}

POST /actions/open
Content-Type: application/json

{ "session": "abc123", "message_id": 42 }