List view
# The vision To have a site hosted which, like Polkadot.js, can be pointed at some node/chain and from that can obtain the metadata and generate API docs for precisely how to interact with that chain using Subxt, with examples and such for working with events, storage, extrinsics, constants and runtime APIs. # The Plan See github.com/paritytech/subxt-explorer for an MVP of this work.
Due by December 31, 2023# The Vision Setting up `Config` is the hardest thing about getting started with Subxt at the moment. Let's do what we can to simplify and automate this. # The plan - Remove params where we can - Support "dynamic" params where we can; ie params that can be inferred from metadata or whatever - Overhaul the `ExtrinsicParams` part of the config to be smarter and more modular so it's easier for people to set them up (and less likely that people will even have to if they prefer not). - This may require V16 metadata to complete; we'll see if any changes are needed in metadata to allow more automated targeting of a chain.
Due by September 30, 2023•3/4 issues closed# The Vision For signing extrinsics, users can currently: - Enable the "substrate-compat" feature to pull in Substrate crates and use these to sign transactions - Hand off a signer payload to some external thing to sign it. I'd like to provide signer logic built-in to Subxt, so that "substrate-compat" is not needed in most cases (reducing number of crates puleld in by ~200 last time I checked). Hopefully this will speed up build times and provide a nice self contained way to experiment with building and signing transactions. # The plan - Support generating keypairs (ideally from phrases too) and basic signing logic in Subxt (possibly behind a feature flag if it ends up pulling in a bunch of deps, and possibly as a `subxt-signing` crate or similar).
Due by September 30, 2023•1/1 issues closed# The Vision Pierre's new RPC API (https://github.com/paritytech/json-rpc-interface-spec/) is currently being implemented. This will allow us to offer a complete and stable RPC interface in Subxt, as opposed to the current one in which a bunch of methods exist to call runtime APIs. Migrating Subxt to using it will help to expose issues with it. I don't think we'll be able to migrate "all of the way" to using it until it's widely distributed in the community and we have a way to generate the runtime APIs people will want to call into, but we want to at least prototype the implementation to help refine the API and ensure that it works for us when the time comes to move to it permanently.
Due by December 30, 2023•1/1 issues closed# The Vision As well as supporting connecting to a single RPC node, we should also support connecting to a network via smoldot. This will allow Subxt to be benefit from much more decentralisation. # The Plan Implement RpcClientT on some wrapper around smoldot, and provide it behind a feature flag like the "jsonrpsee" RpcClient. # Open Questions - Does smoldot support all of the RPC methods we need in Subxt? I think not, but if it's experimental then we can make it available and see what works and what doesn't. Owing to some external experimentation I think we can at least submit transactions now.
Due by August 30, 2023•3/3 issues closed# The Vision One of the aims of Subxt is that you can statically generate code for some pallets you're interested in interacting with, and then connect to any node using those pallets and talk to it. An issue here is that the statically generated code is also statically encoded and decoded based on the shape of the generated structs/enums. This means that things like pallet/call indexes changing across nodes can break things like multisig, batch or sudo calls (which contain some call enum with a fixed pallet/call index). Ideally, we'd like the encoding and decoding to static types to depend not on the shape of those types, but on the metadata describing what types are expected/provided for some call/query. This would add robustness by allowing for more variation in types (it's fine to pass a `u8` when you need a `u64`), make things like nested calls "just work" (encoding enums would be based on matching up variant names and not index), and give more leeway when things change (eg any extra fields in a struct you're trying to encode will be ignored if not needed). # The Plan The plan here is to create `EncodeAsType` and `DecodeAsType` traits which build on `parity_scale_codec::{ Encode, Decode }` and provide an interface which accept a type ID and type registry when trying to encode/decode some type, and: - Implement these traits on all basic types. - Implement these traits on all codegenned types. - Implement on `scale_value::Value`. - add/adapt subxt APIs to make use of these traits.
Due by March 15, 2023# The Vision In conjunction with the milestone to support new Runtime APIs, we're expecting to need to support working with V15 metadata as well as V14. It'll be necessary to support both. As a result of this, let's also make sure that it's that bit easier to support V16, V17 etc as they come out. # The Plan - Hide/remove any references to RuntimeMetadataV14 from the public API. - Add support for V14 or V15 metadata. # Open Questions - Is it worth thinking about how we might be able to support future updates without breaking changes? is that even possible? - Is it worth thinking about how we might support older metadata versions too as we look over this interface?
Due by July 30, 2023# The Vision Subxt can already decode events, constants and storage entries, but it can't decode recent blocks. This feels like a key missing part of the API, so let's add support for this. # The Plan - [x] Create a "block-centric" API for subscribing to blocks and accessing the transactions, events and storage in the block. - [ ] Allow extrinsic bytes to be dynamically decoded into some `Value`s representing call data. - [ ] Allow attempts to statically decode extrinsics into some tuple or struct representing call data? # Open Questions - Can we do anything about block signatures? - How far can we statically vs dynamically decode transactions? I think we'll look to the Events API for inspiration here and probably offer a similar interface. Like Events, we may not have the information we need to be able to decode all transactions (we might know only about a subset of pallets).
Due by June 30, 2023•1/1 issues closed# The Vision We'd like to make Subxt an approachable and obviously well maintained, documented and supported tool to encourage developers to use it. Great docs are key to that. Some examples of such docs that I think we could draw inspiration from: - https://use.ink/ - https://hyper.rs/ - https://serde.rs/ # The Plan - Assess whether we would benefit from a separate "Book" or whether we should focus more on docs.rs documentation. - If we want a book: - Find a tool/approach that works. I'd like any code examples in our docs to be automatically checked by rust. being able to host the docs in the same repo would make it easy for us to develop/test/have them with every release and branch. Let's see what the easiest/best choice of tool is for create such docs is. - Plan out the docs structure. I think it should be very example focused. it should complement and not replace the API docs, so higher level examples and descriptions of the problems and approaches taken. - Talk to the docs people about this; they might be able to help in all areas of this!
Due by May 30, 2023•1/2 issues closed# The Vision A new set of runtime APIs as proposed by Pierre are on their way (see https://github.com/paritytech/json-rpc-interface-spec/ and https://github.com/paritytech/substrate/issues/12071). The longer term plan will be to remove the existing RPCs, and regardless, we are already expecting users to rely on Runtime API calls much more nowadays rather than exposing such things via a new RPC method. Like creating transactions/storage requests/constants, working with Runtime APIs is fiddly and requires knowledge of which methods are available and how to encode calls to them. So, we'd like to be able to also add the APIs needed to safely and easily construct calls to Runtime APIs to subxt. # The Plan - The major blocker is actually adding type definitions for those Runtime APIs into the metadata (which in turn will lead to a V15 metadata being released, which in turn means we want to bundle together other issues people have with metadata into that update to avoid needing to do another update for as long as possible). We need to start the ball rolling to gather and reach consensus on what needs adding/changing. - Once that's in place, we need to update Subxt to support V15 metadata. - Finally, we need to add codegen for Runtime APIs, expose support for them via a new `api.call()` method (or something like that) and support dynamic quering of them, too. # Open Questions - The first step is the hard one; we need to actually reach consensus around adding this stuff to the metadata in the first place. I expect reaching that consensus and agreeing which other changes need to make it in if so, to take the significant majority of the time here.
Due by May 30, 2023•1/1 issues closed# The Vision Being able to compile compiling Subxt to WASM will allow it to be used in more places, and aligns with the notion that WASM is a first class compilation target for Rust. We want people building rust apps on the web to be able to use Subxt seamlessly as a part of those apps. # The Plan - We've already made strides towards this by getting more underlying crates compiling to WASM, including `jsonrpsee` and things like `scale-bits`. Now we just need to focus on the final cases to push it over the line. - We need to add CI tests to ensure that this works and continues to work going forwards. - Ideally we'd also have at least one working example showing Subxt working in a browser via WASM.
Due by December 30, 2022•2/2 issues closed# The Vision Subxt supports runtime things like user submitted parameters to be submitted as transactions and such now. Let's validate and try this out by adding support to the subxt CLI tool to explore a node, and possibly even submit transactions (though I'd treat that as a stretch goal right now). # The Plan - Add new commands to the subxt binary eg `tx`, `storage`, `constants`. - Eg the `tx` commant takes parameters like `subxt tx balances transfer 'Id (12345Db)' 10_000`. - At each step towards building up such a command, the tool should provide information about what the next value can be, and tell you about the thing you've typed so far (eg `subxt tx balances` would list the methods available on the balances pallet and perhaps provide docs for it, and `subxt tx balances transfer` would tell you about the transfer method and the params it needs). # Open Questions - We'll have to experiment to see the exact shape that this will take. `Clap` for instance may make it hard to do it exactly as envisaged above.
Due by September 30, 2023•3/3 issues closed# Testing issue syncing.
Due by April 11, 2023# This is just a test. Description
Due by December 16, 2022Being able to work with dynamic data will land in Subxt soon. One big question though is; if a team wants to submit a transaction or read a storage value using runtime values, what values do they actually need? For example, doing a balance transfer requires a `MultiAddress<AccountId32, _>`, which ultimately means you need to produce a Value like: `Id ( { 1, 2, 3, 4, 5... } )` (ie an `Id` variant containing an unnamed composite with each byte of a 32 byte address. How can people discover what types are needed? A tool that let people query what storage, transactions, events are available and then what parameter types need to be provided for each one would be very useful. (Beyond giving this help, the tool could allow users to submit transactions etc, but one step at a time). The main things: - Given some type ID, produce an example of a Value type that would be compatible with it. - We may want to prettify the printing of such Value types - We may want to simplify the Value types that are produced; removing any 1-value composite types for instance, since encoding will happily skip it. - With this, a CLI tool that can dig into calls/storage and then present examples of the needed parameters, possibly verifying parameters you provide in the process, and possibly returning the call data etc when you provide correct shapes. - We should provide the docs for any given call etc, too. I see this building on the existing `subxt` binary, which we can tidy in the process.
No due dateMy hope is that once dynamic support has been added, we can move to looking at any final API tidyup and make a push for subxt v1. The goal here is to have something in place that we're fairly happy about and don't plan on making any large breaking changes to (but of course we never know).
No due dateBy this release it would be good to have integrated more scale-value where it makes sense Eg APIs for: - building and submitting a transaction using dynamic scale-value values. - getting events back as dynamic values (done already) - decoding storage? It would be nice to have a prototype tool in place that allows offline construction of transactions from Value's + metadata, too. This will help validate that the dynamic stuff works and is useful. See https://github.com/paritytech/subxt/issues/406 for earlier thoughts on all of this.
Due by August 1, 2022•4/4 issues closedIssues we're keen on looking into but not yet sure which milestone they will make it into.
No due dateVarious bits and pieces that have accumulated that would be good to tick off.
No due date•9/9 issues closedPrimarily about improving docs and handling runtime upgrades. A chunk of work which was going to make it into this release ended up in a new crate, `scale-value`. Future releases will see that integrated into subxt.
No due date•5/5 issues closed