I just tagged 2 strfry releases: 0.9.7 and 1.0.0-beta1

1.0.0-beta1 is a candidate release of strfry 1.0.0 -- help is needed testing!

The internal strfry DB version has been increased to 3, which means that you will need to rebuild your DBs to use this new version.

0.9.7 has some bugfixes and changes that accumulated in master, and has a "strfry export --fried" feature that can be used to create DB exports that can be rapidly imported by 1.0.0 series releases.

The full changelogs are available here: https://github.com/hoytech/strfry/blob/1f34794945cf380035822278c46070a9923129f3/CHANGES

Thank you to everyone who contributed and helps testing! If you need help or run into any issues, reply on nostr or stop by our telegram channel.


the man, the myth, the legend 🐳🐳🐳

nostr:nevent1qqs8vx9y325lnlv3zyqrq75al27rsdpkg04kfy06awmdjsl3acvqx3sppemhxue69uhkummn9ekx7mp0qgszrq3cgvfe89vadjrp0gaa3xfs82txpx6y5ezwjuufzqu20h5xytgrqsqqqqqpvjt6dq


Last release, 1 years ago. Welcome back 🫂


Thank you Doug 🙏

/cc nostr:npub10pensatlcfwktnvjjw2dtem38n6rvw8g6fv73h84cuacxn4c28eqyfn34f


thank you!!!!!!!


thank you & welcome back! 🫡

does the following mean strfry will be continuing to relay when there is an import (in the past it was stopping to relay):

- Switch import to use WriterPipeline


Thanks!

This change shouldn't make much difference in import's behaviour. Because import pretty much constantly has a writer lock, relay *write* operations will be blocked/delayed (and may timeout), but *read* operations should continue as normal.

We could make import release its lock for a few milliseconds periodically so that write operations can go through. I'll look into doing that.


please don’t remove prefix matching 😢 such a neat way to find notes with proof-of-work which i use for getwired.app nostr:note1cwn6dnunqqllp7gwt7t2yh3ffscrllru740alph5hazvvt8znwds3zggv0 https://image.nostr.build/63e6961d329cff3d471abbbf3426a1f07ad2e174c133a13b0553de0bfe59ad22.jpg


Heh yeah that is a pretty cool use-case actually.

But this feature was removed from NIP-01 and strfry tries to follow the spec as close as possible, so take it up with the nostr CEO. ;)


Updated from 0.9.6 to 0.9.7, export with --fried. Updated to 1.0.0-beta2 and imported with --fried. Everything worked perfectly and super fast.

wss://relay.piazza.today

Thanks a lot for making strfry


Glad to hear! Thanks for letting me know, I appreciate it!


nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 🧎♂➡🕋


Yes, it is all my fault. But again, I don't think it's worth having this complicated and inefficient feature just to support this use case that is much better served by special relays.


> help is needed testing!

Here is help testing:  https://github.com/mikedilger/relay-tester


Thanks, I'll give it a try!

I should mention that the existing tests and the differential fuzzing described in the strfry README pass on the 1.0 series, naturally.


Cool.  I should mention that relay-tester isn't complete, it only does 67 of it's 103 planned tests.  But it is already useful.

Be aware that NO is not a failure.  Requirements are scored as PASS/FAIL.  YES/NO is just informative about a particular question.


question: how long does strfry wait before getting an answer from write policy script?

you already said the answers can come in mixed order right. the script does not have to answer in the order received.


It waits forever, so plugins should ensure they do any timing out on their side. I have a debugging script that can be used to detect a stalled/missing response. More info in this issue: https://github.com/hoytech/strfry/issues/112

Currently strfry always waits until it gets a response about the previous event before sending another request, so the order is not applicable. Eventually I might make the implementation asynchronous in which case yes, mixed order would be acceptable. This is why the event ID must be included in a plugin reply even though technically it's not needed today. I clarified this in the docs: https://github.com/hoytech/strfry/commit/d2d8dc7572e63d74caf1810673981add47c9f328