Hi,
It’s my first contribution and I have no intiention of disturbing anything , but regarding the structure of the transaction reference, could we consider the Chain Agnostic initiative, aiming to standardise how we identify blockchain-related primitives?
For instance, this specification identifies the blockchain with namespace
and networkId
while the CAIP-2 specifies the chainId
with namespace
(eip155
, etc.) and reference
(1
for Ethereum mainnet, 137
for Polygon PoS mainnet, etc.). So, basically a reference
property instead of networkId
.
Obviously the reference
would clash with this current specification using reference
for the transaction hash.
Unfortunately, there is no CAIP specification (yet) for a transaction reference (it can be submitted to their proposal though).
We can think of something like this:
type TransactionReference = {
/**
* Identify the blockchain in a CAIP-compliant way
*/
chainId: { // This structured object is what the caip js library uses
namespace: string;
reference: string;
};
// alternatively
chainId: string; // The actual CAIP-2 syntax <namesapce>:<reference> (eip155:1) but needs to be parsed to be used. Note the caip js library provides utilities for that.
/**
* Lack of CAIP specification for the transaction hash, could be:
*/
reference: string;
// or
transactionHash: string;
// or something else such as txHash, transactionId, etc.
// ...
};
@aurel This is a great suggestion. I’d be open to aligning on standard naming for the chain, and then renaming the existing reference
field to something like transaction_hash
to avoid confusion.
Awesome. Thanks
How wonderful to hear from you, @aurel - thank you for the suggestion and for following up!
@nick - I will revert this XIP to Draft status so we can go ahead and update the XIP to align on standard naming per Aurel’s suggestion.
Thank you for the update to the XIP, @nick! Moving the XIP to Review status now.
Hi there, I’m new to this space but definitely want to get involved more!
I am implementing this feature and noticed that the amount
field is typed as number
.
Should this instead be bigint
?
Thanks!
Welcome to the space, @sonicsmith!
Thank you for taking the time to review this XIP and for your question about the amount
field. cc’ing @nick, a core dev on the project, to provide some guidance here.
Please do keep an eye on this post as another change may be coming through next week.
If helpful, I thought I’d mention the XMTP Dev Community Call. Half the call is dedicated questions from the community and deep dives into XIPs. So if you ever have anything you’d like discuss, it would be great to see you there!
With aloha,
J-Ha
@sonicsmith Just checking back to let you know we’re going to await the return of the XIP author to make a holistic call on this. I will take the action item to loop us all back to your open question upon Ry’s return late Apr/early May. More soon - and thank you again for your partnership on this!
Open item from @aurel about whether this sentence is still necessary.
Open item from @aurel:
Should we make the chainId required?
If not, the behaviour must be documented, for instance, if undefined it defaults to eip155:1
(Ethereum mainnet).
I’d personnally prefer it to be required so that there is (slightly) less cases to manage for builder implementing the specification and, in a chain-agnostic context, there is no preference to a give chain (the default one if undefined)
@aurel and @sonicsmith - just a note here to let you know that we are following up on your questions on this XIP. Thank you for your patience!
@sonicsmith thanks for you comment! yes, bigint
makes more sense for the amount
field. i’ve updated the spec to reflect this.
@aurel thanks for your comment and patience!
for simplicity, i’ve updated the spec to include a mandatory chainId
field that references a blockchain ID according to EIP-155. i’ve also added an optional networkId
for the rare cases where it differs from the chainId
.
i understand this limits transaction references to EVM chains, but that’s also a current limitation of XMTP. in the future, we can consider using CAIP-2
for referencing blockchains.
curious to hear your thoughts on this!
cc @nick