Is it possible to control in composeDB which key dids are allowed to write?
For example, if a user has a valid secp256k1 key did, can the model / composite require composeDB to check a smart contract to see if the address is listed before allowing the user to write?
If not, is there any other way to achieve a similar result?
Hi @andyjagoe, thanks for your post, and apologies for the delay in getting back to you.
Couldn’t the dApp check this before allowing a user to write to ComposeDB?
Think of ComposeDB as a decentralized SQL database, so there isn’t any programmability.
Hi @mohsin,
This is an interesting question and one that has been on my mind as well. I fear your answer doesn’t solve the problem of write permissions as, although I could make sure my code checks for specific accounts before being able to write to the model, what is there to stop someone creating a script that spams data into the model themselves?
For the decentralised database analogy to hold, we need a solution that enables certain models to be restricted to specific accounts if needed. A great example of this is Streamr, which saves write permissions to a smart contract, and enables you to have public or private streams, so only specific accounts can write data to it.
For our application, we are looking for a decentralised database and, for the reasons above, Ceramic would not be suitable unless there were plans to implement write access controls at some point in the roadmap.
Thank you for the work so far but I’m really hoping you can see why no write access control options is going to prevent a lot of use cases. I wonder if you could shed some light on this @avi?
Hey Martin @mkc and Andy @andyjagoe - just captured both your feedback in our product backlog under “Access Control for Reads/Writes to a Stream.” Definitely understand the need for both privacy on the read side and eliminating low quality content on the write side.
Beyond access lists, would reputational filters also be helpful? Could be a softer approach than manual allows.
+1 this would be an amazing feature to have
The creator of the model can specify an allowlist of DID’s which are eligible to create new documents
Can you expand on the reputation filters? That could be interesting but how would it function in practice?
hey Justin, added you to the tally for better access control for reads/writes. right now this is one of our top two most requested features, along with custom query fields. We’re working hard to get ComposeDB on Ceramic ready for mainnet by ETHDenver, but this is high priority right after that.
So there’s one approach for access control where you explicitly grant read and write access to a DID. If your goal is privacy, this makes sense.
But another goal for access control some times is to limit clutter in the conversation - something @mkc has mentioned to me IRL. So maybe another approach is to allow everyone to read, but for writing use a reputational score from Gitcoin or EigenTrust based on on & offchain activity to filter out low quality responses at the app client level. Or even something like gating – where a DID/wallet must have participated in a DAO governance vote or a VC that they have the right skillset – to be able to contribute publicly.
So there are a few different ways to do write access control in Ceramic now and a few possible features that could be added.
One thing I would like to clarify is that a Model in ComposeDB defines a schema for data. Each use then creates their own stream and documents that conform to the schema in that model. This allows access control to happen at the level of applications. Essentially allowing two apps to share the same model but have different DIDs that they authorize to write.
What you can do now:
There are two ways you can limit writes today for a given model,
This would effectively remove the possibilities for non authorized DIDs to write data to your application. However, if someone uses a different application they could potentially write data that conforms to the model (I think this is fine in most cases because the data wouldn’t show up in your app anyway).
Possible future feature:
It could be reasonable to add a feature to ComposeDB that allows developers to set an ACL (or better yet, use object capabilities) that restrict which DIDs can write to a specific ComposeDB node. This would allow node operators to have strict control over their node, but not limit the usefulness of the model (e.g. data schema) to the rest of the community.
Hey Joel, appreciate your thoughts on this. I have a model for analytics data and I’d like anyone to be able to permissionlessly create a client to work with the data without worrying (too much) whether the data is invalid or spam (whether accidental or malicious). I think of this as similar to how it’s possible for multiple clients to exist for the same smart contract. What I’m currently doing is maintaining a list of valid DIDs in a smart contract and then checking the contract before using the data. It would be great if someone else building a client for this data didn’t have to check the smart contract and ComposeDB (or the Ceramic node) could be configured to do it instead.