Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

electric-sql.com

Post reply on HN
Print view View original

111–120 of 173 posts

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#111

Post by westurner »

jchw wrote: post #87
klabb3 wrote: post #84

Earlier quoted context omitted.

You can always encrypt local data even if the metadata is not encrypted. But that restricts it to the device itself by default, not even your other devices on the same account can read it. If you want encrypted and shared with other devices or users you have to surface key management to users which is very difficult to do. Signal and a few others do this but they’re very bespoke to the specific business logic. To pro…

I'm not asking for the problem of key derivation to be solved by ElectricSQL per se, just wondering if it can handle E2E encrypted data in any way. That said, I disagree with how difficult it is: there are a lot of approaches that are not too ridiculous. For example, a simple approach to E2EE is to use a PAKE like SRP to do password authentication, then since the password is kept secret, you can use a normal KDF to d…

[IETF] "RFC 9420 a.k.a. Messaging Layer Security" does key revocation and rebroadcast fwiu https://news.ycombinator.com/item?id=36815705

W3C DID pubkeys can be stored in a W3C SOLID LDPC: https://solid.github.io/did-method-solid/

Re: W3C DIDs and PKI systems; CT Certificate Transparency w/ Merkle hashes in google/trillian and edns, keybase pgp -h, blockchain-certificates/cert-verifier-js,: https://news.ycombinator.com/item?id=36146424 https://github.com/blockchain-certificates

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#112

Post by jchw »

westurner wrote: post #111
jchw wrote: post #87

Earlier quoted context omitted.

I'm not asking for the problem of key derivation to be solved by ElectricSQL per se, just wondering if it can handle E2E encrypted data in any way. That said, I disagree with how difficult it is: there are a lot of approaches that are not too ridiculous. For example, a simple approach to E2EE is to use a PAKE like SRP to do password authentication, then since the password is kept secret, you can use a normal KDF to d…

[IETF] "RFC 9420 a.k.a. Messaging Layer Security" does key revocation and rebroadcast fwiu https://news.ycombinator.com/item?id=36815705 W3C DID pubkeys can be stored in a W3C SOLID LDPC: https://solid.github.io/did-method-solid/ Re: W3C DIDs and PKI systems; CT Certificate Transparency w/ Merkle hashes in google/trillian and edns, keybase pgp -h, blockchain-certificates/cert-verifier-js,: https://news.ycombinator.co…

Oh, thanks for this, I hadn't heard of RFC 9420 until now and it looks very interesting.

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#113

Post by roncesvalles »

obeavs wrote: post #109

Huge congrats to the team. I reached out to them four or five months ago as we explored offline-first frameworks, and its awesome to see how far they've come in a short time. We didnt find anyone else who was tackling the tie between client-side SQLite, an open source CRDT/sync layer, and Postgres. We found a few who were attempting to manage this in a closed source way, but it didn't make sense to give up control of…

Conceptually sounds like this is what Firebase, Couchbase Lite, and Mongo Reach do in the NoSQL world.

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#115

Post by roncesvalles »

brigadier132 wrote: post #83

I'm curious, CRDTs are good for having data converge in the same state but not necessarily ensuring that the state it converges to is "correct". How does this solve that?

You can't guarantee "correctness" (if you define that as zero information loss and/or external causal consistency) in any multi-leader system partly because of unsynchronized clocks and partly because, well, you have to deal with the conflict somehow. You can think of CRDT as a tool to minimize relevant information loss (ideally to zero) when two concurrent writes are converged.

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#118

Post by icehaunter »

nathancahill wrote: post #72
samwillis wrote: post #66

Earlier quoted context omitted.

Not at all, it's perfectly possible to use it with Angular. While we haven't built any specific helpers for Angular, like we have for React, our TypeScript client is perfectly useable from any JS/TS framework or project.

What does the local client side look like? Could it be wrapped in a node daemon to sync to a local SQLite file?

Hey, one of the devs here! JS library already works with Node via `better-sqlite3` library. We provide a way to set up listeners to data changes, or you can just start up a node client and do some work periodically on the synced data.

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#119

Post by klabb3 »

jchw wrote: post #87
klabb3 wrote: post #84

Earlier quoted context omitted.

You can always encrypt local data even if the metadata is not encrypted. But that restricts it to the device itself by default, not even your other devices on the same account can read it. If you want encrypted and shared with other devices or users you have to surface key management to users which is very difficult to do. Signal and a few others do this but they’re very bespoke to the specific business logic. To pro…

I'm not asking for the problem of key derivation to be solved by ElectricSQL per se, just wondering if it can handle E2E encrypted data in any way. That said, I disagree with how difficult it is: there are a lot of approaches that are not too ridiculous. For example, a simple approach to E2EE is to use a PAKE like SRP to do password authentication, then since the password is kept secret, you can use a normal KDF to d…

I don’t disagree with your technical assessment per se but I would would not label any of this “pretty simple”, except for special purpose apps with technically competent users.

Academically it’s in a decent state, but tech- and UX wise I’d say it’s immature. It virtually penetrates all layers of a normal stack (including layer 8). For apps it’s at least possible but the web is very tricky as a platform for anything e2ee without absurd usage requirements.

The tech choices that remain after deciding on an e2ee model are severely limited and language dependent, and spans deeply across persistence layers, software updates, authn, authz, social graphs, moderation etc etc. And even so, there are many subtleties in terms of privacy and information leakage that are often necessary compromises for features that many apps take for granted today. Without any social aspects it’s significantly easier (eg PAKE is best suited for for interactive/online two-party operations).

Re: Show HN: ElectricSQL, Postgres to SQLite active-active sync for local-first apps

#120

Post by kiwicopple »

doctorpangloss wrote: post #24
thruflo wrote: post #14

Earlier quoted context omitted.

Hey, You can see our database rules spec here: https://electric-sql.com/docs/api/ddlx We haven't implemented it all yet but you can see the intention / direction. It's similar to RLS but adapted for the context. Connections are authenticated by signed JWT: https://electric-sql.com/docs/usage/auth We also auto-generate a type-safe data access client from the electrified subset of the Postgres schema. This applies type…

> It's similar to RLS but adapted for the context. I'm visiting the docs. > ...This must have at least a user_id claim, which should be a non-empty string matching the primary key UUID of the authenticated user... You should probably strike this from your docs. It sounds like you are still figuring out how this should work. The "right" answer is to author an OIDC authentication module for Postgres and license it in a…

> Projects like postgrest have been down this journey and spell out their solutions. It's all a little vague with Supabase

Just in case it's not entirely clear: supabase is just PostgreSQL + PostgREST. We contribute to + maintain PostgREST, so if it works with PostgREST it also works with Supabase.

> there isn't anything magical about their authorization approach either

I 100% agree with this, and that's intentional. We don't want to do anything special here, we want our solutions to be as interoperable as possible with existing approaches

Post reply on HN