can’t think of anything more important in bitcoin than the work miles and team are doing. bitcoin is for payments 🤝 not just savings. protec him at all costs.
View quoted note →
jb55
_@jb55.com
npub1xtsc...kk5s
I made damus, npubs, and zaps ⚡️
Independent bitcoin core and lightning dev.
#sushistr
I’ve been enjoying nostr with media loading turned off lately. I think i want to extend the mode to hide media-only posts. make text nostr great again.
i think i just came up with a new compact data structure for variable sized integers that supports efficient search. let's say you want to encode 1000 people you follow into the social graph index using martti's encoding. you simply bucket the sorted user-id integers contiguously based on the size of its encoding. for example:
u16_offset: 6
UID(u8) * 6 -> 1,2,42,53,128,255
UID(u16) * 1000 -> 1024, 4086, 65532, ...
the header of the array simply stores offsets into the 2/4-byte array segments. if you want to check if a user id of varint encoding size 1 exists in the person follow list, you can linear scan through the 1 byte entries (probably faster than binary search for ~255 max entries)
if the userid encodes to 2 bytes, you can jump to the 2-byte offset (stored in the array header) and then binary search through that, assuming this would be the larger part of the array.
this gives you the smallest possible encoding and direct indexing... not sure if anyone has thought of this before.
I love compact and fast data structures 🤓
martti already added follow/WoT indices to #nostrdb, now I'm just brainstorming space optimizations!
this is another great use case for #nostrdb custom query filters:
you can exclude results with more than N `t` tags in the query itself, so that spam doesn't clog the results.
we use custom filters everywhere: filtering replies for only pulling root notes, etc. you can have any logic you want and the filter is executed while nostrdb walks the index. no need to query-then-filter, no query limit result slots are wasted. very useful.
View quoted note →