Question: Alexandria Migration Specifics

[bwhm]

Not sure if this is specified anywhere, but what exactly are we migrating from the current testnet to Alexandria?

Things I take for granted:

• Memberships (although changed)
• Channels
• Data objects + content
• Forum
• Balances
• Mints (IDs)

Nice to haves (in order of priority)

In general, the problem here is that I don't think it would work (well) without starting the chain with a ton of state. Also, I don't know exactly how the changes in memberships will affect each worker/role.

With that assumption, I'm not going to dig too deep into the nuances...

Mints

Can we keep the capacity and the total_minted intact, and set created_at to 0/1?

Council and History

Can this be done in any reasonable way? Starting with the election round >0 is easy I guess, but actually storing the previous CMs in each round? The election+voting history is not critical.

If a new Council must be elected at start, or set by sudo, I think that's fine.

Proposals

Keeping the proposal history and discussion would be nice. Sounds like it's possible if we just set all block height references to 0/1, and scrap the voting history. Basically just keep:

• Proposal ID
• Proposers memberId
• Type
• Title
• Rationale
• Result
• Description (if text/signal)
  Parameters for non-text proposal might be a lot more difficult? At least for deprecated ones...

Curator+Storage WGs

Here, the most important would be then current workers+leads, with

• Worker Id
• Stake ID and active stake
• Recurring Reward ID and their rewards?

Keeping the openings seems unimportant, but could interfere with Proposals

Validators

Lots of issues here, but ideally, we'd keep the stash/controller setup and bonding. I suppose this will be hard as the staking module is changed from upstream... In the event that we can't migrate the bonded stakes, we need to "refund" them on the new chain. As many have been slashed, thus having less "unbondable" stake than actual stake, this must be taken into account.

We don't want them to actually start being validators/nominators ofc.

---

I'm sure there are other things I'm forgetting about, in addition to the oversimplification. We need to figure this out rather quickly IMO.

[mnaamani]

Memberships - done in Joystream/joystream-api-examples#12
Data objects + content - done in Joystream/joystream-api-examples#12
Forum - done in Joystream/joystream-api-examples#12
Channels - in progress
Balances - will do in #1112

Mints (IDs): should be easy to do but I suggest only setting an initial capacity. setting the total_minted seems awkward and would require changing the runtime just to set this "historic" value.
Proposals: added to issues #1198

The council doesn't really have a history expect for maybe the number of rounds. I think starting with an empty council as we always do seems acceptable. Having an initial council with proper staking will involve some significant runtime code changes.
In general any staked roles, I would prefer not to try to transfer over just because there is so much state.(staking, recurring rewards, and the working group module itself)

With respect to validators, I think its possible to configure an initial set but the overhead of coordination to get the same validators ready and operational at launch time is not practical.

For transferring proposals, I see great value in preserving it, although the state is a bit complex, it is worth the effort I think. But I will leave it to the end after I'm done with the Balances.

[bwhm]

Mints (IDs): should be easy to do but I suggest only setting an initial capacity. setting the total_minted seems awkward and would require changing the runtime just to set this "historic" value.

If it's awkward, we'll skip it!

The council doesn't really have a history expect for maybe the number of rounds. I think starting with an empty council as we always do seems acceptable. Having an initial council with proper staking will involve some significant runtime code changes.

Yeah, it's not really important.

In general any staked roles, I would prefer not to try to transfer over just because there is so much state.(staking, recurring rewards, and the working group module itself)

This one is a bit more tricky, but see below.

With respect to validators, I think its possible to configure an initial set but the overhead of coordination to get the same validators ready and operational at launch time is not practical.

I don't think we want the validators to be expected to actually run the nodes. I'm just concerned about transferring their stake. For the other roles, we can just add their staked funds to their balances manually, but for validator/nominator bonded tokens, it's a lot more complex due to how slashing doesn't affect the amount you can use to bond, but you still can't withdraw them...

Proposals: added to issues #1198
For transferring proposals, I see great value in preserving it, although the state is a bit complex, it is worth the effort I think. But I will leave it to the end after I'm done with the Balances.

Yeah, I suspected this is tricky, but I do think it's pretty important as well.

[mnaamani]

One module we ignored is the Memo. is there any important information there related to withdrawl via status server?
I suspect validators are no longer using it to place a crypto address there.

[bwhm]

One module we ignored is the Memo. is there any important information there related to withdrawl via status server?
I suspect validators are no longer using it to place a crypto address there.

So the whole module is gone?
I don't know how the new membership module is setup, but even if it has some more input fields, I still prefer the memo...

[mnaamani]

No in Alexandria the memo module is still part of our runtime.
By "ignored" I really meant we forgot to consider if we want to migrate the memos data.