> Currently `strfry sync` will post events it has with regular EVENT messages, and/or download events it needs with regular REQ messages.
It’s fine, IMO, that reconciliation is performed out-of-band. A sentence describing what you just said would be fine.
> Maybe we should also describe the Negentropy protocol there?
Whatever the relay is expected to produce should be defined—or at minimum linked to a specification.
Also, IMO, sending hex strings of binary seems to be both inefficient and against the Nostr ethos of legible messages/events. If you’re sending binary, base64 only inflates by 33% compared to hex strings’ 100%.
Personally, I’d prefer to see the message format specified explicitly as debuggable JSON, if feasible.
Baller. I should do that next time I get asked.
First week in almost a year where I hit 4 workouts. Feels good to be back. 🏋️♂️
What is its sync specification?
Do those things even exist there?
Same. The whole part about the NEG-MSG payloads is missing. What are the mysterious hex-encoded strings?
The NIP-77 document doesn’t specify what the content of the ‘NEG-MSG’ messages are. It also doesn’t seem to cover the actual sending of events in either direction (after the sets have been reconciled).
Hodling #Bitcoin requires a careful blend of stalwart conviction and not giving a fuck.
Thank you! I read the Range-Based Set Reconciliation article. Seems like an efficient strategy.
Makes me wonder about frequency, cost and strategy of rebalancing the b-tree, given that elements would tend to be mostly appended near the end.
“Don’t worry. The blood’s not mine.” nostr:note138t70l89y9vzkf259cgqeqd7vquaav8hu0m7amvkycya5gzs45vqe0lz06
I just tagged strfry 1.0.0. Here are some of the highlights:
* negentropy protocol 1: This is the result of a lot of R&D on different syncing protocols, trying to find the best fit for nostr. I'm pretty excited about the result. Negentropy sync has now been allocated NIP 77.
* Better error messages for users and operators.
* Docs have been updated and refreshed.
* Lots of optimisations: Better CPU/memory usage, smaller DBs.
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:
https://github.com/hoytech/strfry?tab=readme-ov-file#db-upgrade
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!
We've got a few things in the pipeline for strfry:
* 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.
* 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.
* 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.
* Last but not least, our website https://oddbean.com is going to get some love. Custom algorithms, search, bugfixes, better relay coverage, and more!
Link to NIP-77?
this is similar to asking how many users are using email or how many people browse the web. we really don't have an accurate count for those. we can have educated guesses and estimates though. nostr is no different here.
According to nostr.band, Nostr consists of the following:
Pubkeys: 35,067,097
Users: 1,067,394
Trusted users: 188,773
you can learn more about nostr.band's trust rank here: https://trust.nostr.band/
nostr:note1x9rj6k88s4e62qlktz0s6dp5jghyqgpprv4qgrk649gvudspz9esprwtnt
What is a “trusted” user?
I think the whole thing collapses faster under Harris. Four years of Trump would propel at least another decade of red team complacency. But four years of Harris should hopefully push enough of red team into readiness for revolutionary change.
