As discussed during the previous core devs call we would like to ask for the metadata field to support an additional field that could be named context and would be a simple string.
Here are more details why we need this. As we worked on the Orbis SDK we realized that 100% of the developers we worked with were using Orbis to share content (posts, reactions, etc) in their own “social space” which we ended up naming context. A context could represent a social group, an application, a specific chat, a category in a website etc. And each context could have different access rules which were assigned by the developer / owner of this context. This allowed developers to create and own their own space on Orbis which they could query to retrieve all of their context activity. In order to do this we had to add a context field in all of our models which felt weird because models are supposed to guide how a stream is structured and not where the content should be shared / created.
We are using the same context analogy in our work on OrbisDB in order to allow developers to create their own project under which they will be creating content but because this context idea is not natively part of Ceramic we will need every developers to add a context field in all of their models in order to be able to use OrbisDB which creates friction and doesn’t seem natural since as I said before: models should guide how a stream is structured and not where the content should be created. So in order to facilitate our work we would like this context field to be supported in the metadata field of a stream.
This could be added as an experimental field and could be a simple string for now in order to unlock our progress.
Does this specifically need to be named context? I’m trying to decide if this is specific to orbis, and should be called appData or userData, or if context is widely applicable.
Sorry for the late reply. From our experience we realized that the context wasn’t necessarily representing an application, sometime it can be a specific channel in a group, a category on a website etc. So generalizing with appData doesn’t feel like it’s representing contextualized data correctly and userData is so broad that it could make this field very confusing for developers.
I’m definitely open to using another word than context but when we implemented this for the first time a year ago we couldn’t find a better word for this.
Hey, looking at the described use-case and from my understanding during last week’s code devs calls, I’m wondering if the use-case couldn’t be covered using model interfaces, that we shipped recently?
Using model interfaces, you could have a composite such as:
type Context @createModel(description: "Application context") {
# ... any useful context fields
# View to access all the documents bound to the context
nodes: [WithContext] @relationFrom(model: "WithContext", property: "contextID")
}
interface WithContext @createModel(description: "Interface for models bound to a Context") {
contextID: StreamID! @documentReference(model: "Node")
# The following view could be removed from the interface if there's no need to always make the Context document directly accessible
context: Context! @relationDocument(property: "contextID")
}
type Post implements WithContext @createModel(description: "Post with Context") {
# WithContext interface implementation
contextID: StreamID! @documentReference(model: "Node")
context: Context! @relationDocument(property: "contextID")
# Post-specific fields
# ...
}
type Comment implements WithContext @createModel(description: "Comment with Context") {
# WithContext interface implementation
contextID: StreamID! @documentReference(model: "Node")
context: Context! @relationDocument(property: "contextID")
# Comment-specific fields
# ...
}
# ... any other model
This way, context could be handled by any application using the existing mechanisms, rather than requiring specific metadata logic?
@baptiste Do you have any thoughts on @paul’s suggestion above? Basically would allow apps to easily define their schemas to be context compatible by only implementing one interface.
Can you remind me of the reason you didn’t want the context inside of the content?
As I explained during the first core devs call during which I expressed this need on Dec. 7th as well as in my original post: I deeply think that model definitions should guide how a content is structured and not where the content is being shared. So adding this field in the metadata is the right place in my opinion.
In addition to this, Paul’s suggestion would mean that developers with existing models should re-work their models in order to be supported by OrbisDB whereas in our suggestion (adding context to the metadata) it’s fully compatible with existing models which will now be able to contextualized their data if they want to without updating their models.
We don’t use the ComposeDB libraries to create models, we use directly the JS libraries so it’s unclear how this would translate to the Model.create function we are using.
This approach is way less developer friendly than just supporting an additional field in the metadata.
OrbisDB is built heavily around contextualized data and we really need this field in order to open our first wave of alpha testing next week. We’ve been talking about this for +6 weeks and covered it during many core devs call which led to what seemed to be an approval last week. It’s frustrating and not productive to come back to a stage where alternative (and more complex) solutions are being suggested when all we need is an additional field in the metadata…
