Release v0.0.31 · junobuild/juno

Summary

This release of Juno introduces several significant improvements, particularly in the Console, as we prepare for potential decentralization.

Key updates include a shift to a single canister architecture, the implementation of stable memory, and a new proposal mechanism for changes.

Overview

Module	Version	Breaking changes
Console	0.0.9	⚠️
Satellite	0.0.18
Mission Control	0.0.11

Crates	Version	Breaking changes
`junobuild-satellite`	v0.0.18	️
`junobuild-storage`	v0.0.1	🆕️
`junobuild-collections`	v0.0.1	🆕️
`junobuild-shared`	v0.0.16

Library	Version	Breaking changes
`@junobuild/core`	v0.0.53
`@junobuild/core-peer`	v0.0.19
`@junobuild/admin`	v0.0.51
`@junobuild/analytics`	v0.0.24
`@junobuild/ledger`	v0.0.32
`@junobuild/utils`	v0.0.22
`@junobuild/config`	v0.0.10
`@junobuild/cli-tools`	v0.0.13
`@junobuild/config-loader`	v0.0.4	🆕️
`@junobuild/storage`	v0.0.1	🆕️
`@junobuild/console`	v0.0.3	🆕️

CLI	Version	Breaking changes
`@junobuild/cli`	v0.0.68

Plugins	Version	Breaking changes
`@junobuild/vite-plugin`	v0.0.14
`@junobuild/nextjs-plugin`	v0.0.8

Docker	Version	Breaking changes
`@junobuild/satellite`	v0.0.29
`@junobuild/console`	v0.0.29
`@junobuild/action`	v0.0.25

Changes

Here is a list of changes included in this release:

Console (Backend)

The Console received the major changes of the release, which are the following:

Single Canister Architecture

Previously, the Console was deployed using two smart contracts: a backend (cokmz-oiaaa-aaaal-aby6q-cai) and a frontend (xxt4w-7iaaa-aaaak-ad7rq-cai). However, there is no inherent need to separate the frontend assets into a distinct smart contract. Consolidating to a single architecture simplifies maintenance and administration, particularly if it becomes governed by a governance.

As a result, the frontend canister (xxt4w-7iaaa-aaaak-ad7rq-cai) will be deprecated. Moving forward, the backend canister (cokmz-oiaaa-aaaal-aby6q-cai) will handle both data and asset provision, serving the administration console on the web.

Stable Memory

Given Juno's ownership model, which grants developers full control, the Console maintains minimal data, primarily a list of Mission Control IDs matched to User IDs. This list is used to connect developers with their realms upon logging into the dApp.

Adopting stable memory is recommended, especially as extending the Console with HTTP capabilities involves storing frontend assets in heap memory. Migrating the list of IDs to stable memory not only aligns with best practices but also supports future scalability.

Proposals

To prepare for a potential decentralization, both processes of uploading new assets and releasing WASM (of the Satellite, Mission Control, and Orbiter) have been implemented with a proposal mechanism.

This means that changes won't be applied directly but will first be uploaded to the stable memory, and for each change, a proposal will be generated. This proposal can then potentially be proposed to governance, and if accepted, the changes will only be applied once approved.

Collections and Storage Crates

The Console will inherit the same storage and web capabilities as Satellites. On one hand, these are currently the most powerful asset solutions on the Internet Computer. On the other hand, it makes sense to use the same technology for both, as this allows one to inherit the improvements made for the other.

That is why these related features have been extracted to two new crates, junobuild-collections and junobuild-storage.

Wasm Memory Limit

Based on our experience and developer feedback, we have observed that canisters cannot be upgraded once their heap memory exceeds 1 GB. Consequently, both the CLI and Console UI issue warnings when this threshold is approached. To enforce this limit, any new Mission Control, Satellite, or Orbiter (analytics) will now be created with a 1 GB Wasm memory limit.

Console (Frontend)

The console UI/UX has been improved as follows:

Features

Detach Orbiter and Satellite, i.e., remove those segments from the list of managed projects in your Mission Control.
Upload assets in the Storage, which is useful to update or edit assets manually.
New Chinese translations thanks to @bytesun.
Redo the classic rounded spinner.
Make the call to action to clear collections more comprehensive.

Style

Fix glitchy title appearance.
Remove the illustration on the dashboard.

Fix

Logo in navigation always points to home.

Satellite

The Satellites have been updated as follows:

Features

Prevent using reserved system keywords when creating new collections.
Storage and collections features extracted to new crates junobuild-collections and junobuild-storage.

Fix

Storage asset owner should not be updated on asset overwrite.

Build

Bump DFINITY Rust libraries.

Mission Control

The Mission Control have been updated as follows:

Features

Add set_satellite and unset_satellite to support features to attach or detach Satellites.
Implement unset_orbiter to allow developers to detach Orbiter (note that attaching was already available).

Build

Bump DFINITY Rust libraries.

Orbiter

No changes.