People Chain Launch and Identity Migration Plan

[joepetrowski]

As explained in RFC-32, we are working on migrating the Identity pallet and its functionality from the Relay Chain into a system parachain. This will be the first time that functionality is migrated from the Relay Chain rather than simply introduced.

After successful tests on both Rococo and Westend (the Rococo one revealing a small bug, and the Westend one working as expected), we are ready to start deploying this People Chain on production networks.

Everything will happen on Kusama first, and after a successful migration, will happen on Polkadot. This migration will be especially important to UI developers, who will need to source identity information from a new location. The change also comes with a 100x reduction in deposits, making the Identity system much more accessible to users. [1]

Phase 1: Genesis

At the moment of writing, the Kusama and Polkadot runtimes maintained by the Fellowship are based on Polkadot SDK v1.3.0. They will need to be on v1.7.0 for the migration to take place, so that will be the signal that everything is ready.

Once that is in place, we can do two things:

1. Block Identity pallet calls in the Relay Chain;
2. Create a People Chain runtime.

Once the Relay Chain upgrades (let’s call it v1.X.0), we will take a snapshot of all existing Identity state like account identities, sub-accounts, and registrars. This will form the genesis state of the parachain. [2]

Phase 2: Free Deposits

With the Relay Chain upgraded and a genesis state to work with, we can propose to actually register the People Chain. This will not quite be ready to use from the point of being onboarded, as we need to free up all the deposits held on the Relay Chain and update it on the parachain (at genesis there will be no balances on the parachain).

This will require a patch update of the Relay Chain (let’s call it Relay v1.X.1 [3]) that will allow any account to call a special extrinsic just for migrating identities. You can see an example of this on Westend.

This extrinsic will free the Identity deposit on the Relay Chain, calculate the deposit required on the People Chain (again, about 100x lower), teleport the parachain deposit, and add an instruction for the People Chain to reserve the deposit there. That is, users with 20 DOT reserved on the Relay Chain will end up with roughly 19.8 DOT free on the Relay Chain and 0.2 DOT reserved on the People Chain with their Identity Info and sub accounts preserved.

This process will look like this on the Relay Chain and People Chain, with identityMigrator.identityReaped and identityMigrator.depositUpdated events, respectively:

At the end, the Identity state will be off the Relay Chain:

To minimize downtime, I’d recommend setting the enactment time for the patch upgrade a few days after the parachain onboarding, such that users don’t need to wait for an entirely new referendum to pass.

Phase 3: Free Identity

Once all Identities have been migrated (and as this is permissionless, I expect it to take less than one day), then the People Chain can also upgrade (again, People v1.X.1 [3]). This upgrade will allow everyone to start using the Identity pallet functionality again.

Like the Relay Chain upgrade, this patch upgrade can also be scheduled to happen a few days after the Relay Chain’s patch upgrade.

Notes

[1] You can already start using it on Rococo and Westend.
[2] A script for doing that is in this PR. Note that it also migrates the additional data for those who have set github and discord fields.
[3] You can see these “v1.X.1” changes in this PR for Westend.

[muddlebee]

Is there a possibility of integrating a ENS like service with Identity here?

[xlc]

look at this Unique Usernames in Identity Pallet by joepetrowski · Pull Request #2651 · paritytech/polkadot-sdk · GitHub

[muddlebee]

@joepetrowski will the above changes shared by xlc, be live on Polkadot or its system parachain? I don’t see it currently.

[joepetrowski]

Yes. You don’t see it because it’s not in the runtime yet.

[PolkaGate]

We really need to have functional user interfaces (UIs) before updating the Kusama and Polkadot chains. This is a screenshot of the experience when trying to set an identity on the Westend People chain.

[joepetrowski]

Looks like something to report here.

It also looks like you are on the Accounts tab, could have nothing to do with Identity. That’s why they are on testnets and then Kusama before Polkadot.

[PolkaGate]

Yes, it has been reported: Set Identity fails on account page · Issue #10540 · polkadot-js/apps · GitHub

We can set identity via the account page.

All I want to emphasize is the importance of having at least one functional UI before releasing new features on Kusama.

[joepetrowski]

Step 2 is now complete, meaning there is no more Identity info left on the Kusama Relay Chain. All deposits are updated (and much lower) on the People Chain (current Apps UI link).

Note that all front ends that use Identities need to switch @polkassembly @wliyongfeng @wirednkod @Tarik

Once 388 enacts then all functionality (including registrars) will be available on the parachain.

[Tarik]

Working on getting this stable in the Apps UI

[Tarik]

PR is up to fix that bug you mentioned: Fix set identity on accounts by TarikGul · Pull Request #10581 · polkadot-js/apps · GitHub

[joepetrowski]

With the enactment of 388, the Kusama People Chain is now ready for use. Users can now set/modify their identity there, request judgement, provide judgement, etc.

[Tarik]

Everything is up to date and working for identities in Polkadot-js UI. The relay, and subsequent system parachains will all query the people chain for any identity needed.

[muddlebee]

anyone opening openGov ref for .ksm username suffix at Kusama?

[CoinStudio]

Is there any Identity Registrar that is operating on People chain now? I am trying to get verified but it seems all backends are still pointing to Kusama. Thanks

[tbaut]

I’ve got a bunch of questions related to what front-end devs should ideally do considering that parachains and ppl-chains may conflict.

• what happened for pure proxy that can’t be replicated on another chain? I see that the identity has been migrated, but they now have no way to change it. I know we want to make pure proxies cross-chain eventually, but not sure about the timeline.
• do we aim at having the ppl-chain be the canonical identity source and what’s the best way for parachains, should they remove the identity pallet?
• should front-end devs check the ppl chain, on top of identity pallet of a parachain, and show the ppl’s chain identity first?

[joepetrowski]

@tbaut

what happened for pure proxy that can’t be replicated on another chain? I see that the identity has been migrated, but they now have no way to change it. I know we want to make pure proxies cross-chain eventually, but not sure about the timeline.

Yeah these are unfortunately stuck. How many cases are there? I’m trying to get some priority on the feature that would allow network-wide pure proxies.

@tbaut

• do we aim at having the ppl-chain be the canonical identity source and what’s the best way for parachains, should they remove the identity pallet?
• should front-end devs check the ppl chain, on top of identity pallet of a parachain, and show the ppl’s chain identity first?

These really seem like application decisions. IMO there is literally zero difference between having the Identity pallet on the People Chain instead of the Relay Chain, except for lower deposits for users. It is purely a “redistricting” and as far as canonicality goes you should treat Identity on the People Chain no different than you did on the Relay Chain.

[tbaut]

@joepetrowski

How many cases are there?

I don’t have the tools to know at hand, but identity + multisig has been a requirement to receive largish sums from the treasury, I would assume a good half are controlling a pure proxy, so I’d guesstimate in the lower 100s of cases.

@joepetrowski

you should treat Identity on the People Chain no different than you did on the Relay Chain

While I understand it’s a Dapp decision, I always prefer to get some consensus, and eventually a unified way of setting an identity, it makes our life easier. If the parachain devs agree that it’s useless to duplicate this pallet, then the Dapps could have one unique flow, teleport/swap funds, and set an identity. Dapps would only fetch the identity on the People Chain. The introduction of the People Chain is not business as usual, this actually makes the relay very special, since it doesn’t have an identity pallet any more. For instance, in the case of Multix, I could:

• totally abstract the People Chain on Kusama, show the identity from the PC, set the identity from the PC, do the whole swapping and fund management etc… This was never done before, neither on the relay, nor on any parachains. Users would see when making the transaction, that’s it’s a complex one
  or
• treat the PC as a normal chain, support it and have users know about its existence. Ask them to select it before setting a identity, with business as usual. I would still have to have a relay specific logic to go fetch the identity from the PC

So at the end of the day, although the identity on the PC makes everything more complex, Dapps can abstract it, and I wonder if we should go the extra mile of having all parachains use it, because the logic would then be the same as what we do with the relay.

[joepetrowski]

@tbaut

treat the PC as a normal chain, support it and have users know about its existence

I really think that this should not be considered normal. All chains should be abstracted from users in 99% of cases. Yes I understand there are some power users who want to get into the details, but the default should always be to abstract away chain architecture. This is not specific to People Chain.

@tbaut

While I understand it’s a Dapp decision, I always prefer to get some consensus, and eventually a unified way of setting an identity, it makes our life easier.

But different dapps might have different preferences about what they want to use. If you are displaying identity info, it’s just a decision you have to make; just like if you do something that requires KYC you have to choose a KYC provider.

@tbaut

The introduction of the People Chain is not business as usual, this actually makes the relay very special, since it doesn’t have an identity pallet any more.

I disagree, Polkadot should be seen as one, singular system. None of the chains are “special”, it’s just architecture. If a Web2 app migrates part of its computation from an m7.large to a c7.large, it doesn’t make one special and they certainly don’t expose it to their users.

[tbaut]

@joepetrowski

I disagree, Polkadot should be seen as one, singular system. None of the chains are “special”, it’s just architecture. If a Web2 app migrates part of its computation from an m7.large to a c7.large, it doesn’t make one special and they certainly don’t expose it to their users.

When I’m saying that the RC is special, it’s not an opinion, it’s a fact, it’s an actual case in the code when “if we’re dealing with the RC, then do things specifically” because unlike all the other chains, the identity info is elsewhere. The reason why I commented here in the first place is because as you say, it should not be special, but for this to happen, we need parachains to use the PC as an identity provider.

However, this is unlikely to happen, because the burden to migrate outweighs the benefits.

Unfortunately, I’m not able to come up with a proper solution to the problem, and what I believe will happen is that we’ll have:

• a special case for the relay and a complex TX (abstracted away) for anyone willing to set this identity
• business as usual for parachains