Show Idle (>14 d.) Chans
← 2022-11-27 | 2022-11-29 → ↓
07:25 crtdaydreams http://logs.bitdash.io/pest/2022-11-27#1016880 << http mirror of item for readers
07:25 bitbot Logged on 2022-11-27 18:00:19 phf[awt]: http://logs.bitdash.io/pest/2022-11-25#1016874 << this line lands particularly well, because i'm reading unixhaters guide at the moment
~ 19 minutes ~
07:45 crtdaydreams http://logs.bitdash.io/pest/2022-11-27#1016937 << A workshop experiment was done where grease-gun cartridges were replaced with transparent ones, allowing workers to see exactly how much grease was in them at a glance. After a few days of observation it appeared that workers would simply go look for another grease gun rath
07:45 bitbot Logged on 2022-11-27 21:06:57 asciilifeform[5]: not infrequently uses (raw, rather than via mc) sftp
07:45 crtdaydreams er than fill the ones that they could see were empty.
07:51 crtdaydreams asciilifeform: haven't had time to read latest draft spec, is this line-break issue implementation or spec based?
07:53 crtdaydreams actually, that's a terrible question.
~ 1 hours 59 minutes ~
09:52 asciilifeform crtdaydreams: rec to read the latest draft.
09:52 bitbot Logged on 2022-11-10 11:51:20 asciilifeform[6]: meanwhile: signpost , awt , jonsykkel , phf, billymg , et al : preview of 0xfa. a number of sections not done, and prolly over9000 typos but fwiw.
09:54 asciilifeform $ticker btc usd
09:54 busybot Current BTC price in USD: $16241.76
~ 33 minutes ~
10:28 awt asciilifeform: I'm still completely bogged down with fiat work and relocation. Likely won't be able to give it attention until the new year.
~ 33 minutes ~
11:02 signpost asciilifeform: awesome, will re-read soon.
11:07 phf unfortunately until there's a great switchover, can't really do multipart reliably, since it'll spit noise into log
11:12 phf also multipart message not being it's own command type makes me think that asciilifeform has discovered some quality prince george's county dope.
11:19 asciilifeform phf: notion was that old clients will eat'em as standard msgs. lemme know if dope (not tried experimentally, and jonsykkel suggested that his may not, tho can't presently recall why)
↖
11:20 * asciilifeform originally had'em as separate msg coades. then concocted the kludge pictured.
11:22 asciilifeform fwiw if blatta & smalpest indeed would choke on the proposed multipart -- there's then 0 point in not making'em separate codes and dispensing with the kludge
11:22 * asciilifeform admits that not read either prototype in sufficient detail to be certain of the answer
11:23 phf it's got a big of a makefile effect: you'll have a kludge that's relevant for about a month, and then it becomes legacy kludge forever
↖
11:23 phf *a makefile effect
11:23 asciilifeform (there's a reason it's a 'pre-draft' lol)
11:23 asciilifeform phf: tru phakt
11:23 * asciilifeform was thinking 'can avoid fragmenting an already small pestnet?'
11:24 jonsykkel http://logs.bitdash.io/pest/2022-11-28#1016953 << this was re the initial version of new pdf spec, where no explicit 0terminator between messsage Chunk and N+Of
11:24 bitbot Logged on 2022-11-28 11:19:38 asciilifeform[4]: phf: notion was that old clients will eat'em as standard msgs. lemme know if dope (not tried experimentally, and jonsykkel suggested that his may not, tho can't presently recall why)
11:24 asciilifeform jonsykkel: aah
11:24 jonsykkel since fixed in this here item http://logs.bitdash.io/pest/2022-11-15#1016431
11:24 bitbot Logged on 2022-11-15 23:02:17 asciilifeform[6]: updated pre-draft pest spec with jonsykkel's correction & coupla others.
11:25 asciilifeform a ok
11:25 asciilifeform currently nfi re behaviour of blatta re subj, tho
11:26 asciilifeform phf does have strong point, if we carry on with this kind of thing, will end up with 'x86' pile of ???
11:27 asciilifeform alternative tho is also quite ugh, in other direction
11:27 asciilifeform worth discussing imho.
11:27 phf asciilifeform, the reason why its a kludge though, is that you have a declarative wire format, driven by (case command (#x00 ...)) for both packing and unpacking. now you have to kludge a new mechanism of differentiation where also check "but wait, does that region have special value?"
11:27 asciilifeform phf: is the exact reason it's a kludge, yes
11:29 asciilifeform precisely in the style of x64's auto-zeroing of upper halves of long regs on MOV etc
11:29 shinohai *asciilifeform is now known as gabriel_ladell ...
11:29 asciilifeform lol notyet
11:30 phf that's how the protocol can potentially look right now, in declerative lisp form http://paste.deedbot.org/?id=jnZx
11:30 asciilifeform neato phf, is this from your current pestron ?
11:31 phf yes
11:31 phf gives me, (MAKE-RED-PACKET :COMMAND 0 :SPEAKER NICK :TIMESTAMP TIMESTAMP :SELFCHAIN SELFCHAIN :NETCHAIN NETCHAIN :TEXT TEXT)
11:31 asciilifeform a++
11:32 phf or … (string-equal (red-packet-speaker p) nick) …
11:32 * asciilifeform as presently understands, there's only 2 possible answers to 'how to multipart' -- a) the pictured one, where kludge; b) the clean one, where new codes, and old pestrons end up ignoring long msgs
11:35 phf in fact (make-red-packet :command 0 :speaker "joe" :timestamp (get-universal-time) :selfchain 0 :netchain 0 :text "hello, world" :bounces 1)
11:35 phf
11:35 joe hello, world
11:37 jonsykkel i agre no good reason to introduce permanent kludges for bakcwards compatibilty with early prototypes
11:37 jonsykkel royal decree 48bit ipv4 in 1995 and ignore short term consequences wwould have saved a lot of truble
11:40 phf “According to legend, Stu Feldman didn’t fix make’s syntax, after he real- ized that the syntax was broken, because he already had 10 users.
11:40 phf ”
~ 18 minutes ~
11:58 phf 􏿽test
↖
12:02 phf 􏿽well, if nothing else the kludge works. this is a valid "multipart" message with n=1 of of=1
12:04 asciilifeform hm the 'nonprintable' turd shows in log
12:04 bitbot Logged on 2022-11-28 11:58:12 phf[awt]: 􏿽test
12:04 asciilifeform (maybe need a diff turd..)
12:05 phf the siren song of inbandism
12:06 asciilifeform aaha
12:15 jonsykkel if gonna klugde might as well dispense with the uniturd and make 1byte Z and immediately 1byte turd after
12:16 asciilifeform jonsykkel: how would that be compat with old pestrons?
12:16 asciilifeform yea it wont choke, but won't print either
12:16 jonsykkel asciilifeform: i mean u simply begin the chunk where Mark is now
12:17 jonsykkel then newer trons will just look for special value immediately after the 0terminator
12:17 phf one could do Chunk Z N Of TextHash Mark, and you only need mark in case "old pestrons" don't pad their text with zero
12:17 asciilifeform jonsykkel: problem with 'mark after Z' is that random padding after Z may end up == to the mark
12:17 asciilifeform (on ordinary non-multi packet of the correct length)
12:18 jonsykkel asciilifeform: indeed but iirc old specs had 0padding
12:18 shinohai phf `MAKE-RED-PACKET` isn't being very inclusive to all the other colors out there.
12:18 asciilifeform jonsykkel: ~new~ proposed spec has random padding tho, and may issue an unintended multipart mark if sending with the correct length, under your scheme
12:19 phf shinohai, red packet ethnostate when
12:20 jonsykkel ah i see
12:22 * asciilifeform strongly inclined to throw out the kludge, but will wait for folx to beat subj to death
12:23 asciilifeform the obv cost is fragging of the net; bots will need swapping, folx on ancient versions (mod6?) will see some msgs and not others, etc
12:28 asciilifeform thinking about it, theoretically mark ~could~ go after Z, and new-style pestron emitting classical single-part msg would then need to terminate'em with (0)(anything-but-mark)(random..) but still ugh
12:28 asciilifeform inbandism is inescapably ugly
12:28 jonsykkel put new comand for broadcasts with multipartism, ignore old 0x00s, plus emit "ur pestron is old plz run windows update" 0x00 every 5 sec until nobody in net uses old progs
12:28 asciilifeform lol
↖
12:37 phf well, i added support for your kludge to my defwire http://paste.deedbot.org/?id=Ifgb it's possibly better even without kludge
12:38 phf can now say (make-red-packet :type :broadcast-text :text "hello, world" …)
12:40 phf but i still lost the declerative mapping between `command` and its payload, through the "type" indirection. not sure if it's better or worse. i guess this fix makes it very explicit that there's no declerative mapping between type and command with this kludge.
12:47 * asciilifeform not disputes that it's ugly as sin
~ 51 minutes ~
13:38 asciilifeform meanwhile, in misc. old-timer blogs.
↖
~ 36 minutes ~
14:14 phf test
14:15 asciilifeform phf: worx. what was it test of ?
14:15 phf patched defwire
14:15 asciilifeform a
14:28 phf hmm, this is going to fail misserably…
14:33 phf 􏿽Never before had Brother Francis actually seen a pilgrim with girded loins, but that this one was the bona fide article he was convinced as soon as he had recovered from the spine-chilling effect of the pilgrim’s advent on the far horizon, as a wiggling iota of black caught in a
14:33 phf 􏿽shimmering haze of heat. Legless, but wearing a tiny head, the iota materialized out of the mirror glaze on the broken roadway and seemed more to writhe than to walk into view, causing Brother Francis to clutch the crucifix of his rosary and mutter an Ave or two. The iota suggested
14:34 phf 􏿽 a tiny apparition spawned by the heat demons who tortured the land at high noon, when any creature capable of motion on the desert (except the buzzards and a few monastic hermits such as Francis) lay motionless in its burrow
14:36 phf woop
~ 29 minutes ~
15:06 phf imho texthash is a waste of space. there's already a mechanism for chain reconstruction, which is netchain/selfchain. this one just eats up 32 bytess without adding any extra guarantees (except testing that the counterparty's client is not broken)
~ 15 minutes ~
15:21 phf asciilifeform, have you given a thought to ACTION? that's something that's not address in the spec, and if you're going to drop irc specific stuff probably should be
↖
15:22 asciilifeform phf: asciilifeform's rationale for texthash : 1) makes over9000 easier to organize incoming out-of-order chunks 2) provides at least modicum of resistance against buggy or otherwise misbehaving clients corrupting hearsayed chunks
15:22 asciilifeform phf: not considered ACTION. (will need to remember how it was encoded traditionally...) may need explicit mention in spec
15:22 asciilifeform esp. considering that irc frontends may be with us for rather long time
15:23 * phf ~a~c" #\Soh text #\Soh)
15:23 asciilifeform ah hm
15:23 asciilifeform oughta work without explicit knobs then
15:26 * asciilifeform not defined wat-do if conflicting hearsay chunks in fact received (i.e. for some N, Of, and TextHash, different payloads.) if only couple -- can iterate over'em, reconstruct. but when to try? at any rate, oughta alert operator
15:28 asciilifeform notion is, if 1st chunk is immediate, and some number of subsequent chunks -- hearsays, ought not to have to wonder re authenticity of reconstructed payload
15:29 asciilifeform (i.e. if it reassembles and hashes to TextHash, whole thing can be displayed as 'immediate')
15:29 asciilifeform *if any chunk if immediate
15:29 asciilifeform (rather than 1st)
15:29 phf i guess that makes authenticity of whole text as authorative as the most authorative chunk
15:29 asciilifeform correct
15:30 asciilifeform and then not need to display thing in chunks, marking relayers for each
15:30 asciilifeform (display 'immediate' if any chunk immediate, or min-bounce-relayers of min-bounce chunk if none of it was)
15:31 asciilifeform ( if above not makes sense to anyone tuned in, plox to write in! )
15:32 phf doesn't simplify the mechanism though, has to be an extra mechanism on top of existing mechanism.
15:33 phf like you build your missing packets the usual way, holes and all, chain validation, etc. and then once the whole chain is there need to get an aggregate, merge text, hash, etc.
15:33 asciilifeform phf: simplest mechanism is that you dun need to walk back over received msgs to know when it's time to reassemble a multi -- instead you spawn a data structure when see new texthash and fill the thing in
15:34 phf and now your datastructure is "magic", when it comes to lost packets, etc.
15:35 asciilifeform 'magic' in that you gotta specify when to give up if somehow not got 1 or moar chunks, yes. but that problem would have even w/out texthash
15:35 phf but that problem is solved in a generic way already, the tradeoff of your "just stuff it all into datastructure" is that datastructure is now a kind of subgraph, need to have all the ops special handled
15:36 asciilifeform you still gotta store reassembled multis' payloads in db in some reasonably o(1) way. so may as well allocate the space when see any chunk
15:36 phf if i want to walk the graph and to getdata all the missing packets, or if i get a packet and want to check if it's in the graph, etc.
15:36 asciilifeform (when 1st see a chunk)
15:37 asciilifeform you dun wanna have to walk graph erry time scrolling log window etc tho
15:37 asciilifeform 1ce you have the full text reassembled, getting to it oughta be o(1)
15:37 asciilifeform i.e. it should behave, from operator pov, like a single msg
15:37 phf you haven't thought it through
15:38 * asciilifeform must bbl momentarily, plox to continue
15:39 phf e.g. there's no 1-to-1 correspondence between the backlog and the display on account of any number of potential holes, and the multipart is just a special case of hole sources
15:41 phf lacking something like "cells" architecture you're necessarily synchronizing a datastructure that manages missing packets, etc. with your display
15:43 phf i guess a multipart bucket makes a certain kind of screen update "easier", since instead of figuring out where you need to insert new content by some kind of graph walk, you instead know "exactly"
15:44 phf but you can't avoid that graph walk in a general case, because at any moment you might have some number of packets in flight
~ 39 minutes ~
16:23 asciilifeform phf: in asciilifeform's sketch of gui pestron: 'broken heart' is displayed b/w any 2 msgs where it is known there is 1 or more missing msg
16:24 asciilifeform if/when the msg(s) w/ desired hash arrive, the 'broken heart' is replaced with same
16:24 asciilifeform no graph walking req'd (unless asciilifeform misunderstands what was meant)
16:26 asciilifeform when scrolling, db gets asked to supply msg with given hash (i.e. having the already displayed msg on tail of scroll as predecessor), if not found, but there's a msg with higher timestamp -- a brokenheart is shown.
16:26 asciilifeform (higher timestamp & missing predecessor)
16:27 asciilifeform concretely wat-do in re use of nethash to 'thread' msgs, is worth moar thought, and prolly section in spec.
16:29 asciilifeform phf: under proposed algo, packets-in-flight dun demand graph walk -- given as they are marked with N/Of. can simply drop'em in the indicated position in prealloc'd space as they arrive.
16:32 asciilifeform (with a clever db, not even need to make dedicated data structure for this -- simply 1st chunk with given texthash causes preallocation of contiguous space for 'Of' # of msgs; and the chunk seen sits down into the requested pos.)
16:32 asciilifeform the slots corresponding to the missing msgs are marked 'broken heart', and filled in as they come in in whatever order.
16:36 asciilifeform ( term 'brokenheart' cribbed here from the bolix people, who used it to represent 'transparent pointer' that gets followed silently, so that physically-uncontiguous (e.g. after gc) memory could be addressed as contiguous )
16:37 asciilifeform this is how one can fill holes -- of width not known apriori -- after the fact, and still get close to o(1) access to the whole thing later
16:38 * asciilifeform in fact did think through, lol, but invites comments if missed sumthing
↖
16:39 asciilifeform ideally db would store all (non-missing) msgs. in contiguous chain order, rearranging as req'd.
~ 2 hours 7 minutes ~
18:47 phf http://logs.bitdash.io/pest/2022-11-28#1017078 << i gave up on trying to make it work using simple linear dump, with broken heart holes, because even now the graph of incoming pockets is more complicated than "just a missing packet here and there"
18:47 bitbot Logged on 2022-11-28 16:38:26 asciilifeform[5]: in fact did think through, lol, but invites comments if missed sumthing
18:48 phf so, yes, if you think that sequential storage of packets works, and can implement a reliable packets-insert function, then my concerns don't apply
18:49 phf 􏿽*sequential storage meaning in flight runtime data, obviously that runtime data ultimately gets flattened and stored in db as a sequence of some sort. but i started with having my packets in a sequence, and then trying to write a "insert-packet" that also keeps track of missing hol
18:49 phf 􏿽es for the purposes of getdata, and the result was iffy
18:57 phf one reason for that is that while there's always one unique selfchain (since you're the one sending messages, you always have them in the order you sent them), because of transmission delays and failures netchain is subjective to each station.
19:06 phf and the implications of that behavior are varied. like for example somebody might be getting the packets, but for some reason outgoing packets are getting stuck. why? who knows! internet routing magic
19:08 phf 􏿽so you have everyone sharing the netchain, because they're seeing the messages in order, all at the same time. so i respond to you, you respond to me, all's fine. but this thid person with his weird internet delays is also responding to us, but we never see his messages, until the
19:08 phf 􏿽router magic gets unkinked, and his responses all come through at the same time
19:14 phf so your netchain is not so much a netchain as it is as net-directed-acyclic-graph
19:19 phf you can punt on that complexity by implementing a heuristic based packet-insert that essentially maintains a stable topological sort of your directed-acyclic-graph, but having attempted that i have a hunch that the approach is not the best
19:29 phf 􏿽i'd at least try and prototype some of these emergent behaviors kind of like http://logs.bitdash.io/pest/2022-09-07#1012520 because it's possible that i'm overthinking the complexity, and then having a concrete pseudocode algorithm would be helpful, but it's also possible that your
19:29 bitbot Logged on 2022-09-07 17:20:49 phf[awt]: current state of simulation code http://paste.deedbot.org/?id=TzYt
19:29 phf 􏿽 intuition for the protocol's behavior reflect best case, rather than quirks of real world
~ 35 minutes ~
20:04 asciilifeform phf: asciilifeform would be a dirty liar if said that he has final-solution to the pest db problem. esp. in light of fact that he'd like to store ~tree~
20:04 asciilifeform i.e. use netchain for 'threading'
20:05 asciilifeform there's doubtless a reasonably-compact way to do it, esp. if willing to periodically compact the datastructure
20:05 asciilifeform (i.e. rearrange things into a logical order)
20:05 asciilifeform fwiw none of this is detailed in the current spec, still needs thought.
20:06 asciilifeform ( in asciilifeform's mental picture, in gui msg has 'reply' button appear when moused over, and can extend a thread that way, as seen in certain heathen chats )
20:07 * asciilifeform has used various heathen chats for commercial clients, and imho most of the knobs they offer could easily exist in pest
20:09 asciilifeform the current forced linearity of msgs, and the need for logotron links to carry a thread, imho is braindamaged and entirely avoidable if netchain is used properly
20:10 asciilifeform ( the old logotrons, ideally, can be thrown out once a pestron exists that can serve its log over www )
↖
20:10 asciilifeform ... then and only then can 100% dispense with the irc-compat. frontend
20:11 * asciilifeform still pondering whether dedicated 'this is a reply' bit is req'd, or can be avoided
← 2022-11-27 | 2022-11-29 → ↑

Random(pest) | Download hourly DB snapshot | Get Source Code

Theme: Light | Dark | System Default