Show Idle (>14 d.) Chans
← 2023-05-08 | 2023-05-10 → ↓
10:10 asciilifeform http://logs.bitdash.io/pest/2023-05-08#1025846 << correct (still needs megatonne of revision, and asciilifeform again mired in salt mines)
10:10 bitbot 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?
~ 1 hours 22 minutes ~
11:33 awt asciilifeform: do you have a plan to become unmired or permanently mired?
11:33 asciilifeform awt: nope & nope
11:33 asciilifeform ~rng
11:34 asciilifeform ( hypothetically -- if, lol, 'exch rate grows a 0 and a half' -- perma-unmired. but 'if wishes were horses' etc )
11:35 awt my contract ended so I am pretty free for a while. gonna try to make the most of it.
11:35 asciilifeform and, conversely, suppose when asciilifeform gives up the ghost, can be termed 'perma-mired'.
11:38 asciilifeform awt: congrats (?) on the 'pretty free'
11:41 awt asciilifeform: ty (?) lol
11:56 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.
↖
~ 51 minutes ~
12:47 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,
12:47 bitbot 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.
12:47 phf pest://iOPjv7o9y8tz0FxeqKXawulIEYBK9Z9cXWCniNE8+z4= << hello, world
↖
12:48 phf should be an equivalent of log reference that we do now
12:48 phf then each client can do its own lookup, etc.
~ 1 hours 2 minutes ~
13:50 awt phf: yes I can see that. Should be able to insert a following line shomehow.
13:56 phf 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
~ 21 minutes ~
14:18 awt phf: could also do footnote style quotes (iOPjv7o9y8tz0FxeqKXawulIEYBK9Z9cXWCniNE8+z4=) (IBsM2cqkUtTU9pwDUD5nB9Xe6Z61+q8IuqK22R0UzNg=) that open up a pane when the message is selected.
14:31 phf well, i think that each client can do whatever ux, so we're discussing in-band format and behaviors.
14:32 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
14:33 awt phf: got it
14:34 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
14:35 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
14:36 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
14:39 phf http://logs.bitdash.io/pest/2023-05-09#a3d805168e646d9543fcb397755564a06fdd6c665632434dc0c51e73d8517905f21e1c1126bb213e3e10268e8a0c2972c85fcba72c9df06751680637f5a6688d :D
14:42 phf ah never mind it's 256, so more like #62b5bb83ed9289828f73e4f4d51c9b8a61e7bb57d25e2e539ae3e7916c5229e3
14:42 phf or #YrW7g+2SiYKPc+T01RybimHnu1fSXi5TmuPnkWxSKeM= in base64
~ 1 hours 7 minutes ~
15:49 signpost http://logs.bitdash.io/pest/2023-05-09#1025860 << hot
15:49 bitbot Logged on 2023-05-09 12:47:57 phf[4]: pest://iOPjv7o9y8tz0FxeqKXawulIEYBK9Z9cXWCniNE8+z4= << hello, world
15:52 signpost http://logs.bitdash.io/pest/2023-05-07#1025823 << should be apr 21, 2024 for next, at block 840,000
15:52 bitbot 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
~ 2 hours 40 minutes ~
18:32 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.
18:36 phf 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
~ 21 minutes ~
18:58 jonsykkel lemme chek wats in log
19:06 jonsykkel http://zzz.st/up/BMddoeQ5/
19:07 phf ah, ty
19:07 jonsykkel my pestron waits for ignore pakets after the sliceing, u sending those?
19:07 jonsykkel and times out if not get
19:07 jonsykkel cant see cuz i dont log them
19:08 phf hmm, i'm sending them, but on a pretty random schedule
19:08 phf yeah, the last timeout looks like that's what it is
19:09 jonsykkel theres step11-12 in the http://www.loper-os.org/pub/pest/pest_draft.html#44-rekeying
19:09 phf and those ignore packets should be with the new key slice?
19:10 jonsykkel thats how i interpreted it
19:10 jonsykkel the xored slices
19:11 jonsykkel Kn == K xor Sa xor Sb
19:11 phf yeah, but why wait for ignore?
19:12 phf 7 Rekeying
19:12 phf TODO
19:12 phf lol nevermind
19:12 jonsykkel ye its in the old one only
19:13 jonsykkel i guess the point of the ignores etc is to make sure both partys calced the same new key
↖
19:14 jonsykkel before delete old one
19:14 * 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
19:15 * asciilifeform absolutely refuses to maintain 2 flavours of spec src text
19:15 jonsykkel or maybe ur question was "why ignore and not just any packet"
19:15 phf 􏿽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
↖
19:15 bitbot 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
19:15 phf 􏿽f you're going to do that then there probably shouldn't be a timeout
↖
19:16 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'
19:19 phf so in other words there's a mandatory ignore after rekey
19:20 asciilifeform aaha
19:22 jonsykkel ok, i se
19:25 * asciilifeform haunted by suspicion that the rekey algo could be made simpler, or at least stated moar compactly; but not presently knows how
19:26 jonsykkel 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
19:26 bitbot 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
19:26 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
19:27 asciilifeform jonsykkel: there's a timeout 'Tk' , see old draft spec
19:27 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.'
19:27 jonsykkel asciilifeform: inded, replying to phfs
19:27 asciilifeform a
19:30 jonsykkel spek dosnt make entirely clear exactly at which point the rekeying is to be considered "complete" however
19:30 asciilifeform http://logs.bitdash.io/pest/2023-05-09#1025904 << rekey can fail simply from loss of 1 or moar of the pertinent packets
19:30 bitbot 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 on the other hand i
19:31 jonsykkel iirc my client considers it complete after the ignore recved
19:31 jonsykkel meaning, no timeout
19:32 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
19:33 asciilifeform ( after satisfied that the slices were baked independently )
19:33 phf word, i get it now
19:34 phf i wasn't really thinking about it, just going by spec
19:38 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
19:40 asciilifeform phf: wainot right away?
19:40 asciilifeform ('cubby' seems like an unnecessary moving part imho)
19:41 phf yeah, i'm not sure i think you're probably right
~ 19 minutes ~
20:00 awt 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?
20:00 awt *graph db
20:08 awt Hmm actually not that bad: SELECT * FROM nodes ORDER BY json_extract(body, '$.timestamp') DESC LIMIT 1;
← 2023-05-08 | 2023-05-10 → ↑

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

Theme: Light | Dark | System Default