Using a relay as a key-value store

[alexgleason]

Some popular relays like strfry use a key-value store (LMDB) as its database. But what if you could use strfry directly as a key-value store?

Why? Well, I don't know. My application uses a key-value store and I wonder if I can do everything through events.

Anyway, implementing get and set is easy. getMany is the hard part, because it's a range query and relays don't guarantee ordering.

But wait, they do! They order by created_at desc.

So we just have to encode the keys as created_at timestamps. We just need some fancy numerical key compression algorithm, or, to map keys to numbers manually. And yes we are limited by the JSON integer range. But then we can do range queries with since and until filters.

Is this good? Is this useful? Is this practical? No, not at all. It's not my best idea. But something about it burns in my brain so I can't help posting it.

[vitorpamplona]

This looks similar to #1168. I used kind 31200 to be rows of any database for a ruby application.

I think @wilsonsilva is considering something like that from this convo: wilsonsilva/nostr#13

[vitorpamplona]

But as of now, you can put all your app's key-value pairs as NIP-78 tags: https://github.com/nostr-protocol/nips/blob/master/78.md

[alexgleason]

I'm using NIP-78 heavily. A separate key-value store is needed when the dataset is very large, like statistics and extra indexes, and I can't afford to be pulling and updating the list that frequently.

[vitorpamplona]

It's hard to see key-value stores and large datasets in the same sentence. To me, if things are large or complicated, you shouldn't use key-value anymore.

Keep in mind that many relays have limits on the number of records they return in a query. If you save each key-value as an event, you might only receive 500 events or without having to force since/until filters to get the next 500.