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.
I’m on Damus, I’m catching up on notes from this morning and then I get to about two hours ago and my feed just turns into a feed consisting of only nostr:npub1vp8fdcyejd4pqjyrjk9sgz68vuhq7pyvnzk8j0ehlljvwgp8n6eqsrnpsw and nostr:npub1cmmswlckn82se7f2jeftl6ll4szlc6zzh8hrjyyfm9vm3t2afr7svqlr6f posts and no one else.
😂🤷♂️🫂
nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s
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