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

Show HN: Kvass, a personal key-value store

github.com

Post reply on HN
Print view View original

101–110 of 129 posts

Re: Show HN: Kvass, a personal key-value store

#101

Post by markstos »

chrisseaton wrote: post #37
markstos wrote: post #35

Earlier quoted context omitted.

Fair. The project could do a better job of explaining what benefit is it has over the file system API.

For example sharing a public link to a value. And syncing between file systems across a network is hard. (Before you say it's easy you can just do X, Y, and Z... remember that infamous Dropbox comment.)

It was easy to share public links to values hosted on the file system in 1995 with Apache. It remains easy today with Nginx and other web servers.

Syncing filesystems across networks with rsync has worked well for years.

If you are considering a personal key value store, you are probably already familiar with web servers and rsync. If not, they are two general purpose tools which are likely to be useful for other projects as well.

I was absent the day of the infamous Dropbox comment.

Re: Show HN: Kvass, a personal key-value store

#103

Post by chrisseaton »

markstos wrote: post #101
chrisseaton wrote: post #37

Earlier quoted context omitted.

For example sharing a public link to a value. And syncing between file systems across a network is hard. (Before you say it's easy you can just do X, Y, and Z... remember that infamous Dropbox comment.)

It was easy to share public links to values hosted on the file system in 1995 with Apache. It remains easy today with Nginx and other web servers. Syncing filesystems across networks with rsync has worked well for years. If you are considering a personal key value store, you are probably already familiar with web servers and rsync. If not, they are two general purpose tools which are likely to be useful for other pro…

> It remains easy

You're just parroting the original comment which was proven to be so so wrong in practice. Most people aren't able to / don't want to duck-tape random systems together like this.

I could snakily ask you what's the point of Nginx? Why not just run a dial-in BBS? Don’t you have the skills to do that? Why do you need this fancy Nginx and why did anyone bother writing it? That’s what you sound like.

There's value in building something that is integrated.

Re: Show HN: Kvass, a personal key-value store

#104

Post by DecoPerson »

makeworld wrote: post #93
maxmunzel wrote: post #19

Earlier quoted context omitted.

Thanks for the critique! I wanted to use symmetric crypto as its trivial to use without domains and certificates. The possibility of replays is a non-issue, as the key-value store is implemented as a CRDT and therefore all operations are idempotent. On the other hand, I didn't anticipate replay attacks in the design and thanks to your comment, I'll keep them in mind should I ever find myself in a scenario where they…

It doesn't matter if the operations are idempotent. The point is that an eavesdropper can replay a message that sets a key, for example, overwriting whatever was there previously. It would be better to use an established cryptography system. You could do self-signed certs with TLS, like Syncthing does. Or just use SSH.

If the CRDT part is done correctly, then replaying a message that sets a key will not change anything, ever.

If the message is:

Key: Foo

Reference CRDT node ID: 7654321 (the last node that the clients knows of that updated the value of ‘Foo’)

Operation: Update

Value: Bar

The ID of this new node: 1122112211

(Omitted for simplicity: Timestamps, hashes, …)

Replaying that message won’t do anything if the target already knows about the existence of that new node.

If the target didn’t know about the node, then I guess you’re helping them sync their own data? Maybe they owe you a thanks? If you knew what each encrypted message contained, you might be able to do some split-state shenanigans; for example: replay the message that sets a “PasswordAuthEnabled” key to “Yes” but deliberately omit the message that changes the “Password” key from its default of “password” to a genuine password. It’s very hard to imagine an actual situation like this occurring, but I guess that’s what makes crypto (and designing secure systems in general) so damn tricky. That and the math. And end users. And…

Re: Show HN: Kvass, a personal key-value store

#106

Post by pdpi »

apavlo wrote: post #7
tkindy wrote: post #4

I’m wondering what sorts of use-cases people would use a personal key-value store for. Maybe it’s just a useful foundation for building other tools on top of, like a password manager.

But it's just a wrapper around SQLite. Skip the middleman and just use SQLite.

Or don't skip the middleman and get a simple k/v interface instead of having to deal with a whole sqlite database.

Re: Show HN: Kvass, a personal key-value store

#107

Post by Skunkleton »

rscrawfo wrote: post #90
vorticalbox wrote: post #63

Earlier quoted context omitted.

That is true, its just not as widely used as I would have hoped.

I feel like that has changed over the past few years. Many restaurants in my area started using them for menus, and I recently saw them used to setup wifi while on vacation.

I just paid my lunch tab by scanning a QR code on a receipt, and then tapping Apple Pay. It was rad.

Re: Show HN: Kvass, a personal key-value store

#108

Post by Skunkleton »

dheera wrote: post #55

In case anyone is wondering about the name, it's a Slavic fermented bread drink that's much less alcoholic than beer (and commercially canned versions are near zero alcohol). It's one of my favorite chilled summer drinks, and you should be able to find it in Slavic stores in the US as well.

There is a cold cucumber soup that uses kvass as its base. I would recommend giving that a try as well.

Re: Show HN: Kvass, a personal key-value store

#109

Post by dheera »

Skunkleton wrote: post #108
dheera wrote: post #55

In case anyone is wondering about the name, it's a Slavic fermented bread drink that's much less alcoholic than beer (and commercially canned versions are near zero alcohol). It's one of my favorite chilled summer drinks, and you should be able to find it in Slavic stores in the US as well.

There is a cold cucumber soup that uses kvass as its base. I would recommend giving that a try as well.

Okroshka? Yeah I love that stuff. I'm vegetarian, replacing the sausage with a vegetarian one (or leaving it out) works well. I followed this recipe:

https://www.youtube.com/watch?v=ifE7gDiLDbE

The Life of Boris also has a great video on making Kvass:

https://www.youtube.com/watch?v=k1UTJKBMvgc

though I haven't gotten around to trying it, I've only had commercial bottled and canned ones. I imagine if you make it yourself you'll have a slightly more alcoholic outcome.

Re: Show HN: Kvass, a personal key-value store

#110

Post by makeworld »

DecoPerson wrote: post #104
makeworld wrote: post #93

Earlier quoted context omitted.

It doesn't matter if the operations are idempotent. The point is that an eavesdropper can replay a message that sets a key, for example, overwriting whatever was there previously. It would be better to use an established cryptography system. You could do self-signed certs with TLS, like Syncthing does. Or just use SSH.

If the CRDT part is done correctly, then replaying a message that sets a key will not change anything, ever. If the message is: Key: Foo Reference CRDT node ID: 7654321 (the last node that the clients knows of that updated the value of ‘Foo’) Operation: Update Value: Bar The ID of this new node: 1122112211 (Omitted for simplicity: Timestamps, hashes, …) Replaying that message won’t do anything if the target already k…

I see, thanks. I was focusing on the "idempotent" part but yeah a CRDT would protect against replays. Still not a great design though, still opens yourself up to issues, in case not all messages are part of the CRDT, or you have a buggy CRDT implementation.
Post reply on HN