Discussion: Basic Profile Definition about cips HOT 17 OPEN

A json-schema for the basic profile could look something like this:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
    "$ref": "#/definitions/BasicProfile",
    "definitions": {
      "BasicProfile": {
        "title": "BasicProfile",
        "type": "object",
        "properties": {
          "name": {
            "type": "string",
            "title": "name",
            "maxLength": 150

          },
          "image": {
            "type": "string",
            "title": "image"
          },
          "description": {
            "type": "string",
            "title": "description",
            "maxLength": 420
          },
          "emoji": {
            "type": "string",
            "title": "emoji",
            "maxLength": 2
          },
          "background": {
            "type": "string",
            "title": "background"
          },
          "birthDate": {
            "type": "integer",
            "title": "birthDate"
          },
          "url": {
            "type": "string",
            "title": "url",
            "maxLength": 240
          },
          "gender": {
            "type": "string",
            "title": "gender",
            "maxLength": 42
          },
          "homeLocation": {
            "type": "string",
            "title": "homeLocation",
            "maxLength": 140
          },
          "nationality": {
            "type": "string",
            "title": "nationality",
            "maxLength": 140
          },
          "affiliation": {
            "type": "array",
            "items": {
              "type": "string",
              "maxLength": 140
            },
            "title": "affiliation"
          }
        }
      }
    }
}

from cips.

ISO for nationality and birthDate make sense. For gender, the ISO you linked seem to be about sex not gender. We specifically want to enable people to share their gender here.

👍 makes sense, maybe we can still define an enum of value if there is no standard so that developers can know what to read/write?

locales is interesting, but maybe this is more relevant in some other type of settings document?

Yes having a settings document sounds great, it could be very useful both at a root/user level and per-app/service 👍

As for the images: yes, we ideally want to do something like that. The longer term goal is to use something like basquiat that allows us to create a top level IPLD object that points to mutliple sizes of the image. I think we aimed for simplicity at first with only linking a single image with CID.

Yes this kind of tool would be very useful indeed!
I think the issues with not providing these metadata is that apps can have different needs and expectations. For example it could be OK for a desktop app to upload a 5MB background image, but on the other side for a web app accessed to via a metered mobile connection, it could be a bad UX. By providing this metadata, app logic can be implemented accordingly.
Another aspect is more adversarial: once users or apps start paying for storage, I don't know about FileCoin but in Swarm the cost would depend on the size of the file requested, so if someone decides to upload a 1GB avatar, it could get very costly for the consumers.

Related to this but out of scope for this CIP: how do documents versioning work please? If we decide image is a string now and becomes an object later, can we maintain backwards compatibility?
It might become quite complex for apps and libraries to maintain compatibility with the specs if there are multiple versions of a growing number of document schemas.

from cips.

@PaulLeCam Let's move this thread to the newly created Settings Index (CIP-24) 👍

from cips.

@oed @michaelsena updated the schema

from cips.

I think as much as possible these values should match common standards to make them easier to implement, especially across apps that may use different locales, for example:

• gender could implement ISO 5218
• nationality could use ISO 3166 (maybe even be strict about using alpha-2 or alpha-3 variant)
• birthDate shouldn't be a UNIX timestamp because that wouldn't work for people born before 1970, instead it could use the YYYY-MM-DD format of ISO 8601

I also think it could be useful for apps to have a locales array of strings using the IETF language tag so they can adapt their UI and/or content accordingly. I'm not sure if it's most relevant on the basic profile or other places.

Also to make things easier for app implementations, it might be useful to provide more metadata for images (and other media/attachment types) rather than only a CID, for example using TypeScript interfaces:

interface BinaryReference {
  cid: string
  type?: string
  size?: number
}

interface DimensionsMeta {
  width?: number
  height?: number
}

interface MediaMeta {
  duration?: string // ISO 8601 - https://en.wikipedia.org/wiki/ISO_8601#Durations
}

interface ImageReference extends BinaryReference, DimensionsMeta {}
interface AudioMeta extends BinaryReference, MediaMeta {}
interface VideoMeta extends BinaryReference, DimensionsMeta, MediaMeta {}

Maybe these should be described in another CIP?

from cips.

Great suggestions @PaulLeCam! A few thoughts:

ISO for nationality and birthDate make sense. For gender, the ISO you linked seem to be about sex not gender. We specifically want to enable people to share their gender here.
locales is interesting, but maybe this is more relevant in some other type of settings document?

As for the images: yes, we ideally want to do something like that. The longer term goal is to use something like basquiat that allows us to create a top level IPLD object that points to mutliple sizes of the image. I think we aimed for simplicity at first with only linking a single image with CID.

from cips.

maybe we can still define an enum of value if there is no standard so that developers can know what to read/write?

People are quite sensitive about their gender. I think a string with length limit is probably the solution that makes the largest amount of ppl happy :)

Related to this but out of scope for this CIP: how do documents versioning work please? If we decide image is a string now and becomes an object later, can we maintain backwards compatibility?

So documents will specify a version of the schema they are using. This allows apps to know if it's using a version they support. Also, I imagine that image for example might change name if we introduce a better format of the image using the above suggested approach.
With regards to the adversarial problem, yeah I think we need to start adding various limits to linked files at various places. Definitely need to think more about where that is defined (probably in the node that decides to pin the linked file?)

from cips.

People are quite sensitive about their gender. I think a string with length limit is probably the solution that makes the largest amount of ppl happy :)

OK I guess it depends on the expectations the users and app developers should have regarding this field then?
If it's a "display only"/free-form text, maybe the app can just display as-is but as it doesn't provide locale information it might be less relevant/used.
On the other side, if the user expects the app to be aware of this field, the app might appear insensitive of the user's preference if it can't handle the value as expected?

So documents will specify a version of the schema they are using. This allows apps to know if it's using a version they support.

👍 makes sense, thanks!

from cips.

Great comments @PaulLeCam, thanks for all the helpful input.

Also, I imagine that image for example might change name if we introduce a better format of the image using the above suggested approach.

@oed @PaulLeCam How do you imagine naming things like this would work? I agree that changing the name of the property is probably the easiest way I can imagine to signal to developers that the expected value is different (even if the explicit version of the schema is different), however this would over time mean that we would be venturing into more and more obscure naming for properties.

People are quite sensitive about their gender. I think a string with length limit is probably the solution that makes the largest amount of ppl happy :)

Agreed @oed this is the reason for just punting on this and using a string with a max length. I wonder if there is something more we could do though...

locales is interesting, but maybe this is more relevant in some other type of settings document?

I think this is a great use case for a Settings document that can be linked from the Root Index (CIP-12)! We had previously had this included in the Identity Index Protocol (IIP) (CIP-11) but removed it because it wasn't apparent what it would be initially used for. This makes sense. How do you imagine a document like that would be structured? How could we reason about dividing up the documents it links to? It could make sense to have a Settings Document (subdirectory) which links to a Locales Document which includes all the locale information for the user. A document like this could include (from Wikipedia):

--
These settings usually include the following display (output) format settings:

Number format setting
Character classification, case conversion settings
Date-time format setting
String collation setting
Currency format setting
Paper size setting
Color setting
other minor settings ...

The locale settings are about formatting output given a locale. So, the time zone information and daylight saving time are not usually part of the locale settings. Less usual is the input format setting, which is mostly defined on a per application basis.

Furthermore, the general settings usually include the keyboard layout setting

from cips.

@oed @PaulLeCam How do you imagine naming things like this would work? I agree that changing the name of the property is probably the easiest way I can imagine to signal to developers that the expected value is different (even if the explicit version of the schema is different), however this would over time mean that we would be venturing into more and more obscure naming for properties.

I guess it mostly depends how we handle versioning, should there be a new version of a schema for backwards-compatible changes/additions, or only for breaking changes?
Let's say to improve the image field we add an imageSources field with an array of object having more metadata about the image type and dimensions.

If we go the backwards-compatible way, the schema would have both image and imageSources fields, but imageSources could never be a required field, because previously created documents wouldn't contain it. In this case it's not a big deal because it's an optional field, but when making changes to required fields it can get more annoying.
Now from an app consumption perspective, the logic would have to be updated to "select the most relevant image source if available or fallback to the basic image field". Again it's not a big deal in itself but that's additional logic for a single change of a single field in a single document, multiplied by all the possible variants it can become way more burdensome.
There is also the app authoring perspective: should the app only write the imageSources or also image field? Again as it's an optional field either way is fine, but if image was a required field, the app would need to fill it as well.

The alternative is to have a new version of the schema that replaces image by imageSources.
In that case from the the app consumption perspective, we can either only work with one version of the schema, which has the downside of excluding either old content (if we only use v2 schemas over v1) or possibly new content (for apps not updated and only supporting v1 schema). An updated app could also decide to support both versions, but that means additional logic of checking if a v2 version exists, and fallback to v1 otherwise, likely needing network round-trips so possibly lowering the UX.
The authoring perspective is similar as the backwards-compatible way: an app could choose to author in a single schema version or both, but there might be the additional cost of having to write multiple documents, so developers might choose to only use the latest version supported by their apps.
The upside though is that it makes the per-schema logic simpler, especially having support for new required fields.

I think this is a great use case for a Settings document that can be linked from the Root Index (CIP-12)! We had previously had this included in the Identity Index Protocol (IIP) (CIP-11) but removed it because it wasn't apparent what it would be initially used for. This makes sense. How do you imagine a document like that would be structured? How could we reason about dividing up the documents it links to? It could make sense to have a Settings Document (subdirectory) which links to a Locales Document which includes all the locale information for the user. A document like this could include (from Wikipedia):

--
These settings usually include the following display (output) format settings:

Number format setting
Character classification, case conversion settings
Date-time format setting
String collation setting
Currency format setting
Paper size setting
Color setting
other minor settings ...

The locale settings are about formatting output given a locale. So, the time zone information and daylight saving time are not usually part of the locale settings. Less usual is the input format setting, which is mostly defined on a per application basis.

Furthermore, the general settings usually include the keyboard layout setting

Yes would be nice to support all these settings, we could even split them into different categories, such as:

• i18n (locale, date-time format, currency format...)
• location (country of residence, preferred currency...)
• accessibility (color contrast, font size, font type...)
• appearance (dark mode, theming...)

Makes me think, back to the basic profile schema, we should change nationality to a nationalities array as people can have multiple ones, and maybe add a residence country field?
I think it would be useful for DeFi or related apps needing to do KYC to have some of this data provided.

from cips.

@PaulLeCam I updated the properties to the changes you suggested:

• ISO for birthDate
• ISO for nationality
• nationality -> nationalities
• homeLocation -> residenceCity + residenceCountry

Let me know how it looks! 👍

Also going to work on creating a CIP for the Settings Index and adding it to the Identity Index Protocol. Will ping you on that CIP when it's ready for review.

from cips.

Nice!
Looks good, I'm just wondering about the max size for nationalities and affiliations, as they are arrays does this refer to the size of one item, or the full array serialized as JSON for example?

from cips.

I was imagining the full array serialized. But open to your direction here.

Also, for Settings Index, a few questions:

• What's the difference between i18n and location? They seem very similar if not the same to me.
• What's the difference between accessibility and appearance? Also seem very similar if not the same.
  @PaulLeCam

from cips.

I was imagining the full array serialized. But open to your direction here.

I guess it mostly depends why we have these restrictions in the first place, is it to avoid making documents too large?
The thing about arrays needing to be serialized for validation is that I don't know if it's supported by JSON schema validators so it might make the implementation more complex.

What's the difference between i18n and location? They seem very similar if not the same to me.

Maybe we can come up with better terms, I'm mostly thinking about the different concerns we might want to address. For example in the case of a Swiss-German citizen living in the US and visiting Japan, you could have something like:

• nationalities: Swiss and German
• country of residence: US
• locales: German and English
• date/time format: MM/DD/YY maybe if he's more used to the US one?
• timezones: home (PST) and local (JST)
• preferred currency: JPY for the duration of his trip

So depending on the apps and services used, it's easier to have specific information to provide the best UX.

What's the difference between accessibility and appearance? Also seem very similar if not the same.

I see it as the difference between the preferences I'd set in my web browser, that can enforce applying colors, font types and sizes on pages, versus letting the pages handle variations of their own designs.
Accessibility should be seen as more "strict" requirements set by user, maybe due to disabilities, while appearance is more about cosmetic preferences, if that makes sense?

from cips.

In general, is there a way that users can backup their profile information using verifiable claims stored in collections index. Probably a link from profile info to another claims document? Even social profiles like tweet/github/etc.. handles can be backed up with claims. Any thoughts?

from cips.

For sure @sylar217 That's entirely possible and I imagine you have much more information about you're profile which you might not want to share publicly on a decentralized network. So the Collections Index could point to some hosted resource which you control access over with your DID.

from cips.

I was looking for something like a claims property in profiles which would contain an array of ceramic document IDs, provided i want to disclose those claims. Something like I link my tweet handle with DID, and have a claims document for the same.

from cips.