Support AENSPointee from Ceres

[davidyuk]

As I understood from https://github.com/aeternity/aeternity/pull/4056 there has been added a new variant to

https://github.com/aeternity/aepp-calldata-js/blob/410effa3c6ded41baaf2ea18619c5af4a982cf6d/src/FateTypes.js#L172-L181

If I'm trying to pass AENSPointee to contract call using the current version of calldata on Ceres if fails with bad_pointer, I assume it is because mismatch of variants size.

Calldata needs to support both Iris and Ceres (the same as js sdk) to allow smooth migration.

[davidyuk]

Actually, sdk can depend on an old and new version of calldata, so it doesn't need to support both.

[marc0olo]

@dincho any plans to tackle this? would be helpful for my grant project where I would like to prepare a migration to a contract with new features.

[marc0olo]

actually I am wondering if there are any other types that need to be introduced due to Ceres 🤔

Chain.network_id probably: https://github.com/aeternity/aeternity/blob/master/docs/release-notes/next-ceres/fate_extensions.md

[dincho]

Yes, I'll spend some time on this lib this week

[marc0olo]

@dincho any chance to get this done in the near future? 🙏

[marc0olo]

btw the description should maybe be updated, e.g. "support AENSv2 types"

[davidyuk]

Calldata needs to support both Iris and Ceres

This seems to be easy because AENS changes look backward compatible.

The current implementation allows adding raw data, does it make sense to limit to a string on calldata side? (to ease usability)

[dincho]

The current implementation allows adding raw data, does it make sense to limit to a string on calldata side?

I don't think so if the protocol allows it, this lib should support it