Idea: Many-to-many relationship between Project and Context
tempe-techie opened this issue · comments
Idea
Currently the Project object and the Context object have a one-to-many relationship. Project can have many contexts, while context only belongs to one project.
Context:
{
"name": "SGB Chat",
"project_id": "kjzl6cwe1jw145qvssudltw3f1qxhehs4yulyntvgzbs1jeco1yy3vv7kfm5uka",
"websiteUrl": "https://sgb.chat",
"accessRules": [],
"displayName": "SGB Chat",
"integrations": {
"discord": {
"channel_id": "1083760838004973678"
}
}
}
Project:
{
"name": "Sgb.chat",
"website": "sgb.chat"
}
I propose switching to the many-to-many relationship between the two. This would mean that a context can be used by many projects.
Reasoning behind this idea
Let's say there's a community that has an Orbis chat frontend operated by person A. This person has very strict rules on which content to allow in the chat and regularly removes posts that do not fit these rules. Because part of the community does not agree with so strict censorship rules, a person B sets up an alternative frontend, but using the same context.
If we want person B to be able to run their own frontend with the same context, but having their own censorship rules, the many-to-many relationship between Project and Context is needed. Post removals need to occur on the Project level. Some posts can be removed in one project, but remain visible in another, even though both use the same Context.
Changes required
@baptistegreve I would love to hear your opinion on this and what kind of changes would it require. Could it be developed in a backwards compatible way? Or having both systems running in parallel? Let me know your thoughts 🙂
Hey! Thank you for sharing your thoughts here :) This is an important discussion and after your initial comment the other day I gave it some thoughts but I don't have a precise solution in mind yet.
My first intuition is that this should be done with a sort of forking mechanism in which anyone would be able to create a project and add a forked version of another context in there. When that's the case, the project owner would be able to add their own moderators to the forked version of the context and querying the forked version would return both the posts shared in the new version as well as keep on sharing posts shared in the initial version.
What are your thoughts on this?
Edit: While it's not a #1 priority it would definitely be implemented in a backward compatibility way once finalized.
@baptistegreve If I understand correctly, forking would mean that from the forking point on, the community chat is split into two different contexts that do not share future posts anymore. So whatever group B posts in their own frontend would not be visible on the A frontend. Did I understand correctly?
I would rather see that both groups share the same context, and posts from both frontends are posted to that same context. The only difference would be the moderation part. Each group would have their own moderation.
May I ask how is moderation currently implemented? If I remove some post from my project, does this get written into Ceramic? I couldn't find that info on Cercscan 🙂
forking would mean that from the forking point on, the community chat is split into two different contexts that do not share future posts anymore.
What I have in mind would be a version of forking in which those twin-contexts would share future posts but have a different set of moderators so some posts might be visible in Context A but not in Context B but most of the posts would be available in both contexts.
May I ask how is moderation currently implemented?
Moderation as well as all of the logical tasks (gating mechanism for examples) are implemented at the Orbis infrastructure layer which is the layer being queried by front-ends (which we intend to decentralize at some point to let anyone run their own architecture).
forking would mean that from the forking point on, the community chat is split into two different contexts that do not share future posts anymore.
What I have in mind would be a version of forking in which those twin-contexts would share future posts but have a different set of moderators so some posts might be visible in Context A but not in Context B but most of the posts would be available in both contexts.
Oh, okay, in that case that would fine. 🙂
May I ask how is moderation currently implemented?
Moderation as well as all of the logical tasks (gating mechanism for examples) are implemented at the Orbis infrastructure layer which is the layer being queried by front-ends (which we intend to decentralize at some point to let anyone run their own architecture).
I wonder if moderation could be done (in a scalable way) on Ceramic... Perhaps metadata added to a post that would signify that post has been censored in a certain project. Or a Moderation model for censored posts (although I'm not sure how scalable would that be).
Anyway, just some thinking out loud here. Hope it helps you find the best solution 😎