Should I use DID:PKH to store profile information?

I’m fuzzy on the specifics of how DID:PKH and DID:Session function. I understand that I can craft a DID:PKH from an Ethereum address. The DID:Session seem to be a transitory DID:key generated from a DID:PKH.

Given a Ethereum address, I can use CAIP-10 to look up their DID:3ID. I shouldn’t need to do that for a DID:PKH though because it can be formed from the address… My understanding was that DID:Session is being used to hide a creator’s Ethereum address.

It was suggested that MetaGame should migrate to DID:PKH for better support. The existing tiles containing users’ profiles are controlled by DID:3IDs, however. Will we need to create new tiles controlled by a DID:PKH to store profiles?

Also, what is the timeframe for the implementation DID:3IDv2? Would it be better to stick to DID:3IDv1 for the time being and switch to v2 when it becomes available?

One more issue. I switched MetaGame’s DID:3ID to the current format, and after I created a new account, the process that pulls that data into the backend is reporting there’s no CAIP-10 for that Ethereum address. Does that have to be created manually, or is there a delay, or what?

@zfer, @paul, & @mattdavis0351.eth can one of you weigh in here?

@dysbulic I’m unsure on most of this.

What I do know is that any data created with DID:3 is not going to be able to be controlled by a DID:PKH.

did-session is a library that helps manage “web 2 like” sessions, while implementing SIWE and SIWS specifications. When you use it, a DID:KEY is created as well as the DID:PKH. The DID:PKH is what you will use to read/write data for the given user.

I’ll let the engineers who were pinged here weigh in on any recommendation for migrating from DID:3 to DID:PHK as well as the implementation timeline for 3IDv2 and what happens to the data when that takes place.

yes unfortunately there is no easy migration from 3id → did:pkh for any existing data, other than apps implementing there own “manual” migration. And yes did:pkh and related libraries will be the best supported and receive the most development. 3id/3id-connect remains for any apps that really cannot switch over, but 3id-connect library support will be limited. We would really like help anyone switch over when possible. Many apps have been switching over at the same time they change to composedb

It wont be easier to switch to 3idv2 necessarily from 3idv1, it will likely look closer to did:pkh and be as easy or easier to switch from did:pkh in the future. Timeline for a 3idv2 is uknown at the moment.

not sure i follow the last question, what was the 3id switch?

hey @mattdavis0351.eth , I’m Sanjay from LearnWeb3DAO. Ceramic had a bounty task for writing a tutorial. And we were asked to inform & coordinate with you in order to see if the tutorial fits ceramic messaging and that no duplicate tutorials are being worked on.
I request you to review my tutorial: https://sanjayblogz.hashnode.dev/deep-dive-into-common-did-method-its-use-cases

And also let me know if there are any other further processes.

Here is my contacts:
Email: sanjaykumarkathi5@gmail.com
twitter: sanjay_0508