Is metadata stored in centralized database?

Help - Core-Kit tKey JS SDK
1

Hi everyone, I noticed that in the source code of torus-metadata, the metadata is stored in a centralized database instead of being pushed to IPFS, even though a CID is created. The getHashAndWriteAsync function only generates the CID without pushing it to IPFS.

const ipfsResult = await getHashAndWriteAsync({ [tableName]: [{ key, value: data }] });

In getHashAndWriteAsync function, it only created CID:

const getHashAndWriteAsync = async function (data: Record<string, Partial<Data>[]>): Promise<string[]> {
  ...
  const ipfsResult = hashes.map((x) => {
    const cid = new CID(x); // does this code only create CID?
    return cid.toString();
  });
  return ipfsResult;
};

In the case of the Torus database being shut down or attacked, do you have any approach to recovery?

2

Alongside using our metadata setup you can provide your own end point to store your users metadata securely.

We no longer use IPFS as it was not a performant form of storage for metadata.

3

Hey @tranvinhlx135

Thanks for the question. Currently Web3Auth’s metadata server is on our AWS Cloud network. Metadata server basically stores metadata about where the user’s shares are stored (incl. public polynomials etc), helping us retrieve the tKey info. All of the metadata is fully encrypted as you can see from network calls. Please note that the shares are actually stored on nodes. You can read about that infrastructure here (Role of Nodes | Documentation)

Further, this is just one part of the user’s key and the other two parts are stored within the user’s device (device share and backup recovery share). These two parts can separately be used to construct the key without the need of the metadata server. We’re in the process of rolling out a separate website to help user’s data. Something similar to what happens in our Tech Page (Tech Home).

Finally, talking about the recovery mechanism in case of attacks for the metadata server, We take database backups at regular intervals within the day to ensure data security and recoverability within our systems. These backups exist within our AWS as well as IPFS storage. Our frontend SDKs allow you to configure your own metadata server URLs (Core Kit SDKs). We currently use AWS RDS for the db backing metadata due to performance reasons. If you look at older commits, we used to write data to IPFS on each call. This resulted in lower performance. So, in the latest code, we just return the CID hash. We internally have a lambda service which periodically takes backup of the RDS and dumps it to IPFS.

5

Thank you for your explanation.