Hacker News Reader

Comment by Horos | Hacker News Reader

Nice try — the local-first distributed pattern worth building on.

Three questions:

Why blockchain for access rights? A signed Merkle structure or a Certificate Transparency-style log would give the same guarantees without the operational complexity. What does the blockchain add here that a simpler append-only signed registry doesn't?

The threat model is unclear. If the blockchain provider controls validation, the "accessible only to end users" guarantee depends on trusting that provider. This is the oracle problem — the chain guarantees integrity of what's inside it, but not the truthfulness of what gets written in. Who runs the chain, and what happens if they're compromised or write false access rights?

Go is listed first in the bindings but the example code is Python. Is the Go binding at feature parity, or is Python the primary target?

View on HN

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.

Thanks for sharing — always a pleasure to discover what others are building.

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.

Reply on news.ycombinator.com