Pre-RFC: XMS language (XCM Made Simple) about rfcs

[bkchr]

I'm all into making XCM better approachable. However, I don't think that using XML is that much of a better idea here. Maybe just having nice abstractions in different languages for building XCM programs is the better way for now.

[kianenigma]

I would be curious to see the Rust equivalent of the program you have above, and a couple of other programs, and demonstrate how this will simplify it? First glance, I feel like it would be more or less equally complicated.

[shawntabrizi]

What would be the action item for this RFC? How would this ultimately effect the polkadot-sdk code base?

[xlc]

If the goal is to construct XCM from more programming languages, an alternative approach will be SDK generation from the Rust defs. As we have type metadata available, it is not hard to generate SDK for other languages such as JS/Python/Solidity, or even XCM/JSON schema.

[olanod]

If the goal is to construct XCM from more programming languages, an alternative approach will be SDK generation from the Rust defs. As we have type metadata available, it is not hard to generate SDK for other languages such as JS/Python/Solidity, or even XCM/JSON schema.

Yeah one of the main goals is to construct XCM and complex extrinsics from more programming languages in a simple declarative way as XCM instructions lend themselves pretty well to be written that way instead of an imperative approach(Alberto didn't enjoy making the Moonbeam JS examples), specially being able to write the instructions from the many client-side languages that interact with the chains. Sube a very lightweight/simple Rust client designed for embedded devices would be the first XMS "interpreter", it currently has experimental JS bindings with planned support for Python/Kotlin/Swift.

It's also a goal to steer away from writing XCM with Rust. we should pivot it to focus things on the client side, most developers are NOT Rust developers and they are the ones that can bring the use cases for the format. With pallet XCM's send/execute we have most of the tools we need on the chain side, instead of writing more wrapper pallets I'd like to see a vibrant ecosystem of (client-side)developers sharing XCM abstractions in a language agnostic way. The idea of generating SDKs form Rust code is good and a step forward over having to replicate the same work in different languages but I think we(Rust devs) don't know yet what abstractions we need, let the users figure that out after lots of easy experimentation.

import xms from 'https://dot.tools/xms.js'
// imagining a curious JS user importing some well known script
await xms.import("https://acala.dev/xcm/x-tokens.xms")
// she can experiment with ad-hoc scripts
await xms.load(xms`
import 'https://dot.tools/xcm/std.xms'
def "me" "0x1234567890"
def "half-my-money" {
    query "/polkadot/system/account/{me} | get data.free | {in} / 2"
}
`)

await xms('half-my-money | x-transfer /polkadot/${in} ./:2000')

[olanod]

I would be curious to see the Rust equivalent of the program you have above, and a couple of other programs, and demonstrate how this will simplify it? First glance, I feel like it would be more or less equally complicated.

The JS code in Moonbeam's example is already more complicated I can imagine the Rust code won't be much different?

What would be the action item for this RFC? How would this ultimately effect the polkadot-sdk code base?

I'll work a bit more on the ergonomics of the format, decide on a minimal set of "reserved keywords"(e.g. a speciall def node used to construct everything else?) and try to come up with a "standard library" that would just be common definitions that expand into the usual verbose JSON-like representation we usually use when serializing Rust types. A PoC with working examples would also be good for getting a feeling about the language, based on the feedback during the call, I'd consider the experiment failed if it doesn't prove to be simple enough to use and learn.
I'm not sure If I understand the polkadot-sdk concern part, for now it doesn't have any impact? eventually we could add the xms crate in the repo and have it come with tools like the interpreter, code generators or keep the "official" collection of xms scripts that can be published on IPFS or a static web server. It can also be kept independent just like polkadot.js or smoldot are not part of the official repo but still fall under the umbrella of the fellowship.

[shawntabrizi]

I guess the reason why I ask about the impact on the Polkadot SDK is due to what I envision these RFCs to be about.

And I could totally be wrong here, so happy to have a more meta conversation and realign my thinking, but...

It seems this repo, and the Polkadot fellowship are about making decisions around the core protocols of Polkadot and the Polkadot SDK.

Your initiative and goals here are cool, but seem to be something external from Polkadot and the Polkadot SDK. For example, the creation of XMS would not prohibit the creation of any number of other external declarative languages to wrap XCM. There is no reason that I see so far why this meta-language needs to be enshrined into a Polkadot RFC.

Since this proposal does not actually seem to have any effect to the Polkadot Protocol or the Polkadot SDK (which contains the XCM crates), then there really isn't any need for this fellowship to approve or deny this RFC.

It seems instead, this is just a way to communicate ideas and get feedback, which is great in its own right, but probably not the intention of RFCs process.

Does this resonate with anyone else? Am I in the wrong mindset?

Perhaps we need a separate repo, or section in the Polkadot Forum, which is more like "talk with and get feedback from the fellows".

---

All this being said, I do resonate with your goals, and I think that the experimentation of things like this is valuable and should be supported.

[KiChjang]

To write XCM and send it over the wire, all you need is to have a SCALE codec in your programming language, and create structs/classes/types that have the same SCALE encoding. An entirely new language is not required at all.

In fact, this really sounds like it should be an OpenGov proposal to develop SCALE codec libraries and primitive XCM types for other programming languages. I struggle to find any sort of action item for the fellowship here in this proposal.