I am seeing pretty big performance issues when generating new shares. I am generating from a back up share. I have deleted previous web module shares although I haven’t generated a fair amount for a given account. I am wondering why I would be seeing performance issues? Seems like there’s A LOT of network requests going to torus network.
@s11 We recommend you create no more than a total of 6 shares, including your device shares and recovery shares. This is because the more shares you create, it increases the size of the tKey state, which can cause performance issues in the frontend and can slow down the login process. Ideally, you should create 2 recovery shares and ask the user for their trusted devices and only store the device share on them.
Please let us know how many shares do you have.
For the particular account I had 4 shares. It seems the issue is when I am generating a new share from the backup share. For other accounts this process is quick. But for a particular account for which I have generated many local shares and have since deleted them it takes quite awhile to generate a new share from the back up share. Why is this?
Could you share the network log in the chrome devtool and your code on the login and generate new share for futher debugging?
Yes as you can see there are many many calls the the /get endpoint of metadata.tor.us - this takes up the bulk of the time. Here is the code
await tKey.inputShare(mnemonic, "mnemonic");
const { requiredShares } = tKey.getKeyDetails();
if (requiredShares <= 0) {
const reconstructedKey = await tKey.reconstructKey();
// Do something
}
// Generate new share for device storage
const newShare = await tKey.generateNewShare();
const shareStore = await tKey.outputShareStore(newShare.newShareIndex);
await (tKey.modules.webStorage as any).storeDeviceShare(shareStore);
Hi, it is possible that the share that you used to login (inputShare) is an old share hence a lot of api calling.
Could you try inputShare with a more recent backup share created ?
Yes it is an old share. The backup share was one of the first shares created for this account. It would be unfortunate to have to generate a new backup share just to solve this issue, but you are saying that is the only solution?
Can you tell me why using an old backup share would cause this issue?
And if I generate a new backup share how can I delete the old backup share? How can I get the share index for this backup share?
Any update here? Seems like an inconvenience to have to generate new backup shares just to solve this performance issue. I would think a backup share is something you generate and store as a backup, not having to think much more about it. Any work around?
Another update. I even get rate limited by torus network because its making so many requests. Over 300! What is going on?? I am trying to generate a new backup share but getting blocked.
Now i’ve tried generating a new share, but it failed and now i get {"name":"CoreError","code":1307,"message":"Share doesn't exist "}' when using the original back up share …
Hello, have you resolved your issue? Because I’m currently facing the same problem. I have several dozen requests to “https://metadata.tor.us/get”.
I had 25 shares and therefore performance issues on react-native. I manually deleted all the shares I no longer use by using the “deleteShare” function of tKey, but this added even more requests to “https://metadata.tor.us/get”.
How can I properly delete shares that are no longer in use?
hi @christophe
I hope you are doing great!
Would you mind creating a new post about this question?
Thanks a lot