Skip to content
On this page

Project status

Legible is a draft, with formats, reference code and paths available for initial tests that follow participants' work: what they can understand, add and continue, and how much effort it takes. The economic hypothesis needs to be examined through that use, beyond the technical correctness of the files.

Available to try

You can prepare a contribution with AI, review it and save it as a Legible Draft. The first-use attachment contains instructions, the format and examples. Start with your first draft. According to your intention, you can share and develop, participate in a space or create one. The general guide includes an optional space model; the participation guide is an alternative for that path. Choose one attachment. The example space is fictional and optional; participants still configure access, channels and tools. Participants exchange files they choose, preserving origins and relationships.

The site, book and paper are available in Portuguese and English. Portuguese is also the complete normative source for draft 0.4 of the specification, the NCO and NRC 0.2; English editions are synchronized reference translations. The initial publication baseline uses v2 schemas.

Experimental, with known limitations

The Rust, Python, MCP and local app components provide preparation, validation, verification and local queries. The bench supports testing storage and access per participant. Automated tests cover specific operations; use with actual accounts, MCP clients, Android devices and networks requires checks in those environments. Baseline signing uses plain Ed25519 and OpenSSH.

Versions identify different objects: specification draft 0.4, schemas v2, Rust core 0.1.0, Python library and MCP server 0.0.1, and NRC 0.2. Updating software does not, on its own, change record formats. Normative changes must identify their edition; existing records retain their bytes and adopted convention.

Proposals without completed implementations

The Python library delegates record building, sealing and verification to the Rust core. Its tests and the OpenSSH checks of fixtures provide evidence about specific operations; they do not by themselves demonstrate interoperability between two complete, independently developed implementations. That cross-test remains a maturity milestone to reach, without being presented as a requirement for trying this draft.

A specific Hermes integration, corporate package, contextual discovery across multiple sources, native mobile signing and persistent identity recovery still need development and testing. Consult the implementation catalogue to distinguish available components from proposals.

What tests need to investigate

Correct file exchange is a technical check. Assessing the thesis requires finding out whether a contribution preserved before selection helped someone ask another question, find an alternative or develop work they would not have considered.

Count preparation and reading time, necessary corrections and each participant's benefit too. Comparisons should provide equivalent access to people, models, information and time. Failures and results without gains help identify where the proposal needs to change.

Create a space · Participate in a space · Submit a report or contribution to the protocol

Read this page as Markdown