2023-01-09T20:57:31Z https://nostr.now Doug Hoyte https://nostr.now/npub1yxprsscnjw2e6myxz73mmzvnqw5kvzd5ffjya9ecjypc5l0gvgksh8qud4 https://nostr.now/nevent1qqsgejmv4xzfln88pwrvtpv9vtst3l2yxt5dhhnumxfg5d55d26gjzgzyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6x9el2y In reply to <a href='/nevent1qqs9z3c280hal05xwxw3gukrt0sgj7ahkw2mxxfzl5n34stvweuuu8cuy74dl'>nevent1q…74dl</a><br/>_________________________<br/><br/>I think clients must be written to handle the case of individual relays missing/deleting data. If you&#39;re low on disk-space, not much choice!<br/><br/>You could have some kind of heuristics that delete unneeded notes, and keep the important ones (whatever that is for your use-case). 2026-04-10T13:05:21Z https://nostr.now/nevent1qqsynxff8znwrrdtacujkw5wenl0lneaujmznqzdvqxt7xm3qh4jgugzyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6h4elf2 In reply to <a href='/nevent1qqs9rzzcutru78h6c8pv708cjwl0ylqpfnqs2qnxknsrxc627tkq7kqfhak26'>nevent1q…ak26</a><br/>_________________________<br/><br/>This is the first I&#39;m hearing of it. Can you please point me to any more details? I don&#39;t see anything related to negentropy in the commits you referenced. 2026-03-19T17:43:52Z https://nostr.now/nevent1qqsff4a3ansvwmpdvj62lelrk46r3t6ys67294vwtlfx3grscu2y4fszyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z697nlqn strfry 1.1.0 release<br/><br/>There are a lot of changes in this release. Some highlights:<br/><br/>* Preliminary support for AUTH (NIP-42)<br/>* Support for COUNT requests (NIP-45)<br/>* Prometheus monitoring end-point<br/>* REQ filter validation: restrict which filters your relay will service<br/>* Configure your relay.info with npubs instead of 32-byte hex (optional)<br/>* Timeout-support for plugins to detect and recover from plugin hangs/crashes<br/>* Deletion of parameterised replaceable events now follows NIP-09<br/>* upload/download convenience commands to transfer notes to/from remote relays<br/>* Improved error messages for both external users and admins<br/>* Many small bugfixes and convenience features<br/><br/>See here for the full list: <a href="https://github.com/hoytech/strfry/blob/master/CHANGES">https://github.com/hoytech/strfry/blob/master/CHANGES</a><br/><br/>Thank you to everyone who contributed!<br/><br/>There are no backwards-incompatible DB changes, so it should be a drop-in replacement for the 1.0.0 series. However, we always recommend backing up your DB first just in case.<br/><br/>One thing to note: We are deprecating the `strfry stream` command. `strfry router` does everything stream did and much more. 2026-03-19T14:29:58Z https://nostr.now/nevent1qqsyw9rxm9u7px0tm4g68crt4eq3wwqul9ecnjcammyl4auhvtvfr7gzyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6u7uae9 In reply to <a href='/nevent1qqsxaa2xk9hadfym4xg6ksmu7j9nse4u9mmjt0txz072cs6538tehgqrt6sy5'>nevent1q…6sy5</a><br/>_________________________<br/><br/>I believe they are working as per spec, but please let me know if not.<br/><br/>The beta-series finally implements the deletion of parameterised replaceable events with a-tags: <a href="https://github.com/hoytech/strfry/issues/168">https://github.com/hoytech/strfry/issues/168</a><br/><br/>Is there anything in particular you&#39;re wondering about? 2026-03-15T22:35:10Z https://nostr.now/nevent1qqs0gtc7hxchp0fg52c38xgkdydhhhpggfmg88w7wu7f6shvm5nr9qszyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z69e9498 In reply to <a href='/nevent1qqsre8vaxmwmd7sxz9ygq46um4crevyhuxy6kxfsaa5j3pmhn6zj4mcaw7lec'>nevent1q…7lec</a><br/>_________________________<br/><br/>You&#39;re welcome! Let me know if there&#39;s anything you&#39;d like me to implement. 2026-03-15T22:31:28Z https://nostr.now/nevent1qqspqekzel8ex5vj0fyfws6wfs858cgphfjsesd47223r22kd3puu7qzyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6smzmmr strfry 1.1.0 beta series:<br/><br/>I&#39;m working on a new release of strfry and there are some beta releases tagged in case anyone wants to give them a try. There are lots of changes in the queue. I&#39;ll write them up in more detail soon.<br/><br/>For now here&#39;s a small new feature in 1.1.0-beta4: --range option for sync. Basically it&#39;s a convenience feature for specifying since/until in your filter. Examples:<br/><br/>strfry sync wss://blah.com --range 1h-<br/><br/>^^ sync just last hour of notes<br/><br/>strfry sync wss://blah.com --filter &#39;{&#34;kinds&#34;:[0]}&#39; --range 1Y-6M<br/><br/>^^ sync kind 0 events between 1Y and 6M old<br/><br/>This is especially useful for &#34;paginating&#34; big syncs. You can first do 2M-1M, then do 3M-2M, then 4M-3M, etc. 2026-03-15T14:33:10Z https://nostr.now/nevent1qqspmraxsvv2a784nan0vwryud4m98fy44lf3s8p02c66wnvz9vgkdczyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z63epsu7 In reply to <a href='/nevent1qqsfvc3rlzph2s96znms8eqrdh5uhgpfrk3yjh9z36wrpedd6lt6y0cnhfxrq'>nevent1q…fxrq</a><br/>_________________________<br/><br/>Here&#39;s the video of it in action, it&#39;s awesome!<br/><br/><a href="https://www.youtube.com/watch?v=rN7HYXmgxzk">https://www.youtube.com/watch?v=rN7HYXmgxzk</a> 2024-12-24T17:49:57Z https://nostr.now/nevent1qqsgn64g50qd374glmufznwnehgmdwgd3w5u02377rs0qnuxh0j377qzyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z62xd6dy In reply to <a href='/nevent1qqszmt7ccaxrhltx8z0kwp3u5ldqlvwv85yyk7f3n227x5ugfclelvc986tse'>nevent1q…6tse</a><br/>_________________________<br/><br/>Yep looks like the same approach to me. 2024-12-20T19:44:48Z https://nostr.now/nevent1qqs2l8z8d0hr0h8de687p55klpa386649urqkkrxgch9cg9l282d4aczyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6hlxspm In reply to <a href='/nevent1qqs9307ld60jj7h8sqyf73za54jjcvk504ls0vcu3aw8u26jnq6h7uc0lrp3h'>nevent1q…rp3h</a><br/>_________________________<br/><br/>The answer to this is surprisingly complicated.<br/><br/>TLS can optionally support compression which would most likely have universally worked for all wss:// connections. However, this was disabled in OpenSSL and other TLS libraries because of a critical information leakage that arises when secret and non-secret information are combined in the same compression context: <a href="https://blog.qualys.com/product-tech/2012/09/14/crime-information-leakage-attack-against-ssltls">https://blog.qualys.com/product-tech/2012/09/14/crime-information-leakage-attack-against-ssltls</a><br/><br/>HTTP-level compression does not apply to websockets (since its framing replaces/upgrades the HTTP framing) so instead compression is specified by the websocket RFCs. It is optional, so not all clients support this.<br/><br/>Websocket compression happens per message, and can use an empty window for each message, or can have a &#34;sliding compression&#34; window where messages are effectively compressed with previous messages. Some implementations will support both of those modes, some only one, and some neither. Even if an implementation supports compression, it may choose not to use it, and/or may use it only for particular messages (and not others). Furthermore, in the websocket compression handshake, bi-directional window sizes need to be negotiated and sometimes windows cannot be negotiated in one or both directions.<br/><br/>Almost all browser websocket clients support full compression with sliding windows in both directions, and so does strfry. The sliding window has a relatively large memory overhead per connection, so it can optionally be disabled. The compression ratios can be seen in the strfry logs.<br/><br/>Although strfry &lt;&gt; browser connections are almost always compressed both ways, different clients and relays have different levels of support and often can&#39;t negotiate optimal compression. 2024-09-14T00:22:34Z https://nostr.now/nevent1qqs8wkse4lcxx8g300qzmwjk3092udng4f30hzpfjjd6kjuzfeykh3czyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6kd4kxm In reply to <a href='/nevent1qqsr4uuejxs54ws6dxy77yklg4xkxvlqygnp4uwxqhnru3fac4jsk5gftqjk7'>nevent1q…qjk7</a><br/>_________________________<br/><br/>&gt; If you’re sending binary, base64 only inflates by 33% compared to hex strings’ 100%.<br/><br/>On purely random data, after compression hex is usually only ~10% bigger than base64. For example:<br/><br/> $ head -c 1000000 /dev/urandom &gt; rand<br/> $ alias hex=&#39;od -A n -t x1 | sed &#34;s/ *//g&#34;&#39;<br/> $ cat rand |hex|zstd -c|wc -c<br/> 1086970<br/> $ cat rand |base64|zstd -c|wc -c<br/> 1018226<br/> $ wcalc 1086970/1018226<br/> = 1.06751<br/><br/>So only ~7% bigger in this case. When data is not purely random, hex often compresses *better* than base64. This is because hex preserves patterns on byte boundaries but base64 does not. For example, look at these two strings post-base64:<br/><br/> $ echo &#39;hello world&#39; | base64<br/> aGVsbG8gd29ybGQK<br/> $ echo &#39; hello world&#39; | base64<br/> IGhlbGxvIHdvcmxkCg==<br/><br/>They have nothing in common. Compare to the hex encoded versions:<br/><br/> $ echo &#39;hello world&#39; | hex<br/> 68656c6c6f20776f726c640a<br/> $ echo &#39; hello world&#39; | hex<br/> 2068656c6c6f20776f726c640a<br/><br/>The pattern is preserved, it is just shifted by 2 characters. This means that if &#34;hello world&#34; appears multiple times in the input, there may be two different patterns for it in Base64, but only one in hex (meaning hex effectively has a 2x larger compression dictionary).<br/><br/>Since negentropy is mostly (but not entirely) random data like hashes and fingerprints, it&#39;s probably a wash. However, hex is typically faster to encode/decode and furthermore is used for almost all other fields in the nostr protocol, so on the whole seems like the best choice.<br/><br/>&gt; Personally, I’d prefer to see the message format specified explicitly as debuggable JSON, if feasible.<br/><br/>This is theoretically possible, but it would be very difficult to interpret/debug it anyway, and it would add a lot of bandwidth/CPU overhead. 2024-09-13T21:23:19Z https://nostr.now/nevent1qqsylffc9whpup0ryvzhaje7czkxa5p4fk6ccvctjrt8t9e2wh82keqzyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6pqxmnt In reply to <a href='/nevent1qqswtzpzlmqjenzjjw4udx8ft6eax3awvpduhlpspc3r6ulyknvdfwg0sukg6'>nevent1q…ukg6</a><br/>_________________________<br/><br/>The best way is to first upgrade to 0.9.7, which is the latest release in the 0.9 series. This has the &#34;--fried&#34; option for export (but not import).<br/><br/>After you have the fried export, upgrade to 1.0.0 and import with &#34;--fried&#34; too.<br/><br/>Sorry for the trouble, but it will save a *lot* of time versus normal import! 2024-09-13T19:36:02Z https://nostr.now/nevent1qqsff0hau7guqc6dpaeplajqm652yzyldnax52lxu5vswlmff2vg9nczyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6htnpup In reply to <a href='/nevent1qqsvpafepk9n3jxw95zk5dnu8ymaddx3kp93tundmu273jlh9dmnz9gqj2h7n'>nevent1q…2h7n</a><br/>_________________________<br/><br/>NIP-77 I believe is still a draft/work-in-progress, so I don&#39;t know the final form yet.<br/><br/>I think fiatjaf&#39;s intent was just to standardise the nostr integration, rather than negentropy as a whole. I guess this is similar to how JSON/SHA256/secp256k/etc are not themselves specified in NIPs, but instead external specifications are referred to. That said, the negentropy spec is relatively straightforward and there are already at least 5 implementations (and I know of some more in development too): <a href="https://github.com/hoytech/negentropy/tree/master?tab=readme-ov-file#definitions">https://github.com/hoytech/negentropy/tree/master?tab=readme-ov-file#definitions</a><br/><br/>&gt; It also doesn’t seem to cover the actual sending of events in either direction (after the sets have been reconciled).<br/><br/>True, but by design this is out-of-scope of the negentropy protocol. Negentropy just performs a set reconciliation so the client knows which IDs it has and/or needs. It is then up to it to decide what to do. Currently `strfry sync` will post events it has with regular EVENT messages, and/or download events it needs with regular REQ messages.<br/><br/>However, there are a lot of other possibilities. If a client is only interested in uploading (or downloading), it may only do one of those actions. In fact it may just store those IDs and fetch them later, or through some other relay or mechanism. Alternatively, if a client doesn&#39;t actually care about the event contents and is only trying to compute an aggregate &#34;reaction count&#34; across relays, it may never actually download the events, and purely use negentropy for de-duplication purposes. 2024-09-13T19:33:28Z https://nostr.now/nevent1qqspdtx43t6kvtw5rgwe2e0c0egxhhcgpza25tys88gyph4v7p642eqzyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6h5yuh9 In reply to <a href='/nevent1qqsx772kxjrtp7luzwmmkcr0ay0c7d2l5dmagheycef2xpt29c7askgxfe0yf'>nevent1q…e0yf</a><br/>_________________________<br/><br/>Oh no, I missed this one, thanks for linking! This is a really good write-up and there are a lot of similarities with what I&#39;m designing for strfry proxy. Like some of the comments, I&#39;m not sure if partitioning on ID will be optimal in all cases. I can also imagine variations on pubkey and created_at.<br/><br/>Some variant of consistent hashing will also be necessary I think, for failure recovery, rebalancing, changing the number of backend relays, etc. 2024-09-13T19:17:08Z https://nostr.now/nevent1qqsgvga7qd3jhhu9u9qvya0a7leekg8p8y7rsyty7ke9vcnjge3stzszyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6tlmt0t I just tagged strfry 1.0.0. Here are some of the highlights:<br/><br/>* negentropy protocol 1: This is the result of a lot of R&amp;D on different syncing protocols, trying to find the best fit for nostr. I&#39;m pretty excited about the result. Negentropy sync has now been allocated NIP 77.<br/>* Better error messages for users and operators.<br/>* Docs have been updated and refreshed.<br/>* Lots of optimisations: Better CPU/memory usage, smaller DBs.<br/><br/>Export/import has been sped up a lot: 10x faster or more. This should help reduce the pain of DB upgrades (which is required for this release). Instructions on upgrading are available here:<br/><br/><a href="https://github.com/hoytech/strfry?tab=readme-ov-file#db-upgrade">https://github.com/hoytech/strfry?tab=readme-ov-file#db-upgrade</a><br/><br/>Thanks to everyone who has helped develop/debug/test strfry over the past 2 years, and for all the kind words and encouragement. The nostr community rocks!<br/><br/>We&#39;ve got a few things in the pipeline for strfry:<br/><br/>* strfry proxy: This will be a new feature for the router that enables intelligent reverse proxying for the nostr protocol. This will help scale up mega-sized relays by allowing the storage and processing workload to be split across multiple independent machines. Various partitioning schemes will be supported depending on performance and redundancy requirements. The front-end router instances will perform multiple concurrent nostr queries to the backend relays, and merge their results into a single stream for the original client.<br/>* As well as scaling up, reverse proxying can also help scale down. By dynamically incorporating relay list settings (NIP-65), nostr queries can be satisfied by proxying requests to external relays on behalf of a client and merging the results together along with any matching cached local events. Negentropy will be used where possible to avoid wasting bandwidth on duplicate events.<br/>* Archival mode: Currently strfry stores all events fully indexed in its main DB, along with their full JSON representations (optionally zstd dictionary compressed). For old events that are queried infrequently, space usage can be reduced considerably. As well as deindexing, we are planning on taking advantage of columnar storage, aggregation of reaction events, and other tricks. This will play nicely with strfry proxy, and events can gradually migrate to the archival relays.<br/>* Last but not least, our website <a href="https://oddbean.com">https://oddbean.com</a> is going to get some love. Custom algorithms, search, bugfixes, better relay coverage, and more! 2024-09-13T05:54:31Z https://nostr.now/nevent1qqs8vx9y325lnlv3zyqrq75al27rsdpkg04kfy06awmdjsl3acvqx3szyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6dee0nl I just tagged 2 strfry releases: 0.9.7 and 1.0.0-beta1<br/><br/>1.0.0-beta1 is a candidate release of strfry 1.0.0 -- help is needed testing!<br/><br/>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.<br/><br/>0.9.7 has some bugfixes and changes that accumulated in master, and has a &#34;strfry export --fried&#34; feature that can be used to create DB exports that can be rapidly imported by 1.0.0 series releases.<br/><br/>The full changelogs are available here: <a href="https://github.com/hoytech/strfry/blob/1f34794945cf380035822278c46070a9923129f3/CHANGES">https://github.com/hoytech/strfry/blob/1f34794945cf380035822278c46070a9923129f3/CHANGES</a><br/><br/>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. 2024-09-05T22:17:26Z https://nostr.now/nevent1qqsxvvc6ksg4rz9mpfxdmuggvekty565lg2her9f684nmckqyc0xw2czyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z68cx86s In reply to <a href='/nevent1qqsxjkg7hw95n2m7jx26dltw9z02akhy2l7ry0q9d3pfrhd5a87fj3quur6az'>nevent1q…r6az</a><br/>_________________________<br/><br/>Yes, I saw -- it means a lot, especially coming from jb55. Thanks! 2024-09-01T18:32:26Z https://nostr.now/nevent1qqsd7nj66kaf6gmh5s2k9xyauwxsj3yuxrg7w9cev9s6ndt9uvyk9jgzyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6yuhp9p In reply to <a href='/nevent1qqs86fc3ucugxg6m0p2zyy46prynav9kej6v2d32n8zm4lx6usshsqcwyhhk4'>nevent1q…hhk4</a><br/>_________________________<br/><br/>FWIW I agree with you. Right now the front page is really boring. I have some ideas and I&#39;m working on it! 2023-09-29T13:19:39Z https://nostr.now/nevent1qqsqqh8kjfg298k5fg84qqcym0kpvvwcwfx55tmdv3mwa5yhahushqgzyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6tu2kpp In reply to <a href='/nevent1qqsg9x3v0r408tpftsxnts5vmupgmgyd2hskyf4atqv5r55xz924p0qd6plva'>nevent1q…plva</a><br/>_________________________<br/><br/>Thank you!! 2023-09-28T06:25:18Z https://nostr.now/nevent1qqs249sz89y9tr42zef20yzwvdljksmz0rfp8300468l7trpyzcsj9qzyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z69fp4fm In reply to <a href='/nevent1qqsvyuw2uvjnlevvfxw94vktu9qrslul57dqdgk3g5y03mvp932k7dstxmpha'>nevent1q…mpha</a><br/>_________________________<br/><br/>Yes, I have seen nostrdb. I think it&#39;s a great idea, and that it will be a big benefit for native clients. Let me know if I can help in any way!<br/><br/>I was thinking about it a bit and maybe flatbuffers is a bit overkill for the indexed nostr events in strfry, and I&#39;m working on a branch that uses a custom event representation similar to nostrdb. I usually use flatbuffers by default because the generated code is convenient and it&#39;s easy to evolve the schema in a backwards compatible way. Also it comes with some nice utilities for debugging and securely parsing untrusted data (not needed here).<br/><br/>BUT the core nostr event layout is pretty much fixed and saving some space here is important not least because it will let us pack more records into the page cache. I&#39;ll keep you posted on how that goes. Cheers! 2023-09-13T00:10:43Z https://nostr.now/nevent1qqs25vze6wfylvjajf67taw7e0pqray6xclyy2ec0g9a0ckm7e822kczyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z68m69hu In reply to <a href='/nevent1qqs8vvlj3hen6znnxdshv79yq4pc0n7wklwkfz256le4wdfqylyqnes9dd4ly'>nevent1q…d4ly</a><br/>_________________________<br/><br/>600ms seems too long for that set size. I will take a look at the performance when I have my Rust harness working. Let&#39;s make sure it&#39;s working the same way as the C++/JS impls first, and then we can see if there any speed-ups.<br/><br/>One optimisation I did in the C++ was to ensure that the XORing is always done word-wise, instead of byte-for-byte. In fact, with attention to the alignment, I got the compiler to emit PXOR SIMD instructions to do multiple words in a single instruction.<br/><br/>That&#39;s very cool about the UniFFI bindings, I&#39;m looking forward to it! 2023-09-12T07:13:09Z https://nostr.now/nevent1qqsxkckk26uv40ks7garxh3qjlk9m9899j3v0kn24r4zfd8rfauyuqgzyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6n98wp4 In reply to <a href='/nevent1qqs9rwu7dgn7qhwhmjv22vyg8jzvxzhz656spwl8jl59x3ypddltz5gemk73c'>nevent1q…k73c</a><br/>_________________________<br/><br/>Hehe thank you! 2023-07-14T16:47:15Z https://nostr.now/nevent1qqs8l6y8mee9hprzm0mgdw788gkj7sac0q6k5fc62qq2e92gahy3e9szyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z67e8z8m Hey all! I&#39;m going to be doing a talk on nostr and the architecture of the strfry relay. It&#39;s next week at the CppNorth conference in Toronto, Canada:<br/><br/><a href="https://cppnorth.ca/speaker-doug-hoyte.html">https://cppnorth.ca/speaker-doug-hoyte.html</a><br/><br/>If anyone&#39;s around, it&#39;ll be a pretty fun conference! You can enter NOSTR in the checkout to get a discount on the ticket. 2023-07-13T12:10:04Z https://nostr.now/nevent1qqsrqwjp30v85r3aypaj03j0ehu450td9rett5nmgtfxx47cvxq444szyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z609msr5 In reply to <a href='/nevent1qqsvutf3wsv65mc8j04cp0gsls6a4fwsx258dzezjv03ar9ugalq57s9w8gl5'>nevent1q…8gl5</a><br/>_________________________<br/><br/>Hi! Yeah, sorry, the sync support has been broken for a little while. However, this is now fixed in the `next` branch and very soon there will be a 1.0.0 release with this included. 2023-06-09T19:03:00Z https://nostr.now/nevent1qqs2znw2j4juumhv6cn2ahm879kse3ja6ytr2tg652zx7stgsyfnreszyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z60qvx2s In reply to <a href='/nevent1qqsquznnhjtewp2cd0ggdyah02qqq3w2t4jye6nrazxqa6uhg2sfyase93l3s'>nevent1q…3l3s</a><br/>_________________________<br/><br/>Hey guys, sorry for the delay!<br/><br/>Just to clarify: You&#39;d like it so a particular user (authenticated in some way, maybe NIP-42?) can only access a subset of the keys in the DB?<br/><br/>I think that would be possible (assuming authentication is implemented of course). As Mike sas, it wouldn&#39;t be quite as easy as with SQL, where you could add a WHERE clause to all the required queries. However, I think you could do it in a way that wouldn&#39;t affect performance drastically.<br/><br/>If the sets of events for each user are mostly disjoint (not too many duplicated), then you could possibly run a strfry instance for each user. A running instance has a relatively low overhead, especially if you scale down the various thread counts. 2023-05-05T17:41:38Z https://nostr.now/nevent1qqsfm9pkql6cfmk7f6rlrfg4d70ch2jgy4rlankthrulwp6s84v2zmgzyqscywzrzwfet8tvsct680vfjvp6jesfk39xgn5h8zgs8znaap3z6urr4f9 In reply to <a href='/nevent1qqs2n0fp9fe6s5asnztzj5hzh2ccwwq68uq6whda33mu04gl7qsnutcpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet586mtyv'>nevent1q…mtyv</a><br/>_________________________<br/><br/>Thanks! I&#39;m looking forward to actually testing strfry on production traffic. :)<br/><br/><br/>I think the merkle-tree syncing could really help with distributing data amongst relays too, I&#39;m going to write more on this shortly. 2023-01-10T18:22:03Z