Hi, it seems this is not possible at the moment.
when i try to use Composite.create with a did-session from an eth address i get: Error: Unsupported model controller did:pkh:eip155:1:0xxx, only did:key is supported at assertSupportedModelController
Will that change in the near future?
Could i perhaps create a did session on the basis of a did:key? possibly replacing eth.getWebAuth by something else? Would there be an example of that?
Thanks, Joera
did-session is typically used for app users, so that they can easily use their wallet to sign ceramic updates, on the other hand apps will typically manage their models/composites with a long lived key (did:key)
was there any specific reason you where trying use did-session in that way?
it is possible to create a new authmethod for did-session, similar to the pkh libraries, and the authmethod could be a general did one or a did:key one for making sessions, but its generally recommended to publish models with just a did:key
Hi Zach,
I am working on a POC for a decentralized DBaaS, using Fluence network and ComposeDB.
The previous version had a two-sided marketplace with node+db-providers and users. From a frontend you can select a db-provider, which each is a fluence node paired with ceramic & ipfs nodes. The index on node is generated with a hardcoded pk of a did:key.
The new version i am working on has node-providers, index creators/owners/controllers and users. Node-providers offer infrastructure. Index creators can create composites + start indexes on that infrastructure and let ‘their’ users use them. All within a decentralized marketplace for decentralized services. From a different perspective it could be seen as a ComposeDB playground. (permanence of data of course not being guaranteed … yet). Or think of the UX for a headless CMS with non-devs being able to design content architecture.
Within such a context it would be good UX for index creators to able to create composites and operate indexes from a wallet/did:pkh
Joera