What to expect from the alpha¶

Kunuleco is in closed alpha. That word is doing real work: the system runs, people use it daily, and it is also under heavy construction. This page is the honest version of what that means for you.

What "alpha" means here¶

Rough edges are normal. Commands occasionally misbehave, output is sometimes untidy, and reconnecting after a laptop sleep can take a nudge. When something looks stuck, /reconnect (or restarting the app) is a legitimate move, not an admission of defeat.
Releases move fast. Updates ship frequently. /check-updates and /update fetch them, and every install and update is verified against a signed manifest before it applies; nothing installs without a valid signature.
Some releases require a fresh install. Occasionally a release changes something foundational and updating in place is not enough. The release notes say so explicitly when that happens. This is exactly why you should export an identity backup early:
```
export-identity ~/kunuleco-backup.kuneid <base64_passphrase>
```
Treat alpha data as precious but not yet promised. Your spaces persist on your node and survive restarts, but durability guarantees are still being built out. Keep copies of anything you would truly hate to lose.

A note on security, plainly¶

The design is capability-based from the ground up, releases are cryptographically signed, and the security of the system is an active, ongoing engineering effort. It is also alpha software that has not yet had an independent audit. Use it for what it is today: a place for real conversation among people you trust, not yet a vault for secrets or a tool for high-risk situations.

Reporting problems¶

Reports from testers are the main engine of improvement. The capture step is built in. In the Urchin client, type /bug (over SSH, bug <description>) right when something looks wrong. It takes a structured snapshot on your own machine and sends nothing. It writes a JSON file to the bugs/ folder in your data directory and prints the file path and an 8-character id.

/bug captures the machine state, and your alpha channel (your welcome note says where) is how it reaches us. Zip the bugs/ folder and send it along, quoting the id. If you filed from the Urchin client there are two files sharing one id, one from the client and one from the node. Send both. A good report adds:

What you did: the command or click, as exactly as you can.
What you expected, and what happened instead: paste the output if you can.
Build info: @version prints the server build; mention your platform too.
Connectivity state if it seems network-related: what transport showed.

For anything the capture cannot see (crashes on startup, installer trouble), describe it in your alpha channel directly. Small observations are welcome; "this wording confused me" is a real bug.

Thank you¶

Alpha testers are co-builders. The offline mesh at DWeb Camp 2026, the friends system, the guided tour: all of it got better because someone tried it early and said what they saw. Welcome aboard.