Run it. Understand it. Verify it.

Raven is an open-source communication protocol and terminal-native CLI for Linux, Windows, and macOS. Its RVN1 envelope and local identity model support peer communication without a Raven-operated central messaging server. Machines are the nodes.

Raven is a communication system: RVN1 defines the protocol, Raven Node implements the host runtime, and the CLI provides the terminal interface. Human messaging is one use case; relaying and agent communication are part of the wider architecture.

Yes. The protocol specifications, security-critical core, Raven node, and terminal client are public under AGPL-3.0. Read the source and license.

Raven targets source builds on Linux, Windows, and macOS. Run it from a native shell, PowerShell or Windows Terminal, Terminal.app, iTerm2, or a compatible terminal. Individual carrier availability can differ by host.

No central account, email address, or subscription is required to create a Raven identity. Your supported local key store holds the identity material.

Raven does not require a Raven-operated central messaging server for its supported peer delivery path. A receiving node still runs on a host. Optional relay, bridge, or bootstrap hosts may help carry traffic; serverless does not mean that no computer listens on a network port.

The CLI gives humans and operating-system hosts an explicit interface to identity, peers, message delivery, and node policy. The terminal is a deliberate product choice.

No. The terminal is Raven’s intended interface, not a temporary frontend.

The Rust package retains the name ash and contains two executables, ash and raven, built from the same CLI implementation. Use --bin raven in Cargo commands. The website uses Raven as the product and command name.

Install Git, Rust, and the platform build tools, then use the source-build commands in the installation section. The Cargo package is ash; --bin raven selects the Raven executable. GNU/Linux source compilation and protected identity initialization are separate: fresh Secret Service identity creation is currently disabled in the published implementation. Check the release status before planning a new production Linux node.

Install Git, Rust, and the platform build tools, then use the source-build commands in the installation section. The Cargo package is ash; --bin raven selects the Raven executable. Run the executable from Terminal.app, iTerm2, or a compatible shell. Keychain access must be available to the running binary and user.

Install Git, Rust, and the platform build tools, then use the source-build commands in the installation section. The Cargo package is ash; --bin raven selects the Raven executable. Run the commands in PowerShell or Windows Terminal and invoke raven.exe. Build tools and the node service’s native validation gates are documented separately; compilation alone does not establish production service readiness.

Rust and Cargo are required for the documented source build. Running an already built, compatible binary does not require Cargo, but its operating-system and runtime requirements still apply.

After building, invoke target/release/raven on Linux or macOS, or target\release\raven.exe on Windows, from the node workspace. Alternatively add that directory to PATH. Run raven --help for commands or raven for the guided terminal menu.

Run raven init with a stable profile path, or raven --data-dir /absolute/profile/path init. Initialization needs the supported protected key store; GNU/Linux fresh identity creation is currently gated. The command exposes public identity details, not private seeds.

Run raven contact add --help for the current options. Add the peer’s public address and key, set a local tag, configure a reachable LAN endpoint, and pin the fingerprint after comparing it through a trusted channel. A display name or @tag alone does not establish identity.

After contact verification and listener setup, raven send --contact @alice --chat opens the interactive chat path for your Alice contact. Message content is read through standard input; the CLI does not accept plaintext message content as a positional send argument. Delivery requires an authenticated session.

Use raven contact list to inspect saved contacts and raven status to inspect node and transport state. A saved contact is not proof of a live connection. raven doctor diagnoses node readiness; readiness alone is not proof of successful message delivery.

Run the separate raven-node service under a supported supervisor using a stable profile and the documented listener configuration. The repository contains launchd, systemd-user, and Windows service helpers; their release gates and platform requirements differ. Read the service instructions rather than assuming that a background CLI is a fully configured node.

The terminal interface does not require a desktop window or Bluetooth. The selected protected identity backend still needs its required services, and fresh GNU/Linux identity creation is currently held. Do not bypass this gate with a plaintext lab backend for production.

Use raven inbox to inspect the committed endpoint inbox, raven contact list to inspect contacts, and raven status to inspect node and transport state. A queued message is not proof that the peer received it.

A Raven ID is a protocol address derived from public cryptographic identity material. Use it together with the public key and verified fingerprint; a display name or local @tag is not a cryptographic identity.

The supported init path creates identity material locally using the implementation’s cryptographic randomness and persists the seed through the selected protected backend. If that backend cannot safely initialize or load the identity, the normal path fails closed.

No. The ID derives from public identity material rather than a centrally registered contact address.

The identity seed uses macOS Keychain or a DPAPI-protected file on Windows. GNU/Linux has a Secret Service loading path, but fresh protected identity creation is currently disabled in the published code. A successful source build does not remove that gate. The CLI uses --data-dir when supplied. Otherwise it checks RAVEN_DATA_DIR, then ASH_DATA_DIR, then the home profile: ~/.raven, or an existing ~/.raven-ash when ~/.raven is absent. Without HOME it falls back to ./raven-data. Use an explicit stable path for services and separate profiles. The profile location and protected seed storage are different: copying the folder alone may not copy the identity.

Compare the peer’s public-key fingerprint through a trusted channel before using contact add with --verify-fp. Use raven contact verify --tag alice to inspect verification for a saved Alice tag. Run each command with --help for its options.

Separate stable --data-dir profiles can hold separate identities where the protected backend supports initialization. Use distinct listener endpoints and consistent profile settings for each process. Creating another profile does not clone an existing identity.

Do not assume that copying a profile is a supported identity migration. Protected seed access can be bound to the OS user, key store, and profile path. Use only a documented migration or recovery mechanism for your build; no universal export-and-import workflow is claimed.

There is no central recovery service. Without a compatible backup or supported recovery method, you may need a new identity and fresh peer verification. Protocol proposals for social recovery do not establish availability in the current CLI.

The CLI stores contact records in contacts.json under the selected profile, including public key details and local labels. Treat these trust records as integrity-sensitive local state and restrict access to the profile.

Peers with a working local network can use the supported LAN path. Disconnected delivery through optional Bluetooth or store-and-forward carriers depends on implementation, configuration, and reachable peers.

The architecture includes Internet/libp2p, LAN/direct peer, relay/store-and-forward, and optional local radio carriers. The current CLI’s authenticated LAN path is distinct from experimental Internet coordination, automatic multi-hop routing, and headless Bluetooth support.

No. A host can run Raven over a supported network path without Bluetooth. Bluetooth is an optional local carrier, not the identity of Raven or a hardware requirement for a server.

Yes, through a supported network carrier and a correctly initialized host. A Bluetooth adapter is not a requirement for the Raven node architecture.

A participating node holds a sealed envelope in a configured queue and forwards it when an eligible route is available. Replication, expiration, and duplicate-handling rules bound forwarding. A queued envelope does not establish eventual delivery.

Relay policy is explicit. The CLI exposes raven node relay on and raven node relay off; use --help and inspect raven status. Enabling policy does not implement a missing carrier or automatically discover a multi-hop route.

The Raven forwarding design carries sealed envelopes instead of plaintext. Relays and network observers can still observe traffic timing, size, endpoints, or other carrier metadata. Encryption is not a promise of anonymity or guaranteed delivery.

Envelope identifiers, seen-message state, and queue/replay checks prevent repeated processing along supported paths. Expiration and nonce or session checks have different roles; their exact persistence and bounds follow the carrier and security profile.

Do not assume automatic connectivity through arbitrary NATs. The terminal architecture includes libp2p, but full DHT/relay coordination and hole punching across real NATs remain experimental. A reachable LAN peer is a different case from Internet traversal.

The supported authenticated direct peer path can connect hosts on a reachable local network without a public Internet messaging service. Both hosts need verified identities, compatible session setup, and a running listener.

Real headless GATT is not complete in raven-node. CI uses a mock BLE adapter. A compatible transport implementation and real hardware validation are required before claiming Bluetooth delivery on a particular host.

Automatic multi-hop production route selection is not wired into the current CLI send path. Explicit bridge-pull functionality and test harnesses are separate from automatic routing in the command you run.

No such blanket claim is made. ATSAM specifies hybrid pairing and ratchet work, but full post-quantum interoperability is not complete in the Rust terminal path. Use the supported profile and its documented release gates.

The project has not been independently audited. Public code, test vectors, and automated checks support review but do not constitute an independent audit or proof of all physical network conditions.

The envelope architecture can support text, files, and structured encrypted payloads such as JSON or machine events. Support for a particular payload or command depends on the implementation; this does not mean every file or agent workflow already runs through the encrypted node.

The inspected Raven command surface does not expose a general group-management command, and no production MLS capability is claimed here. Group membership, group-key rotation, and group workflows must be documented and implemented before this site describes them as available.

No. Queue TTL limits an envelope’s forwarding lifetime. It does not erase plaintext, a local history entry, or a backup already retained by a recipient.

Stop the relevant node and remove the profile, keys, message data, and backups you intend to delete. Removing the executable alone does not remove its data directory. Deleting your copy does not delete copies held by peers.

The website and the peer protocol are separate. Visiting the website sends ordinary HTTP request information to its hosting provider. Read the privacy page for website hosting, local node state, and optional agent-provider boundaries.

No. RDAP is an experimental A2A companion with its own keys in .team/keys. It does not currently submit application payloads through the production Raven node’s ATSAM session actor. Shared identity and encrypted node integration remain work in progress.

RDAP signs tasks and answers and pins trusted peers. Direct HTTP does not encrypt the content; use HTTPS or a protected network layer for confidentiality. Its experimental plaintext mailbox is disabled by default and must not be treated as Raven end-to-end encryption.

Clone the RDAP repository and follow its current setup and signed-task quickstart. Linux and macOS use ./rdap; Windows uses rdap.cmd. RDAP has its own dependencies, identity setup, trusted-peer configuration, and model/carrier settings.

That depends on the configured peer, carrier, and model provider. A hosted provider receives the request and context sent to it. A peer signature does not establish local-only processing or make an unencrypted carrier confidential.

Use the Raven issue tracker for reproducible non-sensitive bugs. For a security issue, follow SECURITY.md and avoid posting private keys or message content publicly.