Doug Hoyte

The answer to this is surprisingly complicated.
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: https://blog.qualys.com/product-tech/2012/09/14/crime-information-leakage-attack-against-ssltls
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.
Websocket compression happens per message, and can use an empty window for each message, or can have a "sliding compression" 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.
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.
Although strfry <> browser connections are almost always compressed both ways, different clients and relays have different levels of support and often can't negotiate optimal compression.

2024-09-13 22:30:29

- reply

Hehe in fact my original attempt at sync in strfry was a protocol called "yesstr" using my Quadrable library: https://github.com/hoytech/quadrable
It used binary flatbuffers over websockets. It caused a lot of problems since binary websocket messages require a distinct message type from text ones. Since nothing else in nostr uses these, of client libraries were having trouble integrating with it. Using a structured binary format like CBOR or flatbuffers also means clients would have to pull in a (probably heavy) serialisation library.
The nice thing about the current approach is that any existing nostr client already must support websocket text messages containing JSON containing hex data.

2024-09-13 21:23:19

- reply

> If you’re sending binary, base64 only inflates by 33% compared to hex strings’ 100%.
On purely random data, after compression hex is usually only ~10% bigger than base64. For example:
$ head -c 1000000 /dev/urandom > rand
$ alias hex='od -A n -t x1 | sed "s/ *//g"'
$ cat rand |hex|zstd -c|wc -c
1086970
$ cat rand |base64|zstd -c|wc -c
1018226
$ wcalc 1086970/1018226
= 1.06751
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:
$ echo 'hello world' | base64
aGVsbG8gd29ybGQK
$ echo ' hello world' | base64
IGhlbGxvIHdvcmxkCg==
They have nothing in common. Compare to the hex encoded versions:
$ echo 'hello world' | hex
68656c6c6f20776f726c640a
$ echo ' hello world' | hex
2068656c6c6f20776f726c640a
The pattern is preserved, it is just shifted by 2 characters. This means that if "hello world" 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).
Since negentropy is mostly (but not entirely) random data like hashes and fingerprints, it'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.
> Personally, I’d prefer to see the message format specified explicitly as debuggable JSON, if feasible.
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-13 20:47:52

- reply

Probably our telegram channel is best currently: https://t.me/strfry_users
Hopefully some day we'll migrate fully to nostr!

2024-09-13 20:05:18

- reply

Good question! Right now the implementation is pretty simple, but I think will work well in most cases: It always splits a range into 16 equal-sized ranges unless the range has 32 or fewer IDs, in which case it just sends the whole list of IDs. I think there is probably some low-hanging fruit on tuning that threshold.
The nice thing is that nothing in the protocol needs to change to tune this. In fact, the protocol theoretically supports dynamic adjustment of those parameters to target a particular point in the latency/bandwidth tradeoff space.
There are also some other reasons you might want to customise the range selection, which I described here: https://logperiodic.com/rbsr.html#range-choice

2024-09-13 19:49:16

- reply

No, both of those versions use DB version 2, so their DBs are compatible.

2024-09-13 19:36:02

- reply

The best way is to first upgrade to 0.9.7, which is the latest release in the 0.9 series. This has the "--fried" option for export (but not import).
After you have the fried export, upgrade to 1.0.0 and import with "--fried" too.
Sorry for the trouble, but it will save a *lot* of time versus normal import!

2024-09-13 19:33:28

- reply

NIP-77 I believe is still a draft/work-in-progress, so I don't know the final form yet.
I think fiatjaf'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): https://github.com/hoytech/negentropy/tree/master?tab=readme-ov-file#definitions
> It also doesn’t seem to cover the actual sending of events in either direction (after the sets have been reconciled).
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.
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't actually care about the event contents and is only trying to compute an aggregate "reaction count" across relays, it may never actually download the events, and purely use negentropy for de-duplication purposes.

2024-09-13 19:24:01

- reply

Good question! Appending at the end (or near the end) is actually the best-case scenario in my B-tree implementation, because it leaves the right-most leaf fully packed, unlike a classic B-tree which keeps it at half-capacity. More info here: https://github.com/hoytech/negentropy/blob/master/cpp/negentropy/storage/btree/core.h#L15-L31
Making multiple updates to the B-tree in the same transaction is also highly optimised: The modified nodes are edited in-place in memory, and only committed to the DB at the end of the transaction. So on average, inserting 40 or fewer records at the right edge of the tree in one transaction will require only 1 DB read and 1 DB write (in addition to the metadata page).

2024-09-13 19:17:46

- reply

I appreciate you letting me know -- I'm glad you like it!

2024-09-13 19:17:08

- reply

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'm designing for strfry proxy. Like some of the comments, I'm not sure if partitioning on ID will be optimal in all cases. I can also imagine variations on pubkey and created_at.
Some variant of consistent hashing will also be necessary I think, for failure recovery, rebalancing, changing the number of backend relays, etc.

2024-09-13 12:29:17

- reply

https://github.com/nostr-protocol/nips/pull/1494

2024-09-13 05:54:31

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!

2024-09-12 19:22:01

- reply

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

2024-09-09 21:17:21

- reply

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.

2024-09-06 23:41:50

- reply

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

2024-09-06 19:05:05

- reply

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. ;)

2024-09-06 03:47:57

- reply

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.