marcus-pousette
commented
1 year ago The main idea is that every peer need to run their own checks for every commit to verify whether a party can modify a state or not. This means in practice if every party is running the same ACL logic the state would end up to be the same for everyone. However if you don't assume that we can trust parties then there are multiple answers to this question depending on what kind of reliability you want. One way is to define an ACL database with Peerbit itself, then you bind this database with the canAppend and canRead hooks that you can access on setup with your database in mind, like this:
@variant("document")
class Document {
@field({ type: "string" })
id: string;
constructor(props: { id: string }) {
this.id = props.id;
}
}
@variant("test_store")
class TestStore extends Program {
@field({ type: Documents })
store: Documents<Document>;
@field({ type: IdentityAccessController })
accessController: IdentityAccessController; // IdentityAccessController is part of Peerbit standard lib
constructor(properties: {
id?: string;
identity: Identity;
accessControllerName?: string;
}) {
super(properties);
this.store = new Documents({
index: new DocumentIndex({
indexBy: "id",
query: new RPC(),
}),
});
this.accessController = new IdentityAccessController({
id: properties.accessControllerName || "test-acl",
rootTrust: properties.identity.publicKey,
});
}
async setup() {
await this.accessController.setup();
await this.store.setup({
type: Document,
canRead: this.accessController.canRead.bind(this.accessController),
canAppend: this.accessController.canRead.bind(this.accessController),
});
}
}Now you might think: If the ACL of one database is defined by another database, what defines the ACL for that database?
The IdentityAccessController database/program is uniquely defined by its rootTrust publicKey, which is basically the creator of the access controller. When someone wants to add a permission to IdentityAccessController it either has to be signed by the root trust, or it has to be signed by an identity that has been trusted by the root trust (trust chain).
The hash of the program TestStore will uniquely be defined by the rootTrust of the accessController if you keep other properties constant, this means, anyone who opens TestStore by its CID will be sure that everyone else that also have it open, will observe the same root trust for the access controller. If someone tries to change the rootTrust for the ACL then all programs that rely on it will change because the hash will change, which means that it is impossible to do that without changing the address for the whole program itself.
With this way of dealing with trust, you can ~ be sure ~, or at least assume that everyone who is writing to TestStore that are part of the ACL canAppend also respects the access controller. In extension, this means that if you search for data that is defined in TestStore and make sure that you verify that the responses are signed by members of the ACL, then you can be "somewhat sure" that query responses are accurate. If you want to make sure that a party is not behaving maliciously just for your particular query, you would aggregate responses from many peers that are part of the ACL and make sure that there is a consensus about what the response should be for a particular query.
A simple example is a database that is a counter. If you query the database to check what the counter is, you could wait for at least 70% of the network to send you a response, then you could take the median value as the true value for your particular query/observation.
If you want to write an application that does not assume any kind of trust, you need to replicate all content by yourself, on your devices. If you are writing an application where resilience is not that important you can just make sure that you approve and reject commits as they come with your local ACL logic.
TheRook
How does peerbit make sure that a user can add a data record to the database, and make sure no one else removes it or modifies it? If i am not mistaken peerbit and orbitdb expects users to be trusted when modifying a shared collection.
A Merkel-CRDT can be used to make it hard to deny that data was ever seen and provides some source of truth without a full blockchain: https://research.protocol.ai/publications/merkle-crdts-merkle-dags-meet-crdts/psaras2020.pdf https://github.com/ipfs/go-ds-crdt