|
|
|
|
|
|
by francink
99 days ago
|
|
|
Hi Horos,
thanks for your comments. I really appreciate! 1. Perhaps I am misusing the "blockchain" term. The access is granted with signed blocks. Each block can introduce some changes, like granting/removing access to other users, including the encryption key with an envelope. Each block links to the previous via hash. There is no consensus mechanism. 2. The vault is defined by a storage and the public keys of the creator. A client must know in advance the creator keys and he will use those keys to verify the signature. The creator then can grant admin rights to other users with specific blocks. An access grant not signed by an admin, will be rejected by a user. It is not really about data truth, because the target is more information exchange. Does it answer the question? 3. Go is the implementation language, not really a binding. I use Python in the first example because it is more compact. However the guide shows samples for all supported languages. The primary target is Go for server side and Dart for mobile. Python is effective for samples and experiments. |
|
|
A few thoughts after your answers:
The E2E file sync part has existing solutions, and your access rights system is really a signed append-only log rather than a blockchain (no consensus, no decentralization) — which is fine, but the term might create misleading expectations.
What I'm more curious about is the access model itself. How are access tokens created and transferred? Who consumes them, and how does authorization propagate? Have you considered a salted API where each user carries a unique identifier, so the whole grant/revoke/delegate flow goes through a single unified mechanism regardless of what's being accessed?
The SQL sync layer is what actually caught my eye — I've worked on similar problems for specific use cases, and encrypted database sync between peers is a genuinely hard problem. That feels like your real differentiator.
On that note: does the SQL layer reference the file content or file paths? I'm guessing you built both interfaces because they're correlated — the SQL holds structured data that points to the encrypted files. If so, that's worth making explicit, because right now they look like two unrelated features rather than two sides of the same system.