Well, part of the reason is that relay.damus.io is running an old version of strfry that has a quirk in it. It will return sets of events that are ordered by pubkey instead of by timestamp.. so it can lead to this type of behavior from requests that return large sets.

Reply to this note

Please Login to reply.

Discussion

Thank you for the explanation!

Haven’t upgraded yet because its a pita to compile

I've been deploying it using the docker image converted to a systemd-nspawn container.. that way it always compiles ez and doesn't care which version of Linux is on the host system. Lmk if you want some nspawn configs..

The steps are roughly like this:

docker build

docker create

docker export

machinectl import-tar

machinectl enable

machinectl start

Tho ya you also will have to export and import the db.. which I imagine will take a while on damus.. so not the easiest upgrade to pull off.. you can do it with minimal downtime by starting the new version side by side and running an initial export, then importing to the new while the old one runs, and then running a stream to catch up .. but yea, all very time consuming heh. 🤙

Uhhhh yeah that will probably take a long time if I have to migrate

Ya the export can be run on a live strfry and is fast, the import is what takes a really long time.

The strfry database seems super complex. Why just not go with a “conventional” DB, like SQLite, or SQL server (with ODBC connection)? Me, I use a JSON array of Nostr events as “database”, with linear search :-) . This is a database with one record. Simple (also happens to be my first ever Nostr post) https://github.com/pedro-vicente/nostr_client_relay/blob/main/database/database.json

Damus used to run on sqlite but it couldn’t handle the load, even with optimized queries. lmdb is the only thing that doesn’t fall over atm.

Got it. I just created a fork of your new database and will try to do that CMake build and Windows port soon. Curious about the performance, and it seems so simple (I like simple things). Cheers. https://github.com/pedro-vicente/nostrdb

windows patches are welcome. Right now i just have the data structure that I’ve already mapped to data types within Swift/damus. The lmdb bit is coming soon.

Here you go. Started with just a CMake script that defines a library used by ‘test’ and ‘bench’. Tested in Linux and made a pull request. The ‘test’ program fails with an assertion by the way. CMake is just a must have build tool for cross compiling https://github.com/damus-io/nostrdb/pull/1

Hey, I made a new pull request that has more CMake support for the secp256k1 lib, do you have time to merge it? Thanks (Sent from Nostur for Mac, neat desktop client) . https://github.com/damus-io/nostrdb/pull/2