From a4fc5cc5ef92cd152265c3ecf1a200a4769dcc9d Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Tue, 11 Nov 2025 11:21:34 -0300 Subject: [PATCH] add recommendation for HLL client-side usage. --- 45.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/45.md b/45.md index 906f7398..dae90a58 100644 --- a/45.md +++ b/45.md @@ -73,6 +73,21 @@ One could mine a pubkey with a certain number of zero bits in the exact place wh The value `hll` value must be the concatenation of the 256 registers, each being a uint8 value (i.e. a byte). Therefore `hll` will be a 512-character hex string. +### Client-side usage + +This algorithm also allows clients to combine HLL responses received from relays with HLL counts computed locally from raw events. It's recommended that clients keep track of HLL values locally and add to these on each message received from relays. For example: + + - a client wants to keep track of the number of reactions an event Z has received over time; + - the client has decided it will read reactions from relays A, B and C (the NIP-65 "read" relays of Z's author); + - of these, only B and C support HLL responses, so the client fetches both and merges them locally; + - then the client fetches all reaction events from A then manually applies each event to the HLL from the previous step, using the same algorithm described above; + - finally, the client reads the estimate count from the HLL and displays that to the user; + - optionally the client may store that HLL value (together with some "last-read-date" for relay A) and repeat the process again later: + - this time it only needs to fetch the new reactions from A and add those to the HLL + - and redownload the HLL values from B and C and just reapply them to the local value. + +This procedure allows the client to download much less data. + ## Examples ### Count posts and reactions