Now would be a great time for the XMTP SDK’s and node software to support the Ed25519 signature scheme and BLAKE2b hashing algorithm used by Sui.
As you will be aware Ed25519 will allow for faster signing and verification, bringing XMTP into the era of faster Web3 apps that are aiming for ‘the ease of Web2’.
Note that Ed25519 and Blake2b are robust choices which can protect against various attacks such Side-Channel Attacks (Timing Attacks, Power Analysis Attacks), Collision Attacks and others. Note that adding Ed25519 will not only enable Sui but also other chains that use Ed25519.
As a team who is building multiple apps on Sui we will use this integration if it can be implemented within the next 6 months. We expect our apps to pull others into the ecosystem as well.
Thanks for posting, @Sandesh_Pokhrel! We have seen a lot of interest in ED25519 support, and it’s a no brainer that we’ll add support at some point. Some preliminary work has already happened in our libraries, but it has to do with MLS installation keys rather than wallet keys.
The multi-wallet work in XIP-46 is also a step towards this kind of thing.
In the short term, finishing up the Group Chat feature and getting our 1:1 chat moved over to the same MLS foundations will require everyone on our team. That said, we’re open source for a reason and we’d love to work with anyone willing to contribute time/ideas/effort to making this happen faster!
Hello @Sandesh_Pokhrel - thank you for this incredible offer to contribute open source work to enable XMTP to support Ed25519 and BLAKE2b support!
Also, thank you for these meaningful questions - let’s get them answered!
@Brian_Covey - might you be able to help Sandesh and team get answers to their questions, please?
Once we have answers to these questions and if the MECHA DAO LLC team decides to proceed with contributing open source work, we can start with an XIP draft to articulate the work to be done.
Is the codebase already in suitable shape for us to do this, or would we need to wait for you to finish the work you are doing on the core library?
I don’t think there is anything strictly blocking progress for ed25519 support. Although with all the group chat + other features being actively worked on, all the churn in the codebase could make the implementation stage (assuming you started right now) more difficult then it otherwise would be
Knowing your codebase, how much work do you estimate will be required?
Here’s a short run down of what this would entail:
The address item identifying a blockchain identity is stored generically as a String, this means we don’t have many requirements for what an address is. Could store whatever blockchain-specific address you want in there. Further, our identity system is mostly generic across Signature types via the Signature trait.
Most of the work for implementing Ed25519, at least as far as the xmtp_id crate goes would probably just be implementing Ed25519 for the Signature trait. You could look at how its done for RecoverableEcdsaSignature as an example. The trickiest part might be handling signature recovery for ed25519. Not sure if that’s strictly supported in ed25519 libraries. Therefore ed25519 impl might require some finagling there to make it work with everything else.
This would be the first step, and at the very least allow associating an ed25519 key with an existing identity. Definitely would require testing to make sure things work as expected. Most of the implementation would go into the xmtp_id crate.
Hey @AndrewPlazaXMTP, got it.
I’ve socialized it with the team, I’m going to make a start, it won’t be my full focus for a few weeks, this will let time pass so that the XMTP code base is getting closer, then I’ll pull in an experienced rust guy and we will get this done as a team of two. How does that sound? Could you please let us know any time estimates you have on the XMTP core library progress. I’ll ping you from time to time for updates.