Closed thiendangvan closed 6 months ago
We have received your issue, we will think about it and get back to you
We have received your issue, we will think about it and get back to you
thank you
@thiendangvan We currently support scan QR code login, which provides a way to "link wallet" between different devices(for example, when you finish the login process on device A, you can use the scan page to scan the QR code provided by device B, and approve it to login. After that, device B will enter the set pin page). However, the core wallet info will remain on those devices, only those devices can deal with our service. It is still unknown which way you would like the "link wallet" process to be, which of the following way you would prefer? Please inform us: A: the process above B: after you finish login on device B(by your own account service), the service can control the device A and send a message. If the user open the APP on device A and approve it, the device B will be able to login the web3 wallet. In this case, we will provide the logic API in the scan QR code scene to help you to deal with it. C: after web3 wallet is created, you can collect particular wallet information in our SDK, and we will provide some Java backend APIs that can create a new wallet information just like the scan QR code process, but this time you won't need the device A to approve it. After that, you can provide the new wallet information to device B. D: after web3 wallet is created, your server process it to the device B and make them to use the same identity. It is not recommended, and each of them can drop it by exitWallet(), then the other will find it denied by the wallet contract.
@thiendangvan Hi, is there any update on this issue? =)
@thiendangvan Hi, is there any update on this issue? =)
hi sorry for the late response, i'm discussing it with our team and will get back to you soon
@thiendangvan We currently support scan QR code login, which provides a way to "link wallet" between different devices(for example, when you finish the login process on device A, you can use the scan page to scan the QR code provided by device B, and approve it to login. After that, device B will enter the set pin page). However, the core wallet info will remain on those devices, only those devices can deal with our service. It is still unknown which way you would like the "link wallet" process to be, which of the following way you would prefer? Please inform us: A: the process above B: after you finish login on device B(by your own account service), the service can control the device A and send a message. If the user open the APP on device A and approve it, the device B will be able to login the web3 wallet. In this case, we will provide the logic API in the scan QR code scene to help you to deal with it. C: after web3 wallet is created, you can collect particular wallet information in our SDK, and we will provide some Java backend APIs that can create a new wallet information just like the scan QR code process, but this time you won't need the device A to approve it. After that, you can provide the new wallet information to device B. D: after web3 wallet is created, your server process it to the device B and make them to use the same identity. It is not recommended, and each of them can drop it by exitWallet(), then the other will find it denied by the wallet contract.
hi @carbon-portkey, about the option C, "after web3 wallet is created" means after the user registers a wallet account right?
"after web3 wallet is created" means after the user registers a wallet account
Hi, @thiendangvan Yeah! "after web3 wallet is created" means after the user registers a wallet account on Device A
"after web3 wallet is created" means after the user registers a wallet account
Hi, @thiendangvan Yeah! "after web3 wallet is created" means after the user registers a wallet account on Device A
Hi @FrankFeng1116, we would like to know more elaboration on option C? how it works? could you help to describe more info? thanks
@thiendangvan We currently support scan QR code login, which provides a way to "link wallet" between different devices(for example, when you finish the login process on device A, you can use the scan page to scan the QR code provided by device B, and approve it to login. After that, device B will enter the set pin page). However, the core wallet info will remain on those devices, only those devices can deal with our service. It is still unknown which way you would like the "link wallet" process to be, which of the following way you would prefer? Please inform us: A: the process above B: after you finish login on device B(by your own account service), the service can control the device A and send a message. If the user open the APP on device A and approve it, the device B will be able to login the web3 wallet. In this case, we will provide the logic API in the scan QR code scene to help you to deal with it. C: after web3 wallet is created, you can collect particular wallet information in our SDK, and we will provide some Java backend APIs that can create a new wallet information just like the scan QR code process, but this time you won't need the device A to approve it. After that, you can provide the new wallet information to device B. D: after web3 wallet is created, your server process it to the device B and make them to use the same identity. It is not recommended, and each of them can drop it by exitWallet(), then the other will find it denied by the wallet contract.
hi @carbon-portkey , @FrankFeng1116 the "link wallet" means that a user already has an account on our system, and then they connect their account to a Wallet. after connecting successfully they can use that wallet on different devices. so is it feasible to do it?
@thiendangvan We currently support scan QR code login, which provides a way to "link wallet" between different devices(for example, when you finish the login process on device A, you can use the scan page to scan the QR code provided by device B, and approve it to login. After that, device B will enter the set pin page). However, the core wallet info will remain on those devices, only those devices can deal with our service. It is still unknown which way you would like the "link wallet" process to be, which of the following way you would prefer? Please inform us: A: the process above B: after you finish login on device B(by your own account service), the service can control the device A and send a message. If the user open the APP on device A and approve it, the device B will be able to login the web3 wallet. In this case, we will provide the logic API in the scan QR code scene to help you to deal with it. C: after web3 wallet is created, you can collect particular wallet information in our SDK, and we will provide some Java backend APIs that can create a new wallet information just like the scan QR code process, but this time you won't need the device A to approve it. After that, you can provide the new wallet information to device B. D: after web3 wallet is created, your server process it to the device B and make them to use the same identity. It is not recommended, and each of them can drop it by exitWallet(), then the other will find it denied by the wallet contract.
hi @carbon-portkey , @FrankFeng1116 the "link wallet" means that a user already has an account on our system, and then they connect their account to a Wallet. after connecting successfully they can use that wallet on different devices. so is it feasible to do it?
@thiendangvan Hi, currently our SDK is designed for end-to-end encryption scene, it means that all the sensitive storage data will be stored inside the device hardware, and will be unlocked when necessary. In that case, "link wallet" is actually an approval for other devices to create a new web3 wallet that have the permission to control user's unique identity on chain. So the way you described differs slightly from our design. We might need some time to discuss this idea, then we will reply to you 🙏
@thiendangvan Hi, currently our SDK is designed for end-to-end encryption scene, it means that all the sensitive storage data will be stored inside the device hardware, and will be unlocked when necessary. In that case, "link wallet" is actually an approval for other devices to create a new web3 wallet that have the permission to control user's unique identity on chain. So the way you described differs slightly from our design. We might need some time to discuss this idea, then we will reply to you 🙏
i see i see, take your time
hi @carbon-portkey @FrankFeng1116, i noticed that if i log in the same wallet on 2 devices i will receive 2 different wallet addresses after login successfully, could you explain the reason for that? is it related to the "end-to-end encryption"? thanks
@thiendangvan OK, our SDK service is based on CA wallet service, which is different form the concept of EOA wallet. So when you create a wallet on the devices, you are actually claiming that the wallet info you created on your particular device can be related to your "contract wallet" during the login process. It's similar to the cryptocurrency exchange services like binance, okx, etc. If you have some btc and want to exchange, the exchange services will provide an address for you to send a transaction, and that address can be called the "contract wallet", although you don't have the access to that address, the exchange services will provide you the right to control the same quantity of your btc assets that you have sent. Portkey wallet services is based on the same function. When you create your identity by signing up the first time, our Portkey CA contract will create a contract wallet identity(A) on the block chain, and the SDK will bind a generated wallet address(B) to it. Then next time if you wish to login on the other devices by scan QR code which we claimed as create wallet C, you are actually use the right that was given to the wallet B by the CA contract to bind wallet C to A. So all the process can be done on those devices, rather to store those sensitive data like private key to some place like servers. If you have other questions, please inform us and we will reply to you quickly =)
@thiendangvan OK, our SDK service is based on CA wallet service, which is different form the concept of EOA wallet. So when you create a wallet on the devices, you are actually claiming that the wallet info you created on your particular device can be related to your "contract wallet" during the login process. It's similar to the cryptocurrency exchange services like binance, okx, etc. If you have some btc and want to exchange, the exchange services will provide an address for you to send a transaction, and that address can be called the "contract wallet", although you don't have the access to that address, the exchange services will provide you the right to control the same quantity of your btc assets that you have sent. Portkey wallet services is based on the same function. When you create your identity by signing up the first time, our Portkey CA contract will create a contract wallet identity(A) on the block chain, and the SDK will bind a generated wallet address(B) to it. Then next time if you wish to login on the other devices by scan QR code which we claimed as create wallet C, you are actually use the right that was given to the wallet B by the CA contract to bind wallet C to A. So all the process can be done on those devices, rather to store those sensitive data like private key to some place like servers. If you have other questions, please inform us and we will reply to you quickly =)
thank @carbon-portkey, so if user log in on other devices by email/phone number, ..etc (same wallet account), it will create a new wallet address to use A? pls correct me
hi @carbon-portkey, I've tried to login to the same Portkey account on 2 devices and got the below response. may I ask what "caInfo.caAddress" is?
hi @carbon-portkey, I've tried to login to the same Portkey account on 2 devices and got the below response. may I ask what "caInfo.caAddress" is?
@thiendangvan Sorry we have been busy those days 🙏 The CaInfo is the personal identity related to your account on chain, and the CaInfo.CaAddress is an virtual address on the contract. When you or the other people send your assets to this address, the Portkey contract will give any generated addresses that are related to it the right to control those assets. It's how the CA wallet works. The assets are not stored to the generated wallets because when you lost control of them( whether it is lost or deleted, or even stolen), those assets will be gone forever. The contract gives you the CaAddress, and when you find a way to regenerate wallets and attached them to your CA Wallet(CaAddress), you will regain the right to control your assets. Hope this will help you =)
hi @carbon-portkey, I've tried to login to the same Portkey account on 2 devices and got the below response. may I ask what "caInfo.caAddress" is?
@thiendangvan Sorry we have been busy those days 🙏 The CaInfo is the personal identity related to your account on chain, and the CaInfo.CaAddress is an virtual address on the contract. When you or the other people send your assets to this address, the Portkey contract will give any generated addresses that are related to it the right to control those assets. It's how the CA wallet works. The assets are not stored to the generated wallets because when you lost control of them( whether it is lost or deleted, or even stolen), those assets will be gone forever. The contract gives you the CaAddress, and when you find a way to regenerate wallets and attached them to your CA Wallet(CaAddress), you will regain the right to control your assets. Hope this will help you =)
thank you very much @carbon-portkey for your information
hi @carbon-portkey, may i ask if the generated addresses can last forever on the user device unless we call the exitWallet() method?
hi @carbon-portkey, may i ask if the generated addresses can last forever on the user device unless we call the exitWallet() method?
@thiendangvan Yes, it is what you thought. And exitWallet() will unbind them.
hi @carbon-portkey, may i ask if the generated addresses can last forever on the user device unless we call the exitWallet() method?
@thiendangvan Yes, it is what you thought. And exitWallet() will unbind them.
got it, thank you @carbon-portkey
hi @carbon-portkey, I've tried to login to the same Portkey account on 2 devices and got the below response. may I ask what "caInfo.caAddress" is?
@thiendangvan Sorry we have been busy those days 🙏 The CaInfo is the personal identity related to your account on chain, and the CaInfo.CaAddress is an virtual address on the contract. When you or the other people send your assets to this address, the Portkey contract will give any generated addresses that are related to it the right to control those assets. It's how the CA wallet works. The assets are not stored to the generated wallets because when you lost control of them( whether it is lost or deleted, or even stolen), those assets will be gone forever. The contract gives you the CaAddress, and when you find a way to regenerate wallets and attached them to your CA Wallet(CaAddress), you will regain the right to control your assets. Hope this will help you =)
hi @carbon-portkey, i wanna ask if the caAddress can receive assets even if its generated addresses are locked? i mean when a generated address is locked, can we send assets to it?
hi @carbon-portkey, I've tried to login to the same Portkey account on 2 devices and got the below response. may I ask what "caInfo.caAddress" is?
@thiendangvan Sorry we have been busy those days 🙏 The CaInfo is the personal identity related to your account on chain, and the CaInfo.CaAddress is an virtual address on the contract. When you or the other people send your assets to this address, the Portkey contract will give any generated addresses that are related to it the right to control those assets. It's how the CA wallet works. The assets are not stored to the generated wallets because when you lost control of them( whether it is lost or deleted, or even stolen), those assets will be gone forever. The contract gives you the CaAddress, and when you find a way to regenerate wallets and attached them to your CA Wallet(CaAddress), you will regain the right to control your assets. Hope this will help you =)
hi @carbon-portkey, i wanna ask if the caAddress can receive assets even if its generated addresses are locked or unlocked? i mean when a generated address is locked, can we send assets to it?
@thiendangvan There's no status called locked for an address on chain, I guess you are saying the locked status of our SDK, right? That status will not affect the CaAddress, it only means using the sensitive data like private key are encrypted and needs to be unlocked by pin code =)
hi @carbon-portkey, I've tried to login to the same Portkey account on 2 devices and got the below response. may I ask what "caInfo.caAddress" is?
@thiendangvan Sorry we have been busy those days 🙏 The CaInfo is the personal identity related to your account on chain, and the CaInfo.CaAddress is an virtual address on the contract. When you or the other people send your assets to this address, the Portkey contract will give any generated addresses that are related to it the right to control those assets. It's how the CA wallet works. The assets are not stored to the generated wallets because when you lost control of them( whether it is lost or deleted, or even stolen), those assets will be gone forever. The contract gives you the CaAddress, and when you find a way to regenerate wallets and attached them to your CA Wallet(CaAddress), you will regain the right to control your assets. Hope this will help you =)
hi @carbon-portkey, i wanna ask if the caAddress can receive assets even if its generated addresses are locked or unlocked? i mean when a generated address is locked, can we send assets to it?
@thiendangvan There's no status called locked for an address on chain, I guess you are saying the locked status of our SDK, right? That status will not affect the CaAddress, it only means using the sensitive data like private key are encrypted and needs to be unlocked by pin code =)
ah i see i see. thank you so much @carbon-portkey
hi @thiendangvan , for this issue, we are in the process of sorting out the technical solution and discussing it internally, and will notify you when the solution is finalized.
hi @wade-portkey, we greatly appreciate for your team's support, we accept the current behavior to save time and we've sorted out a handling for this issue. Please close this issue, thank you so much!!!
hi, @thiendangvan , I would like to know how you are handling this. The user need to connect to the wallet again when logging in on another device, right?
There is another thing to communicate with you: our SDK needs to upgrade to V2 version, this upgrade is the underlying contract account upgrade, the previous portkey account will no longer be valid on the upgraded SDK, so must use the new account on the upgraded SDK. We recommend you to use our upgraded SDK, the new SDK is not yet released, considering your product development progress, we will release the new SDK as soon as possible.
hi @wade-portkey
hi, @thiendangvan , I would like to know how you are handling this. The user need to connect to the wallet again when logging in on another device, right?
-> We allow users to connect to multiple Portkey wallets, so users need to connect to the wallet again when logging in on another device
There is another thing to communicate with you: our SDK needs to upgrade to V2 version, this upgrade is the underlying contract account upgrade, the previous portkey account will no longer be valid on the upgraded SDK, so must use the new account on the upgraded SDK. We recommend you to use our upgraded SDK, the new SDK is not yet released, considering your product development progress, we will release the new SDK as soon as possible.
-> We plan to release our app with Portkey Integration next Thursday (29/2), hope the v2 will be ready soon so we can have time to check. Thanks 🙏🙏
We plan to release our app with Portkey Integration next Thursday (29/2), hope the v2 will be ready soon so we can have time to check. Thanks 🙏🙏
We will release a beta version SDK tomorrow, you can upgrade SDK and test the relevant features; we expect to release the released version on 27/2 or 28/2, you can upgrade it then!
We plan to release our app with Portkey Integration next Thursday (29/2), hope the v2 will be ready soon so we can have time to check. Thanks 🙏🙏
We will release a beta version SDK tomorrow, you can upgrade SDK and test the relevant features; we expect to release the released version on 27/2 or 28/2, you can upgrade it then!
got it, thank you @wade-portkey
hi @wade-portkey , pls let me know when the beta version is ready. thanks
hi @thiendangvan , sorry for not replying in time. we've been busy testing and fixing bugs today, and have just released the beta version 2.0.0-beta.1. This version is not particularly stable yet, and we're still doing further testing and fixing bugs. The released version will be released on 27/02.
hi @thiendangvan , sorry for not replying in time. we've been busy testing and fixing bugs today, and have just released the beta version 2.0.0-beta.1. This version is not particularly stable yet, and we're still doing further testing and fixing bugs. The released version will be released on 27/02.
thanks @wade-portkey, let me check
hi, @thiendangvan, and I'd like to know what features in the SDK you are currently using?
hi, @thiendangvan, and I'd like to know what features in the SDK you are currently using?
hi @wade-portkey, we're using the following features: login, unlockWallet, getWalletState, exitWallet
hi @wade-portkey, i cannot use the unlockWallet() method to unlock a wallet when it is locked, could you help to check? thanks
hi @wade-portkey, i cannot use the unlockWallet() method to unlock a wallet when it is locked, could you help to check? thanks
Sorry, it's our fault. This bug has been fixed, and we published the new version(2.0.0-beta.2), you can try it.
btw, there is an mi
hi @wade-portkey, i cannot use the unlockWallet() method to unlock a wallet when it is locked, could you help to check? thanks
Sorry, it's our fault. This bug has been fixed, and we published the new version(2.0.0-beta.2), you can try it.
thanks @wade-portkey, it's ok now
hi @wade-portkey
hi, @thiendangvan , I would like to know how you are handling this. The user need to connect to the wallet again when logging in on another device, right?
-> We allow users to connect to multiple Portkey wallets, so users need to connect to the wallet again when logging in on another device
There is another thing to communicate with you: our SDK needs to upgrade to V2 version, this upgrade is the underlying contract account upgrade, the previous portkey account will no longer be valid on the upgraded SDK, so must use the new account on the upgraded SDK. We recommend you to use our upgraded SDK, the new SDK is not yet released, considering your product development progress, we will release the new SDK as soon as possible.
-> We plan to release our app with Portkey Integration next Thursday (29/2), hope the v2 will be ready soon so we can have time to check. Thanks 🙏🙏
hi, @thiendangvan , may i ask, has your app been released? i want download it and play with it.
Thanks for your interest in our application @wade-portkey. We have rescheduled the release date. I will let you know when our app is ready
Thanks for your interest in our application @wade-portkey. We have rescheduled the release date. I will let you know when our app is ready
@thiendangvan get it, thanks
hi @wade-portkey, we would like to show the AELF balance on our app so may i ask which method we can use to get the wallet balance?
hi @wade-portkey, we would like to show the AELF balance on our app so may i ask which method we can use to get the wallet balance?
Hey @thiendangvan , you can use the Portkey.getAssetsInfo() method to get all the wallet assets. While there's one more thing to know that all the crypto assets will be shown no matter which chain they lie on. For example, on AELF mainnet there's two different chains - AELF and tDVV, and both of them will be included. you can use the chainId property to separate them apart ~
hi @wade-portkey, we would like to show the AELF balance on our app so may i ask which method we can use to get the wallet balance?
Hey @thiendangvan , you can use the Portkey.getAssetsInfo() method to get all the wallet assets. While there's one more thing to know that all the crypto assets will be shown no matter which chain they lie on. For example, on AELF mainnet there's two different chains - AELF and tDVV, and both of them will be included. you can use the chainId property to separate them apart ~
got it, thanks @carbon-portkey
hi @carbon-portkey, I'm learning about creating Porkey accounts through the Portkey Core SDK, but I'm confused with the parameters of the register function. Could you explain a little about them? https://doc.portkey.finance/docs/QuickStartGuides/BasicGuidesForSDKs/Typescript/register#core-sdk
hi @carbon-portkey, I'm learning about creating Porkey accounts through the Portkey Core SDK, but I'm confused with the parameters of the register function. Could you explain a little about them? https://doc.portkey.finance/docs/QuickStartGuides/BasicGuidesForSDKs/Typescript/register#core-sdk
@thiendangvan This is the API for registering accounts on the chain. Before doing so, you need to complete the Guardian verification activity to obtain Verify Data, such as type, loginGuardianIdentification, verifierId, verificationDoc, and signature. The first and second parameters are the registration type you have selected, such as (type: 'Email', loginGuardianIdentification: ' thiendangvan@gamil.com') The third, fourth, and fifth parameters are the data obtained after the verification activity of Guardian is completed.
hi @carbon-portkey, I'm learning about creating Porkey accounts through the Portkey Core SDK, but I'm confused with the parameters of the register function. Could you explain a little about them? https://doc.portkey.finance/docs/QuickStartGuides/BasicGuidesForSDKs/Typescript/register#core-sdk
@thiendangvan This is the API for registering accounts on the chain. Before doing so, you need to complete the Guardian verification activity to obtain Verify Data, such as type, loginGuardianIdentification, verifierId, verificationDoc, and signature. The first and second parameters are the registration type you have selected, such as (type: 'Email', loginGuardianIdentification: ' thiendangvan@gamil.com') The third, fourth, and fifth parameters are the data obtained after the verification activity of Guardian is completed.
thanks @FrankFeng1116, let me try
hi @FrankFeng1116, may i know if the Core SDK can work on React Native? 🧐
hi @FrankFeng1116, may i know if the Core SDK can work on React Native? 🧐
hi @thiendangvan The core sdk can work on React Native
hi @FrankFeng1116, may i know if the Core SDK can work on React Native? 🧐
hi @thiendangvan The core sdk can work on React Native
I'm trying it in react native, it's quite complicated to handle the login & register flow haha
hi @FrankFeng1116, may i know if the Core SDK can work on React Native? 🧐
hi @thiendangvan The core sdk can work on React Native
I'm trying it in react native, it's quite complicated to handle the login & register flow haha
hi @thiendangvan , may i ask, why are you not using the RN SDK? was there something in the RN SDK that did not meet your requirements?
Hi, we would like to synchronize the connected wallet on multiple devices (link a Portkey wallet to a user account on A device, then on device B we can see the wallet that is connected and can use methods like getinfo, exit wallet, ...). currently when user login to another device they must connect to a wallet again.
I'm thinking that the SDK's login method will return a token and we can store it in DB and use it to log in again on another device. Or we should handle on the Backend (Java) by using the java sdk. Please feel free to make suggestions 🤝