Full custom definition support

[mvadari]

It'd be much easier to use the same library with different sidechains that support different features, since it affects serialization and signing capabilities.

Some work already done on this front:

• feat: modifiable definitions.json values at runtime via encode/decode parameter #2127
• feat(xrpl): custom definitions support #2683

The only remaining step is to add support for the server_definitions RPC method - to call it on connection and store/use it if it is different than the stored file.

[mvadari]

One other thought: we could potentially shrink the binary codec significantly with the complete removal of the definitions.json file entirely, relying entirely on the server_definitions RPC. This may not be worth it due to the corresponding reduction in ease-of-use.

[ckeshava]

@mvadari Yes, I agree with you. Regarding removing the definitions.json file entirely: we will need to perform an RPC call once to fetch the server_definitions output and then use it to perform all forms of serialization/de-serialization right?

I suspect the initial latency might be high (due to fetching the server_definitions), but subsequent operations should be fast.

Are there any other concerns? I believe there are many rippled servers that provide a public-API

[dangell7]

The issue with this is that in this repo we have models and validation. So we could use the binary codec and not use the transaction model however i think this results in errors when signing so you end up doing a lot of @ts-ignore.

Also requests sorta break this from a sidechain issue as we also have requests and objects that need to be parsed specifically for that chain.

If you really wanted to make this an agnostic repo, exporting the transactions, with their required/optional values could help you build a custom model but I dont think typescript can do this runtime, but maybe an automated github task to create different models for different sidechains. I actually tree shook the models here if you're interested in what that would look like. We can actually use these models in the xrpl-accountlib library for those who like to keep everything typed.

[mvadari]

The issue with this is that in this repo we have models and validation. So we could use the binary codec and not use the transaction model however i think this results in errors when signing so you end up doing a lot of @ts-ignore.

If you're strictly only using the binary codec you should be fine, because the binary codec doesn't use those models. If that's not true, then that's a (minor) bug.

Also requests sorta break this from a sidechain issue as we also have requests and objects that need to be parsed specifically for that chain.

We can't solve all the problems, lol. But maybe that can be mostly resolved via @ts-ignore, or perhaps there can be some sort of support for custom requests.

If you really wanted to make this an agnostic repo, exporting the transactions, with their required/optional values could help you build a custom model but I dont think typescript can do this runtime, but maybe an automated github task to create different models for different sidechains. I actually tree shook the models here if you're interested in what that would look like. We can actually use these models in the xrpl-accountlib library for those who like to keep everything typed.

There's been some previous discussion about tree-shaking (see #2307 for example), but I think it hasn't been high priority so far.

[tequdev]

Definitions support for client.submit() and client.submitAndWait() is also required. (internally, getSignedTx() and isSigned())