asciilifeform: http://logs.bitdash.io/pest/2023-05-08#1025846 << correct (still needs megatonne of revision, and asciilifeform again mired in salt mines)
bitbot[asciilifeform]: Logged on 2023-05-08 23:28:36 awt: asciilifeform: is the latest version of the pest spec the one in which BroadcastTextM and DirectTextM have their own unique command ids?
awt[asciilifeform]: asciilifeform: do you have a plan to become unmired or permanently mired?
asciilifeform: awt: nope & nope
asciilifeform: ~rng
asciilifeform: ( hypothetically -- if, lol, 'exch rate grows a 0 and a half' -- perma-unmired. but 'if wishes were horses' etc )
awt[asciilifeform]: my contract ended so I am pretty free for a while. gonna try to make the most of it.
asciilifeform: and, conversely, suppose when asciilifeform gives up the ghost, can be termed 'perma-mired'.
asciilifeform: awt: congrats (?) on the 'pretty free'
awt[asciilifeform]: asciilifeform: ty (?) lol
awt[asciilifeform]: In terms of referencing pest messages in guis, might be nice to be able to reference message hashes like so: pest://iOPjv7o9y8tz0FxeqKXawulIEYBK9Z9cXWCniNE8+z4= - click on it and your gui displays it somehow.
phf: http://logs.bitdash.io/pest/2023-05-09#1025857 << same mechanism should probably be used for quotes. i dunno how well ascii's idea of implicit chains "everything is a reply to something" will work in practice, so it would be cool to retain some legacy hybrid solution, e.g. something like,
bitbot[asciilifeform]: Logged on 2023-05-09 11:56:32 awt: In terms of referencing pest messages in guis, might be nice to be able to reference message hashes like so: pest://iOPjv7o9y8tz0FxeqKXawulIEYBK9Z9cXWCniNE8+z4= - click on it and your gui displays it somehow.
phf: pest://iOPjv7o9y8tz0FxeqKXawulIEYBK9Z9cXWCniNE8+z4= << hello, world
phf: should be an equivalent of log reference that we do now
phf: then each client can do its own lookup, etc.
awt[asciilifeform]: phf: yes I can see that. Should be able to insert a following line shomehow.
phf[asciilifeform]: this way the ref doesn't need to be inline anymore either. web loggers can display the referred messages in some visual way, and so can clients
awt[asciilifeform]: phf: could also do footnote style quotes (iOPjv7o9y8tz0FxeqKXawulIEYBK9Z9cXWCniNE8+z4=) (IBsM2cqkUtTU9pwDUD5nB9Xe6Z61+q8IuqK22R0UzNg=) that open up a pane when the message is selected.
phf: well, i think that each client can do whatever ux, so we're discussing in-band format and behaviors.
phf: as far as behaviors, the proposal i'm making is that in the future™ there will be no need to quote the original message, because every cilent (desktop or web logger) can just render the message however is convenient
awt[asciilifeform]: phf: got it
phf: this is eliminate the noise, but also the weird threading issues, where you quote a logger, and then somebody else says something, and then the logger sends the original message eventually
phf: so if i say something like pest://fff… the client can look up fff in its own database or do a getdata, and then render the result wherever is convenient
phf: as far as in-band format, i don't have preferences, they are all pretty ugly. this possibly also opens up the conversation about RTF messages
phf: http://logs.bitdash.io/pest/2023-05-09#a3d805168e646d9543fcb397755564a06fdd6c665632434dc0c51e73d8517905f21e1c1126bb213e3e10268e8a0c2972c85fcba72c9df06751680637f5a6688d :D
phf: ah never mind it's 256, so more like #62b5bb83ed9289828f73e4f4d51c9b8a61e7bb57d25e2e539ae3e7916c5229e3
phf: or #YrW7g+2SiYKPc+T01RybimHnu1fSXi5TmuPnkWxSKeM= in base64
bitbot[asciilifeform]: Logged on 2023-05-09 12:47:57 phf[4]: pest://iOPjv7o9y8tz0FxeqKXawulIEYBK9Z9cXWCniNE8+z4= << hello, world
signpost[asciilifeform]: http://logs.bitdash.io/pest/2023-05-07#1025823 << should be apr 21, 2024 for next, at block 840,000
bitbot[asciilifeform]: Logged on 2023-05-07 17:37:32 asciilifeform[5]: signpost: iirc there's 1 coming up later this yr, can see whether pattern still appears
phf: jonsykkel, i'm getting keyoffers from you, i've rigged the response manually, i've sent keyoffer and keyslice, but i'm not getting any keyslice back.
phf[asciilifeform]: hmm, never mind i seem to have managed to do a keyoffer keyslice roundtrip, but i'm still getting packets from you with old key
jonsykkel[asciilifeform]: lemme chek wats in log
phf: ah, ty
jonsykkel[asciilifeform]: my pestron waits for ignore pakets after the sliceing, u sending those?
jonsykkel[asciilifeform]: and times out if not get
jonsykkel[asciilifeform]: cant see cuz i dont log them
phf: hmm, i'm sending them, but on a pretty random schedule
phf: yeah, the last timeout looks like that's what it is
jonsykkel[asciilifeform]: theres step11-12 in the http://www.loper-os.org/pub/pest/pest_draft.html#44-rekeying
phf: and those ignore packets should be with the new key slice?
jonsykkel[asciilifeform]: thats how i interpreted it
jonsykkel[asciilifeform]: the xored slices
jonsykkel[asciilifeform]: Kn == K xor Sa xor Sb
phf: yeah, but why wait for ignore?
phf: 7 Rekeying
phf: TODO
phf: lol nevermind
jonsykkel[asciilifeform]: ye its in the old one only
jonsykkel[asciilifeform]: i guess the point of the ignores etc is to make sure both partys calced the same new key
jonsykkel[asciilifeform]: before delete old one
asciilifeform lulzily got hung up on getting algo flowchart formatting to work w/ 'hevea', so to this day not finished sect 7 & buncha other similar in new spec
asciilifeform absolutely refuses to maintain 2 flavours of spec src text
jonsykkel[phf|phf|asciilifeform]: or maybe ur question was "why ignore and not just any packet"
phf[asciilifeform]: http://logs.bitdash.io/pest/2023-05-09#1025899 << but that's already implicit in the protocol. unless i'm missing something the only reason keys will be different, is because client is broken. on the other hand it's a pretty safe assumption that it might be. but on the other hand i
phf[asciilifeform]: f you're going to do that then there probably shouldn't be a timeout
bitbot[asciilifeform]: Logged on 2023-05-09 19:13:58 jonsykkel: i guess the point of the ignores etc is to make sure both partys calced the same new key
asciilifeform: jonsykkel: rationale was, ignore 1) shows that new key 'happened' 2) but not logged and hence not complicates life on either side of the peering if 'not worked'
phf: so in other words there's a mandatory ignore after rekey
asciilifeform: aaha
jonsykkel[asciilifeform]: ok, i se
asciilifeform haunted by suspicion that the rekey algo could be made simpler, or at least stated moar compactly; but not presently knows how
jonsykkel[asciilifeform]: http://logs.bitdash.io/pest/2023-05-09#1025906 << if ttheres no timeout tho, guy who sent last slice doesnt know if other guy recv it or not
bitbot[asciilifeform]: Logged on 2023-05-09 19:15:49 phf[deedbot|signpost]: f you're going to do that then there probably shouldn't be a timeout
asciilifeform: the orig. notion was, 1) new key cannot be forced to an apriori-known value by buggy/sabotaged client on 1 end of peering 2) old key will not under any circumstances vanish on either end until both peers satisfied that they agreed on new one
asciilifeform: jonsykkel: there's a timeout 'Tk' , see old draft spec
asciilifeform: 'A rekeying is deemed to have aborted (any slice Sx, as well as Kn if it has been generated -- discarded by the station) if it does not complete within an operator-specified interval Tk.'
jonsykkel[asciilifeform]: asciilifeform: inded, replying to phfs
jonsykkel[asciilifeform]: spek dosnt make entirely clear exactly at which point the rekeying is to be considered "complete" however
asciilifeform: http://logs.bitdash.io/pest/2023-05-09#1025904 << rekey can fail simply from loss of 1 or moar of the pertinent packets
bitbot[asciilifeform]: Logged on 2023-05-09 19:15:47 phf[jonsykkel|deedbot|awt]: http://logs.bitdash.io/pest/2023-05-09#1025899 << but that's already implicit in the protocol. unless i'm missing something the only reason keys will be different, is because client is broken. on the other hand it's a pretty safe assumption that it might be. but
jonsykkel[asciilifeform]: iirc my client considers it complete after the ignore recved
jonsykkel[asciilifeform]: meaning, no timeout
asciilifeform: intent of given algo is that a rekey is effective after each peer has eaten a packet from the other under the new key
asciilifeform: ( after satisfied that the slices were baked independently )
phf[asciilifeform]: word, i get it now
phf: i wasn't really thinking about it, just going by spec
phf: i probably would've put the key into some kind of cubby hole, and let the counterparty start using it whenever it feels like, within some large limit
asciilifeform: phf: wainot right away?
asciilifeform: ('cubby' seems like an unnecessary moving part imho)
phf: yeah, i'm not sure i think you're probably right
awt[asciilifeform]: Ugh. Trouble with a graphing db with a forest instead of a tree is - what's the latest message? Do I have to check every node?
awt[asciilifeform]: *graph db
awt[asciilifeform]: Hmm actually not that bad: SELECT * FROM nodes ORDER BY json_extract(body, '$.timestamp') DESC LIMIT 1;