Accompanying the initial release of the Ceramic network were several Ceramic Improvement Proposals (CIPs) defining schemas for certain fundamental data types. Amongst these was CIP-19 which defined the “
The field descriptions for the
basicProfile from CIP-19 are:
||a name||string||150 char||Mary Smith|
||an image||Image sources|
||a short description||string||420 char||This is my cool description.|
||an emoji||unicode||2 char|
||a background image (3:1 ratio)||Image sources|
||a date of birth||ISO 8601||10 char||1990-04-24|
||a url||string||240 char||http://ceramic.network|
||a gender||string||42 char||female|
||a place of residence||string||140 char||Berlin|
||a country of residence||ISO 3166-1 alpha-2||2 char||DE|
||nationalities||array of ISO 3166-1 alpha-2 values||2 char||CN|
||affiliations||array of strings||240 char||Ceramic Ecosystem Alliance|
Additionally, MetaGame uses an
extendedProfile to store some additional fields:
basicProfileallows the storage of an arbitrarily spaced, capitalized, and punctuated text-based identifier for someone.
usernameis primarily for use in interfaces, frequently part of a URL.
basicProfilestores a profile image and a header banner (recommended 3:1 image ratio). This is an image to be used as the background image for the page.
pronouns: A users preferred way of designating themselves pronominally. Generally specified as the singular and possessive forms separated by a slash. I.e. “he / his” or “they / their”.
magicDisposition: Magic: The Gathering uses a five color character alignment matrix. Players may have any, all, or none of the five colors: white, blue, black, red, and green. Each color represents a valuation of certain priorities over others.
This string is simply the first letter of each present color, except for black which uses a “K” to avoid conflicting with blue, e.g. “
availableHours: The number of hours the user is available each week for work projects.
playerType: A descriptor that signifies in which aspect of the development process, from initial exploration to final maintenance, the user is most comfortable.
Finally, we store a list of categorized skills in Hasura, but would like to migrate that into Ceramic.
Structurally, my understanding is:
“There are tradeoffs between smaller vs larger Models. The advantage of smaller Models is they are more modular, easier to compose in different combinations, and allow apps to depend on exactly the data they need and no more. The primary disadvantage of smaller Models, however, is that data belong to two different Models cannot be updated atomically.”
Also, ComposeDB will cache all instances of a followed Model, not just data created on itself. So, each independent aspect of the profile should be represented as its own schema.
The only real danger is a catastrophic failure during the saving process and a profile ends up only partially saved which is unlikely and doesn’t sound like a show-stopper if it happens.
This question was originally posed on @ceramicstudio’s GitHub Discussion Forum, but was migrated here as that forum is destined to be obsolesced. In it’s original location, it received one response from @Carlit0eth:
Hey! We are building Orbis a web3 social protocol based on Ceramic - we are not using Composites (yet) but we developed our schema for profile, it could be helpful: cerscan.com/mainnet/stream/k3y52l7qbv1frxhn39k40plvupdqqna03kdgorggo0274ojggr7z93ex979jyp14w.