v0.4.0

This release brings some breaking changes to the message payload formats, migrating to CAIP-2 identifiers everywhere, and some major networking upgrades!

What's new

• Specs now declare exactly which chains they support using an export const chains: string[] export.
  • If one isn't declared, it defaults to ["eip155:1"] (Ethereum mainnet only).
  • Applying a message will throw an error if the message is signed for a chain not declared in the chains array.
  • You must provide a chain implementation for every chain declared in the spec to Core.initialize.
• Ethereum session signatures now use SIWE instead of EIP-712. This should be transparent to users, but is a breaking change to the signature generation and verification.
  • The subject URI of the SIWE message is ethereum:${sessionAddress}.
  • The ipfs://Qm... URI of the app is given as the only resource URI.
  • Ethereum session signatures are now a 3-tuple string format ${domain}/${nonce}/${signatureBytes} so that the SIWE message text can be deterministically reconstructed by verifiers.
• major libp2p upgrades resulting in faster peer discovery times and more reliable connections. Many thanks to the libp2p team for responding quickly to some bugs we found!
• More organized and colorful logging :)

Breaking changes

• appName has been removed from specs and message payloads.
• chain and chainId in action and session payloads have been consolidated into a single CAIP-2 chain identifier chain: string. CAIP is a great project dedicated to solving cross-chain identifier formats better than we could have.
  • Before: { chain: "ethereum", chainId: "1", ... }
  • After: { chain: "eip155:1", ... }
• As a result, the constructor signature of the chain implementation classes have all changed.
  • EthereumChainImplementation is now constructor(chainId: number, domain: string)
  • SubstrateChainImplementation and SolanaChainImplementation are both constructor(genesisHash: string)
  • CosmosChainImplementation is now constructor(chainId: string, bech32Prefix: string)

Upgrade guide

The user-facing changes in this release are

• Update the constructor of your chain implementations. For example, if you're creating a EthereumChainImplementation, you have to pass it a number instead of a string.
• A new way to pass Ethereum RPC URLs to the CLI
  • Before: --chain-rpc ethereum 1 http://...
  • After: --chain eip155:1=http://...
• There are changes to the ApplicationData object returned from the root HTTP route.
  • chains is now string[] instead of Record<string, string[]>.
• Multi-chain apps now have to declare their specific set of supported chains using the export const chains = [ ... ] export with CAIP-2 identifiers.

v0.3.0

This release lands support for running Canvas apps entirely in the browser, along with improvements to the underlying libp2p networking stack!

What's New

• @canvas-js/core can be bundled and imported from the browser. Browser cores use IndexedDB for persisting messages, and an in-memory WASM SQLite database for the model store. You can provide a core: Core instance directly to the <Canvas /> element instead of a host API URL, and use the rest of the hooks exactly the same way. See the example in examples/chat-browser!
• Upgrade to libp2p v0.43.0 with the new Circuit Relay v2 implementation

Breaking Changes

• The --listen CLI argument is now a string /ws multiaddr, not a port number. This makes it possible to control the network interface in addition to the port.
• The WebSocket API has been redesigned as a more minimal server-to-client event stream.
• The ApplicationData interface has been updated to include peering and merkle root metadata.

v0.2.2

What's Changed

• Added a GET /messages API endpoint, disabled by default
• Added a top-level validateSpec(string: string): Promise<{ valid: boolean; warnings: string[]; errors: string[] }> method

Full Changelog: v0.2.1...v0.2.2

v0.2.1

What's Changed

• Better connection and stream event logging
• Fixed a bug in MST sync where streams to empty sources were reset instead of closed

Full Changelog: v0.2.0...v0.2.1

v0.2.0

What's Changed

• Preliminary support for custom actions!
• Core.applyAction and Core.applySession have been replaced with Core.apply, which can be called with either sessions, actions, or custom actions.
• Upgraded QuickJS to add native BigInt support within contracts.
• The libp2p node has been moved inside the Core class. Each app now runs its own libp2p node, with its own persistent PeerId.
• The RPC protocol no longer depends on communicating the types of messages, and just references them by hash. The libp2p protocol string has been upgraded from /x/canvas/sync/v1/{cid}to /x/canvas/sync/v2/{cid}.
• The canvas daemon, canvas start, and canvas stop CLI commands have been removed.
• The @canvas-js/next package has been deprecated.

Full Changelog: v0.1.3...v0.2.0

v0.1.3

• Update to latest @canvas-js/node-okra

v0.1.2

• Fix an issue where the useRoute() hook would not update if a parameter to the route was updated.

v0.1.1

v0.1 is the first release candidate for Canvas, and reflects a basic level of stability that makes it possible to build chat, social, and other interactive applications, that sync and persist without blockchain consensus.

• CLI: Deploy single-page apps using the canvas run command to serve an API. Use the --static flag to serve an included frontend.
• React Hooks: We include React hooks for interacting with Canvas applications from the frontend. The hooks currently support Ethereum-compatible chains only, and can optionally be used with wagmi, ConnectKit, and/or RainbowKit.
• On-chain integration: Read from on-chain using contract hooks.
• Upgradeability: Contracts can be upgraded by using sources.
• Examples: We include example Canvas applications in Webpack and Next.js, which deploy to Fly.io.