Hacker News Reader

Comment by dariosalvi78 | Hacker News Reader

this is great, thanks for launching it, I may actually be a future user of yours ;)

one important feature I see missing is that one cannot run queries with comparisons, such as "give me any message sent between 2022-10-10 and 2023-02-01". This would be very important when one doesn't have all the keys, or when the keys are too many, like in the messages example above.

Any idea for this kind of scenario?

View on HN

Thanks! Yup, it's not always practical to make a huge number of queries when you expect many of them to come back empty. Instead, we first perform private lookups against a Bloom filter, to find out which keys actually hold data (e.g. messages). Then, we privately retrieve only the useful keys.

The Bloom filter is also served over Blyss, so the server still learns nothing about which keys you're interested in. We implemented this system for our private password checker, which tests passwords against almost a billion breached credentials: https://playground.blyss.dev/passwords

Thanks for the answer, but I was meaning from your customer perspective. My understanding is that you offer a key-value store, so the only operation available on the encrypted data is a comparison (==).

If my application wants to retrieve data within a certain range (< and > operators) is there anything I can do to implement it on top of you SDK?

Think of the encrypted messages app: how can I retrieve this month's messages using your SDK?

I hope this clearer now...

Yeah, we don’t natively support range queries.

The simple way to efficiently do this kind of check would be to store an index of keys (perhaps chunk them into buckets, like 0-10, 10-20, etc), and then privately retrieve the individual items. Retrievals are fast, especially when batched, so if the ultimate number of items you’re trying to retrieve is not too large, this can work.

If you want to chat more about range queries, feel free to email us (founders @ blyss.dev)

You can store the nodes of a search tree (e.g. with three levels year/month/day) on Blyss and use that. Of course you’d need to maintain that search tree yourself.

yes, I was thinking about the same, basically the search functionality would be on me. If one has an estimation of how frequently data come in (if the search is done on time) then one could find the best approach for keeping those trees within reasonable size, maybe with a multi level approach, as you suggest.

A generic functionality that would adapt to all situations would be nicer. Maybe Blyss could offer some libraries for that?

Reply on news.ycombinator.com