alt Hacker NewsI'm a big fan of SQLite embedded nature, which allows for chaining multiple SQL calls with near-zero latency.
I'm currently building a personal knowledge graph server a mix of Notion's custom entities via JSON schema and Obsidian markdown+backlinked references. It's working well, but I suspect your product might be a better fit.
I do have one question regarding permissions: how would you recommend modeling a hierarchical access system in a graph database? Specifically, if a user is granted access to a document, they should automatically have access to all its child documents within that workspace. Is there a standard way to model this 'subtree' permission logic, or perhaps a more efficient approach you'd suggest?
Really impressed with the product good luck with it!
Replies
The permissions question is interesting. I think the answer depends on context. One approach would be to create some edge types `hasAccessTo` and `accessibleBy` that connect a user to a node. Then I'd create an edge type `childOf`. The rest is business logic. Permission checks can just traverse up to the first root node with permissions. The downside is this is all business logic, so can't really look at the database and understand this is how it works. Depending on the database you could create a function that returns permissions for any node, that encapsulates this logic.
Anyways, thanks for checking it out! Really appreciate it. Good luck with your project!
Modern authorization systems are often graph-based. Check out ReBAC and ABAC authorization models and also implementations like apache/casbin or authzed/spicedb. These schemas often have surprisingly simple graph definitions; I bet they could be replicated in LatticeDB without much trouble.