signpost[busybot]: got that lisp encoder on par with the python impl. seems like there's plenty of optimization to be had yet.
signpost[busybot]: unnecessary recomputation of the alias method lookup table was bogging it down.
signpost[asciilifeform]: asciilifeform: phf: any notions re: efficient xor of subsequences of a given bit vector? seems like using displaced arrays nukes optimization of bit-xor
signpost[busybot]: http://paste.deedbot.org/?id=z1oZ << current sauce
signpost[busybot]: http://paste.deedbot.org/?id=kAql << and tests
signpost[asciilifeform]: barring something smarter, I might just chop the thing into many non-displaced bit-vectors instead of trying to do everything in one giant bit-vector
signpost[busybot]: since later this thing will need to eat/shit files on disk, the in-memory mega-array will have to go anyway. who says what's to be broadcast/received fits in RAM. was just a place to start.
signpost[busybot] bed, night all
asciilifeform: signpost: pretty neat. you'll want file chunks as direct msg tho, rather than broadcast, if you let'em all-to-all no amt of bw will ever suffice. iirc we had a thread where 'let each station offer operator-selected files to own peers'.
asciilifeform atm has this in the new spec draft in anticipation of signpost's thing
asciilifeform: asciilifeform's notion is, can issue 'i want file with $hash' to >1 peer, and get direct lubyisms from >1 if they have it
signpost[asciilifeform]: yep that sounds right. I was thinking it might be nice to inform peers how much spray you want from each to conserve bandwidth also, just as a politeness mechanism.
signpost[busybot]: "do you have $hash?" -> "yep, and I call it foo, and it's $size" -> "pls canhaz 20mb of encoded fileblox"
signpost[asciilifeform]: the "do you have" can be used to get a sense of availability of $hash in your net
asciilifeform: signpost: 'how much firehose' is actually a tricky q, esp. if one considers peers w/ wildly mismatched pipes
asciilifeform: prolly oughta indicate in the request. 'i can eat n pieces / sec.'
signpost[asciilifeform]: that's true. I'm thinking we don't want each peer to piss 1gb at receiver if file's 1gb though
asciilifeform: signpost: for that, oughta cut into blocks (say 1MB), w/ indiv. hashes
asciilifeform: in general, oughta limit the amt of piss triggerable by 1 packet to sumthing reasonable
asciilifeform: otherwise, too easy to get folx to drown ~selves~ in own piss, and not even through malice but by sheer accident
signpost[asciilifeform]: yeah, perhaps something like you say. I initiate a transfer from peer p1 telling him "spray me packets at up to $limit" and p1 decides (or is limited by pipe) where beneath the limit the transfer operates (or above, nothing hard governs it obviously)
signpost[asciilifeform]: if I'm not saturated on my end, I can ask P2, P3, etc for same, incrementally filling up the amount of my pipe I wish to dedicate to the transfer
asciilifeform: in practice, most folx w/ pestron will be limited by cpu cost of decoding, rather than bw per se
unpx[busybot]: Just in case someone was interested, I just recalled nsucrypto exists and that there are some people trying to figure out the solution of this unsolved puzzle: https://nsucrypto.nsu.ru/archive/2022/round/2/task/7/#data
unpx[busybot]: Ah. Silly. Here's the complete task list https://nsucrypto.nsu.ru/media/Olympiads/2022/Round_2/Tasks/22_second_round-kdjcf.pdf
asciilifeform had an ancient orcish b00k as a kid, w/ puzzlers quite like this
asciilifeform: unpx: problem 9 (where asked to find a symmetric cipher that is commutative and can be used in shamir's 3pass algo) iirc provably has no solution (or at any rate not such that anyone would want)
asciilifeform would be curious to learn otherwise
asciilifeform wouldn't mind having one for pest rekey but afaik aint no such thing w/out bignumism