Migration UI - 3 - Signing

[exezbcz]

part of a bigger issue:

• Migration UI #7552

Signing 🚥

• new part, will be the same as with auto teleport (but in modal)
• the reason everything is on its own page and not in the small modal is simply the space and no way of accidentally closing it and losing the progress. It's quite a lot of transactions if you decide to migrate 1k collection.

• it's a step signing.
• here are possible events of the small sub-part

• the parent section changes based on whether its in progress, its done, or inactive, changes between three states.
  

• the grey 1/4 circle is a loading wheel, please match the style as much as possible.

• The same icons are used for the subsections. Every step is in this case one signed transaction.

• let me give an example.
  

• the contextual message is in this case what is changing.

• when you cancel signing, you have the option to retry (it could say failed or canceled)

• after you finish all of this long signing, you can click on the button to finish (it's not automatic because in this signing, there are also transaction links (as you can see above)

[exezbcz]

Some changes will be made, mainly to the structure of what you are signing, and maybe some flow as well.

don't take this issue please till we update that.

cc @vikiival

[yangwao]

@exezbcz where the user will see if everything was migrated successfully with on-chain checks? Like item list for example?

[exezbcz]

@exezbcz where the user will see if everything was migrated successfully with on-chain checks? Like item list for example?

After each transaction is complete, you can click on the link. Once everything is completed it also works like a list of transactions. It does proceed to the congratulations before you click the complete button

I will add more comprehensive list on the congratulations screen - list of items with status and link to tx. Thanks for feedback sir

[vikiival]

Context

So as I wrote the migration script I found out a unpleasant truth: If user wants to presign items, he/she need to sign MANUALY EVERY SINGLE ITEM.
As this should be as easy as possible, I found a new way

The code

The create collectoion tx should be composed of

// Step 1
const nextId = weHaveACodeForThis()
const collection = getCollectionById('ksm', collectionId)

batch [
create(accountId, defaultSettings),
set_collection_metadata(nextId, collection.metadata),
set_team(nextId, KODA_BOT, accountId, accountId)
]

after transaction is successful the code should call an API

POST /relocations

body

{
  "from": {
    "chain": "ksm", // or rmrk depends which 
    "collection": "" // collection id from 
  },
   "to": {
    "chain": "ahk", // or ahp depends
    "collection": "" // collection id 
  },
  "issuer": "" // account id
}

Once API call was returned with status 200.

we need to compose another API call that sends all the required params to sign.

// Step 2

PUT /relocations/{chainFrom}/{collectionFrom}/iterations/{iteration}

The return of this api call is a list of Signatures where signature is composed at least from

{
  "result": {
    "ok": true,
    "id": "", //basically id of last one 
    "error": null
  },
  "data": [
    {
      "account": "", //current owner of nft
      "attributes": "", // attributes to be created
      "chain": "ksm", // chain 
      "collection": "", // rmrk_collection_id
      "data": "", // packed data, check step 3, sig.data
      "deadline": 12000000,
      "id": "", // internal id
      "metadata": "", // metadta to be minted along 
      "signature": "", // signature, check step 3, sig.signature
      "signer": "",// signer, check step 3, sig. signer
      "sn": "", // rmrk_sn_id
      "to_chain": "ahk",
      "to_collection": "", // collection_id
      "to_sn": "" // future_nft_sn
    }
  ]

Keep in mind that API returns just a list of owned nfts, other signatures are dedicated for other users

Once you get this list of signatures we need to build a payload for tx

// Step 3
function createItem(api: ApiPromise, sig: Signature) {
  const preSignInfo = api.createType("PalletNftsPreSignedMint", sig.data);
  const create = api.tx.nfts.mintPreSigned(preSignInfo, {
    Ed25519: sig.signature,
  }, sig.signer);
  return create;
}

const items = iterations.data.map((sig) => createItem(api, sig));

batch(
  items
)

Once this is successful we can burn the existing nfts

// Step 4

Last step is to iterate over signatures one more time and build proper system.remark for BURN

so iterate over nfts build proper extrinsic (do not remeber from head so can find along the way).

Once this is done.
Call API to mark these nfts as migrated and continue to #7563

TBA

DELETE /relocations/{chainFrom}/{collectionFrom}

Body

[
 
]

From design perspective

I wrote the code first so I can guide better.

1. Create collection (✅)

2. Waiting API to sign NFTs

This will be possibly done in iterations.
my bet is 1000 items per one iteration would be sufficient

3. Creating your own NFTs (✅)

Due to the limit of the AH blockchain my estimation is that 200 items can be minted in one iteration. Each iteration needs to wait for the in block state (then we can reflect it as done).

4. Burning migrated NFTs on Kusama

Same as step 3, but different naming, however we are not limited (13K items were tested).

Questions

1. @exezbcz please let me know if anything is unclear.
2. @kodadot/internal-dev is anything unclear here? Happy to hear your opinion.

[exezbcz]

Thank you sir; mostly clear, however, ad signing txs - some questions

For me, it's important how many tx the user will sign and after which step the user will wait.

from what i understand:

• you sign the first one, wait till the collection is created
• signing the API - or giving it rights to manage items?
• ad step 3 is there also needed a signature for every 200 items or that is handled by someone else
• step 4 - one tx for burning

cc @vikiival

[vikiival]

For me, it's important how many tx the user will sign

1. To create collection
2. No need to sign anything from user
3. NumberOfItems / BatchSize = iterations
4. One to burn

So min 3

[exezbcz]

@vikiival, last question just to be sure

What will user sign if he is not the owner of the collection - migrating only items that were pre-signed by the owner

• is there min. of 2 transactions?
• what about step two, same as with migrating as the owner of the collection? Or its not needed as the user is migrating only items he owns.

thanks!

[vikiival]

What will user sign if he is not the owner of the collection - migrating only items that were pre-signed by the owner

There should be a separated screen for /migrations where user can find list of waiting mogrations and can transact them in the batch

EDIT:
@exezbcz already designed the screen

[exezbcz]

Changes/second iteration

• changes to copy, sections, transactions names, number of transactions.
• updated in the main flow in figma: https://www.figma.com/file/JXNtryaNYhY0XJNArzvPQx/Handoff?type=design&node-id=4218%3A2062&mode=design&t=GKkayTA5Y8dTj3H1-1

Initiation stage

• two steps
• sign collection creation
• automated step - no signing needed, just waiting, more states here:
  
• its under the sections

---

Migrating your items

• that is the mentioned batch transactions, there is a limit of items that could be migrated.
• viki mentioned that there might be an additional step of unlisting all items - if it's needed to add it, do so before the three transactions in this section.

---

Finalization

• the fancy name for burning items on the source chain, I did not want to mention that explicitly.
  

• rest stays the same

[vikiival]

I updated the API

[preschian]

hi @vikiival, is there something wrong with my args in here? https://assethub-kusama.subscan.io/block/0xf8cbf28ce3b0ce89b07ab484654c589efd443e6ed241902c437a59b52f920b73

I'm getting a 400 error on the /relocations endpoint. It returns Cannot read properties of null (reading 'currentOwner')

[vikiival]

For the logs purposes

hi @vikiival, is there something wrong with my args in here? https://assethub-kusama.subscan.io/block/0xf8cbf28ce3b0ce89b07ab484654c589efd443e6ed241902c437a59b52f920b73

Everything is good here

I'm getting a 400 error on the /relocations endpoint. It returns Cannot read properties of null (reading 'currentOwner')

There was a bug with usage of uniquery I was requesting image field on rmrk endpoint that does not exist.
Fixed and deployed

[preschian]

Updates:

• still in progress step 3, preparing pre-signed items. Currently, I still ask Viki related to the backend via Telegram
• rmrk => looks good until step 3
• ksm => sometimes, error on step 1

I will check again tomorrow

[preschian]

Updates:

• Mostly still errors on the db/backend side. One of the issues was: Rest operator on bind will fail to execute on bigger tables aidenwallis/kysely-d1#23
• Currently still in this phase:

[preschian]

Updates #7909:

On ahk:

• ✅ create collection
• ✅ mock API on /relocations
• ❌ real API on /relocations return D1_ERROR
• ❌ migrate nfts from mock API https://assethub-kusama.subscan.io/extrinsic/0x8584ee95d864fc6806923eb96227afd758cd17747283f340d384318f9cc3517d

On ahp:

• ✅ create collection
• ❌ mock API on /relocations returns Target collection not found or you are not the owner
• ❌ real API on /relocations return D1_ERROR

cc @vikiival

Iterations and Burn not yet implemented. I will implement that once migration nfts look ok

[preschian]

Because of the API error, I will try to help on the backend side also on https://github.com/kodadot/private-workers

[vikiival]

❌ mock API on /relocations returns Target collection not found or you are not the owner

This was fixed

[preschian]

Because of the API error, I will try to help on the backend side also on kodadot/private-workers

I'm still not able to test this out. My dashboard has been blank since yesterday. There were some issues on the Cloudflare side. ref: kodadot/workers#192 (comment)

https://www.cloudflarestatus.com/

[vikiival]

Still dead :/