In browser Pendulum account

[prayagd]

Problem statement Currently the webApp user cant setup his Pendulum account

User Story

1. As a pendulum webApp user, I should be see all my pendulum assets on the dashboard.
2. Currently the user is able to setup a stellar wallet using the “one click setup”. From now on the user should be able to setup a Pendulum account in the browser itself or he should be able to connect a external browser wallet like polkdot.js or talismann.

Acceptance Criteria The webApp user should be able to create a pendulum account and see the balances on the dashboard.

[ebma]

Just to clarify, what exactly does "setting up a pendulum account" mean? The One-Click setup already creates a Pendulum account (although it is derived from a Stellar keypair) for the user. The pendulum account can also be exported by clicking on the small "0x" toggle that is shown in the text field. Likewise, a Pendulum account can be imported by pasting either a Stellar secret or a substrate seed into the "Stellar secret key" field. Are you expecting a different flow for this? Or maybe we should add more information to the user? To be fair, it's not very clear that you can import/export an account the way I described it.

[ebma]

I made some research on how to use the wallet extensions and found out that it's a bit hard to use ed25519 keypairs with them. Their default scheme is sr25519 but we need ed25519 keypairs because only those are "compatible" with Stellar, i.e. we can derive a Stellar keypair from an ed25519 keypair and vice versa. They don't offer simple creation/import of ed25519 keypairs and this is unlikely to change because they are aiming for consistency. The only way to have an ed25519 in the polkadot.js extension and Talisman is to import the account from a backup file. This backup file can be easily downloaded in polkadot.js from the respective account in the account list overview but we can also easily use that function because there is a keyring.backupAccount() function offered by @polkadot/ui-keyring (more details here).

So I'd say for account creation we can have two flows.

1. (Start with Stellar account)

   • If the user already has a Stellar account, ask the user to input his Stellar keypair.
   • We then derive the Pendulum keypair and tell the user to download the backup file
   • Then we tell the user how to use the backup file to import his Pendulum account into the wallet extension

2. (Start without any account - Similar to One-Click Setup)

   • If the user does not have a Stellar account yet, we generate a Stellar keypair for him
   • Then we show bim the Stellar secret seed and tell him to import it to Solar or something and offer the Pendulum keypair via the backup file
   • Then we tell the user how to use the backup file to import his Pendulum account into the wallet extension

Note: If the user already has some accounts imported in his wallet extension he is very likely not able to use them because as already mentioned, the default for these extensions are sr25519 accounts and we cannot use them for Pendulum.

Maybe it would be easier if we always assume that the user has a wallet extension installed and imported his Pendulum account into that wallet. This would be less confusing and way easier to handle internally because we can always call the signing functions with that wallet instead of having to check if the user locally has some keypair or not. Also, I'd say it's quite common for dapps to assume that there is a wallet extension in place (e.g. MetaMask for most defi apps).

[ashneverdawn]

Hmm, Seems like using ed25519 as native addresses onPendulum is going to be a common issue for us when integrating with the rest of the Dot/Sama ecosystem.

Perhaps it would be easier to go with sr25519 on Pendulum? This would mean we'd need to implement a mapping on Pendulum between the sd25519 and ed25519 adresses. Probably an extrinsic to 'register' the mapping. If they are both generated from the same seed phrase, it could still be seamless for the user.

Seems to me it will be a lot simpler to solve it this way - we only have to solve the conversion for Stellar instead of for every other wallet/parachain out there. Not to mention potentially xcm.

wdyt? @gonzamontiel @TorstenStueber

[gonzamontiel]

Hmm, Seems like using ed25519 as native addresses onPendulum is going to be a common issue for us when integrating with the rest of the Dot/Sama ecosystem.

Indeed, it already was in the past and will be in the future.

Perhaps it would be easier to go with sr25519 on Pendulum? This would mean we'd need to implement a mapping on Pendulum between the sd25519 and ed25519 adresses. Probably an extrinsic to 'register' the mapping. If they are both generated from the same seed phrase, it could still be seamless for the user.

Seems to me it will be a lot simpler to solve it this way - we only have to solve the conversion for Stellar instead of for every other wallet/parachain out there. Not to mention potentially xcm.

wdyt? @gonzamontiel @TorstenStueber

Indeed. I was thinking about the same. ed25519 and sr25519 are the signing systems and what's used for deriving keys, but the seed is exactly the same for both. With this in mind, it's correct if we say that a user with a known seed, is the owner of both the ed25519 and sr25519 accounts? Just with different signing schemes. Considering this, we would need an Address struct or something similar that allows this translation layer, and use it everytime we need to derive a Stellar account from a Pendulum one and viceversa.

[gonzamontiel]

@TorstenStueber this is something we already discussed at the very beginning of Pendulum, and it's becoming more relevant now. If the reasoning above is correct, we should proceed and create a ticket for it.

[TorstenStueber]

My understanding is that Substrate does neither have "ed25519 account id" or "sr25519 account id" but that it is totally agnostic about this. Account ids are just 32 bytes of binary data.

When signing a Substrate transaction (i.e., extrinsic), it is marked whether the signature is meant to be an ed25519 or sr25519 (or ecdsa signature). Only then is the account id interpreted as either an ed25519 public key or as an sr25519 public key.

Of course a wallet will attach more meaning to account ids as they are either created as public ed25519 keys or as public sr25119 keys (each time generated from some secret seed).

If we need to use sr25519 key pairs, then we can either

• always derive both an sr25519 and an ed25519 from the same seed phrase so that every user has two different account ids in Pendulum
• or change the API of our bridge so that an issue always takes a target account id (on Pendulum) as an extra argument, i.e., we never assume that a user wants to move tokens from a Stellar address to the same Pendulum address but to any configurable Pendulum address instead.

What do you think?

[TorstenStueber]

Anyway, I think that this ticket here is totally unrelated to es25519 vs sr25519 key pair issues.

[gonzamontiel]

Hey. For the sake of the thread.

If we need to use sr25519 key pairs, then we can either

always derive both an sr25519 and an ed25519 from the same seed phrase so that every user has two different account ids in Pendulum or change the API of our bridge so that an issue always takes a target account id (on Pendulum) as an extra argument, i.e., we never assume that a user wants to move tokens from a Stellar address to the same Pendulum address but to any configurable Pendulum address instead.

We had some discussions regarding this and agreed in your second approach. It is the most intuitive way that the user specifies an address to bridge to, in both ways (stellar <-> pendulum). This will unblock this ticket. I created a preliminary ticket on the Spacewalk repo to achieve this, but is low priority by now.

Besides that, this issue needs a more precise specification, @prayagd since we have some time here, can you precisely describe what flow would you expect, provide mockups, etc?

[prayagd]

Closing. This is not relevant anymore as we completed SBP-M2.