Currently the Ceramic Ecosystem page built with Notion while being clean and functional, lacks details about how Ceramic is used in each app and what kind of data models could be leveraged and reused. With Dapps & Models Showcase, we could add links about detailed model usages of dapps to the notion pages to provide much more useful insights about how Ceramic is used in the dapps.
More specifically S3 Dapps Showcase addresses this issue by offering a more comprehensive Dapps store with data model integration. In addition to being an “Ecosystem Page”, this will also provide insight about what data models are being used. As a result, for end users, they would be aware what data is portable across applications and for developers, it would also be easier to discover what data models from prominents ecosystem dapps could be leveraged to cold start their own dapps.
Solution
We extended the S3 composeDB model editor launched during ETHDevener (buidlbox)
I think this is what is being missing in the ecosystem and it’s great to see its being built into cerscan too. We have launched a more generalised version of this feature for Your Web3 Data Hub in April.
And the original plan was to built a dapp-data association mapping into u3. But it was @msena 's idea to build it into s3 data explorer instead.
From the ecosystem’s perspective, it is definitely necessary to have something like a model registry to publish stats about model usage. Because ultimately interoperability/composability/data portability is what differentiates data on ceramic and data siloed in a conventional DB.
The leaderboard is neat. S3 did something similar here US3R SCAN. The challenge is to reliably associate models to dapps (maybe a composeDB model to register model metadata).
We try to parse info from CACAO, but the outcome is messy.
Yeah I definitely agree that this kind of information is super important to guide developers toward using the right model to push toward more composability. I am currently also looking into CACAO as well to add a new source field in Cerscan.
The challenge is to reliably associate models to dapps.
Yeah I agree, something that we notice is that some schemas / models are intended to be used by multiple applications while others are not which makes naming the different entities in Ceramic tricky. This is what’s happening for Orbis for example where users create posts or reactions using our schemas but from many different front-ends (in that case having access to the source field using CACAO is very important) while other models are intended to be used only for one dapp (Oamo or Carbon Title for example). So naming those different entities can be difficult, for example is Oamo a dapp, a protocol or a project? It’s not extremely important but I was wondering if you’ve been thinking as well about this
!