Discussion: Doctypes

[michaelsena]

Discussion for CIP-5.

[oed]

@michaelsena Did an edit of your original outline adding a lot of details. ☝️

[michaelsena]

@oed some thoughts:

• It might be good to have an array of tags instead of just one, and I can imagine developers wanting to add their appName (or something similar) along with some other categorical information.
• Might we want to include tags as an optional property of signed records? This would allow tags to be added after genesis, either adding a tag if it has none, or adding new tags for various reasons (such as additional applications wanting to add their app as a tag).
• I think we need to include tags in DocState

[michaelsena]

@oed I think we should make accessControl an optional meta property (alongside owners, schema, tags, etc) of a document included in the general Doctype specification (both genesis and signed). This would allow users to plug in a reference to some access control provider (either Ceramic document as described here), or some other mechanism.

Unsure if accessControl should be a string or an array of strings tho.

[oed]

@michaelsena accessControl seems to specific and unrelated to the functioning of the protocol in general. Maybe it could be introduced in tiles specifically instead? Want to try to keep the general parts of the protocol more minimal.

Making the update to tags 👍

[michaelsena]

@oed I've also been thinking about how we might be able to include links to documents one level above the current document. Theoretically there could be many different documents that point to a given document, so this would likely need to be an array.

i.e. Doc A and Doc B both include links to Doc C. I'm a user and query Doc C, but want to traverse back up the directory. I'd need to know the documents that link to this one, in this case Doc A and Doc B.

Maybe this could be something like a paths property that contains an array of docIds that link to the current doc.

Thoughts?

[oed]

@michaelsena @simonovic86 I updated the original post once more to reflect the recent changes in the spec.

[simonovic86]

@oed @michaelsena I updated the original post with:

• rename Next to DocNext

[simonovic86]

@oed @michaelsena should we update the type of the schema to string|object? By using the object type can support nested schemas as well

[oed]

@simonovic86 My worry with doing that is that it will segregate how schemas are defined and also silo them. By enforcing it to live in another Ceramic document devs can easily make use of each others schemas.

[simonovic86]

@oed good point, makes sense! that will enable versioning as well

[simonovic86]

@oed @michaelsena updated DocMetadata with isUnique property. Also, added [index: string]: any; to allow arbitrary properties.