Merge pull request #489 from Web3Auth/mpc-core-kit-update

Mpc core kit update

docs/sdk/core-kit/mpc-core-kit/install.mdx

@@ -5,7 +5,6 @@ displayed_sidebar: sdk
 description: "Web3Auth MPC Core Kit Web SDK - Install | Documentation - Web3Auth"
 ---
 
-import ServiceWorkerCode from "@site/src/common/sdk/core-kit/tkey/_sw-js.mdx";
 
 ## [`@web3auth/mpc-core-kit`](https://npmjs.com/package/@web3auth/mpc-core-kit)
 
@@ -32,50 +31,3 @@ app. We have created guides for different bundlers to help you with this issue:
 
 - Please check out our **[Webpack 5 Troubleshooting Guide](/troubleshooting/webpack-issues)**
 - Please check out our **[Vite Troubleshooting Guide](/troubleshooting/vite-issues)**
-
-### Service Worker
-
-A service worker is a scripts that is run by the browser. It does not have any direct relationship with the DOM and provides many out of the box
-network-related features. Web3Auth Core Kit tKey SDK needs a service worker relative to `baseUrl` to capture the auth redirect at `redirectPathName`
-path.
-
-For example, while using service worker if `baseUrl` is `http://localhost:3000/serviceworker` then user will be redirected to
-`http://localhost:3000/serviceworker/redirect` page after login where service worker will capture the results and send it back to original window
-where login was initiated.
-
-:::tip
-
-- Using service worker is required only in the popup flow.
-
-- Service worker is needed if you are using `popup` uxMode within your
-  [Service Provider configuration](/sdk/core-kit/mpc-core-kit/initialize#configuring-service-provider).
-
-- For browsers where service workers are not supported, or in the case you wish to not use service workers, create and serve redirect page (i.e
-  `redirect.html` file).
-
-:::
-
-#### Redirect Page
-
-If you don't have to use service worker or `redirect.html` file. You can get login result by calling `handleRedirectResult()` on redirected page
-mount.
-
-For example, if baseUrl is `http://localhost:3000` and `redirectPathName` is `auth` then user will be redirected to `http://localhost:3000/auth` page
-after login where you can get login result by calling `getRedirectResult` on redirected page mount.
-
-#### Service Worker Setup
-
-- If you're using React, to setup service worker, you need to create a `sw.js` file in your public folder and register it in your `index.html` file.
-  You can find more information about it in [this blog](https://blog.bitsrc.io/using-service-workers-with-react-27a4c5e2d1a9).
-
-- For Angular, [this guide](https://angular.io/guide/service-worker-getting-started) will be helpful in setting up the service worker.
-
-- For Vue, [this guide](https://www.360learntocode.com/2020/12/how-to-use-and-customize-service-worker-in-vuejs-pwa.html) is a great way to get
-  started with service workers.
-
-#### Service Worker Code
-
-You can directly copy the service worker file code from here and paste in your respective folder. You can also find the code in our
-[MPC Core Kit Example (Popup Flow)](https://github.com/Web3Auth/web3auth-core-kit-examples/blob/main/mpc-core-kit/mpc-core-kit-react-popup-example/src/App.tsx).
-
-<ServiceWorkerCode />

docs/sdk/core-kit/mpc-core-kit/mpc-core-kit.mdx

@@ -7,31 +7,15 @@ description: "Web3Auth MPC Core Kit Web SDK | Documentation - Web3Auth"
 import Image1 from "@site/static/images/tkey-mpc-flow.png";
 
 Web3Auth's `@web3auth/mpc-core-kit` SDK is a simple and easy to use SDK, which helps you implement the Web3Auth MPC Features, while giving you the
-flexibility to customize the UI and UX of the authentication process. It is essentially a wrapper around the tKey MPC SDK, which is the core
-implementation of Web3Auth MPC.
-
-:::caution
-
-This SDK is production ready, however, this works in the 2/2 recovery flow. This means that the backup/ recovery shares are copies of the device
-share, making the user hold only one of the shares is any case.
-
-Web3Auth MPC Core Kit Web SDK is designed in a way to make it easier for you to integrate Web3Auth MPC. Without the social login share, it is not
-possible for you to sign signatures. Hence, the 2/2 flow is allows you the same experience as a 2/3 or 2/4 flow. You can generate as many backup
-shares as you want, but internally, they will be copies of the device share.
-
-If you require the 2/3 flow for your application, you need to directly integrate the [tKey MPC SDK](/content-hub/guides/tkey-js-mpc). Here, there is
-one additional share which you can ask the user to safe gaurd, however the experience of using it will be the same. We are working on adding more
-features to this SDK and will be releasing them in the consecutive updates.
-
-:::
+flexibility to customize the UI and UX of the authentication process.
 
 ## Requirements
 
 - This is a frontend SDK and can only run in a browser environment
 - Basic knowledge of JavaScipt
 - Supports all major JavaScript Frameworks, Libraries and Bundlers
 
-## Understanding the Web3Auth MPC Core Kit Web SDK
+## Web3Auth MPC Infrastructure Components
 
 With the Web3Auth infrastructure, your key is divided into multiple parts and stored across your devices and our Auth Network. This ensures that your
 key is always available and never stored in a single place. While in the traditional Web3Auth SDK, your key was dynamically reconstructed in the
@@ -59,13 +43,13 @@ nodes have a threshold of 3/5 which can be customized according to requirements.
 corresponding to the TSS Shares in the nodes and returns them to the user's end. These signatures are then used alongside other shares to generate the
 final TSS Account signatures.
 
-#### Device Factor
+#### Device Factor (Index 2)
 
 This is the second factor used to access the user's account. This step involves the generation of a TSS Share on the user's device and using that to
 generate a final signature for the TSS Account alongside the social login factor. This ensures the user logs in using their trusted device and
 maintains a proper non-custodial setup.
 
-#### Backup Factor
+#### Backup Factor (Index 3)
 
 A user has a choice to generate as many backup factors as needed to access their account. This step involves the generation of a TSS Share on the
 user's end and storing them in whichever location they prefer. This share can be used similarly to the device share to generate a final signature for
@@ -85,19 +69,36 @@ The TSS Shares are the main component needed for the generation of the final wor
 distributed key generation and are stored in the Auth Network and the user's device. Since these shares are generated using MPC, they are **never
 reconstructed** and always stay decentralized and secure.
 
+However, we have exposed a function to reconstruct the TSS Key from the shares in the SDK. This function has been marked unsafe since there is no
+direct use case for it other than key exports in the case the user wants to own it completely.
+
 #### Metadata Key & Shares
 
-The Metadata Key closely mimics the storage of the TSS Key and Shares. The only difference is that the metadata key is always reconstructed and used
-for its encryption/decryption capabilities. It utilizes basic Shamir's Secret Sharing and is initially generated on a users' frontend. The metadata
-key ensures that the infrastructure is backward compatible with the existing Web3Auth architecture, which utilizes SSS (Shamir's Secret Sharing) as
-the main key reconstruction scheme.
+The Metadata Key closely mimics the storage of the TSS Shares. The only difference is that the metadata key is always reconstructed and used for its
+encryption/decryption capabilities. It utilizes basic Shamir's Secret Sharing and is initially generated on a users' front end. The metadata key is
+utilised for the encryption/decryption of the user metadata stored in the Web3Auth Metadata Server.
+
+One metadata share gives you the **read** access to the metadata server, while two or more (as the threshold is reached) give you the **write**
+access.
 
 #### Factor Keys
 
 To enable refresh, deletion, and rotational capabilities on the `tssKey`, we also introduce **factorKeys**. Factor Keys are randomly generated keys
 unique to each factor-generated user's device and backups, like users' phones, chrome extension, on their cloud, assisting third parties, etc.
 
-As shares to the TSS Key and/or Metadata Key may rotate, Factor Keys allow a consistent secret to being saved in these different locations.
+As share to the TSS Key and/or Metadata Key may rotate, Factor Keys allow a consistent secret to being saved in these different locations.
+
+## Understanding the MPC Core Kit SDK Flow
+
+By default, for a new user, the MPC Core Kit SDK starts in a 2/2 flow. This means that the user will have to generate a social login factor and a
+hashed cloud factor. This hashed cloud factor is derived on the SDK front end and stored in the encrypted metadata server. This enables the user to
+start the login process from any device without creating an MFA factor.
+
+This is done to make sure the user can access their account from any device without having to generate a new factor. However, this makes the initial
+onboarding, semi-custodial. To make the onboarding completely non-custodial, the user can use the `enableMfa` feature to generate a device and backup
+factor and delete the hashed cloud factor. This makes the user's account completely non-custodial in 2/3 setup and enables them to access their
+account from any device using the backup share. Device share is saved on trusted device and can be used to access the account from that device
+seamlessly without having to generate a new factor.
 
 ## Resources