Getting started once a release exists

Estimated reading: 7 minutes 1 views

Development status: Planned — Planned experience, not instructions. When a supported release and development environment become available, the intended setup flow will let developers obtain the tooling, configure an environment and confirm readiness. Supported versions and exact commands will accompany that release. Exact installation commands and released tooling are not yet available; experimental tooling exists for internal testing only, no public network or source of test funds is available, and nothing is publicly available for live use.

Before you read: Future developer experience: what a supported release would add.

How would you get from nothing to a first working result once tooling is released? This preview walks through the intended stages — obtain tooling, configure an environment, confirm readiness, submit work and retrieve a result — in terms of what a developer would do and what they would have afterwards. It also says what you would need beforehand, what could go wrong and what a release would add. It contains no commands, versions, package names or outputs.

Planned experience, not instructions. None of the stages below can be carried out today.

Before a release: what is and is not available

  • Exact installation commands and released tooling are not yet available.
  • No SDK, command-line tool, public network or source of test funds is publicly available; see Tools, SDKs and wallet availability and Networks and environments.
  • Experimental tooling exists for internal testing only. It is not a getting-started path and should not be used as one.

What you would need beforehand

Status of this section: Planned — a conditional description; requirements would be set by a release.

The intended first-run sequence

Status of this section: Planned — the intended shape of a first run; none of it can be done today.

  1. Obtain the tooling. You would obtain the tooling from an official source announced with the release, together with a way to confirm that your copy is genuine. Exact installation commands and released tooling are not yet available.
  2. Configure an environment. You would set up an environment to work against: a local environment, described on Local development environment, or a test network if one is offered, as announced on Networks and environments. You would use synthetic data and development keys only. Configuration guidance would accompany the release.
  3. Confirm readiness. Before building anything, you would check that the tooling and the environment work together. How readiness would be confirmed would be described by the release.
  4. Submit a first piece of work. You would submit a small first piece of work, such as a transaction or a confidential job; it would then be submitted. The planned submission experience is previewed on Submitting work and retrieving results.
  5. Retrieve the result and follow its stages. You would follow the work through its stages and retrieve the result. Treat a result as recorded but not final until a documented finality status says otherwise. Today no result is reported as final, because finality is not connected; see Agreement and finality status.

The stage words in italics are documentation terms defined on Lifecycle stages used in this documentation, not states of any implementation.

What you would have afterwards

Status of this section: Planned — a conditional description.

  • A working development setup and a first result.
  • A working understanding of the stages your work passes through, and of where recorded differs from final.
  • Not a production deployment, not a place for real data and not any assurance of confidentiality. Today, encrypted-computation interfaces exist only in an internal prototype that simulates the behaviour and performs no real encrypted computation.

The first run at a glance

The table below restates the five stages in one place.

Illustrative local demo — not a released Cubane API, protocol schema or live-network result.

Table: the intended first-run stages, as illustrative documentation text only.

Stage What the developer would do, in words What they would have afterwards What is not yet available
Obtain tooling Obtain the released tooling from an official source announced with the release, and confirm the copy is genuine Tooling on their own machine, with a known version identity No tooling is released and no official source is announced; exact installation commands are not yet available
Configure an environment Set up a local environment, or a test network if one is offered, with synthetic data and development keys only An environment to develop against No local environment or public test network exists; no configuration is published
Confirm readiness Check that the tooling and the environment work together before building anything Confidence that the setup works as the release documents No readiness check is published
Submit work Submit a small first piece of work, such as a transaction or a confidential job A reference to the work, which is now submitted No SDK or public interface exists; nothing can be submitted
Retrieve a result Follow the work through its stages and retrieve the result A first result, presented as recorded but not final Nothing can be retrieved; finality is not connected, so nothing is reported as final

The table is hardcoded documentation text written for this page, not output from any system. It demonstrates the intended shape of a first run. Nothing was installed, configured, checked, submitted or retrieved; no environment or network exists; and no encryption, authorisation, proof or agreement between nodes took place. It contains no commands, tool or package names, versions, configuration keys, outputs or timings, and none should be inferred from it. The column names are not interface fields. See How illustrative examples work in this documentation.

If a first run does not work

Status of this section: Planned — failure categories are described conceptually; no error interface is published.

  • Refused, delayed or rate-limited. A submission could be refused, delayed or rate-limited. The categories, and what an application would be expected to do about each, are on What can go wrong: failure and error concepts.
  • Not final. A result could remain not final, because finality is not available today. This is a condition to design for, not an error.
  • Messages and troubleshooting. Error messages and troubleshooting steps would accompany a release.

Assumptions, trust and limitations

  • The sequence on this page is the intended shape of a first run; the actual steps would be defined by the release.
  • Internal experimental tooling is not a getting-started path, and its output is not evidence of how a release would behave.
  • General practice: keep real secrets and real personal data out of development environments.

Not yet available, and how this page will grow

Supported versions and exact commands will accompany that release. When a supported release exists, the real getting-started guide is intended to replace this preview at the same address, and the change would be recorded in the Documentation change log.

What this page does not claim

This page does not claim:

  • any command, package or tool name, version, system requirement, output or timing;
  • that any step on this page can be performed today;
  • that any public network, test network or source of test funds exists.

Anything not stated here as available should be treated as unavailable.

Glossary

References

No approved public references yet.

Leave a Reply

Your email address will not be published. Required fields are marked *

Share this Doc

Getting started once a release exists

Or copy link

CONTENTS
Ask Cubane

Ask our AI support assistant your questions about our platform, features, and services.

You are offline
Chatbot avatar
What can I help you with?
Scroll to Top