Show Idle (>14 d.) Chans
← 2022-12-07 | 2022-12-09 → ↓
09:10 phf http://logs.bitdash.io/pest/2022-12-07#1017772 << one of the first books that made me "sad" https://www.elsevier.com/books/swarm-intelligence/eberhart/978-1-55860-595-4 because i realized that the "man in an ivory tower" is not a thing
↖
09:10 bitbot Logged on 2022-12-07 22:28:20 signpost: grows convinced that the distributed computation is the thing, or is at least more thingly than individual meat puppets.
09:11 phf makes this very point that you just made
~ 50 minutes ~
10:01 unpx Currently thinking if I should publish my code that implements some number theoretic algorithms, this is my current progress: https://unpx.net/d4/articles/2022-11-alchemy.xhtml
↖
10:01 unpx https://static.livecodingbook.toplap.org/books/livecoding.pdf
10:01 unpx Still broken?
10:01 * unpx is working on some Grobner basis stuff
~ 56 minutes ~
10:58 lobbes hello #pest
10:58 unpx Hello lobbes!
11:01 lobbes hi unpx (odd, I only see your hello from the logs, not my station; possibly it is eating through the backlog atm)
11:03 lobbes ah yup, there's the message history. Nice!
11:14 awt welcome lobbes!
~ 22 minutes ~
11:37 asciilifeform welcome lobbes !
11:37 signpost howdy lobbes!
11:39 asciilifeform unpx: i do see your msgs (and not only in log.)
11:39 asciilifeform http://logs.bitdash.io/pest/2022-12-08#1017778 << neato.
11:39 bitbot Logged on 2022-12-08 10:01:35 unpx[4]: Currently thinking if I should publish my code that implements some number theoretic algorithms, this is my current progress: https://unpx.net/d4/articles/2022-11-alchemy.xhtml
11:40 * asciilifeform sadly not has the cycles atm to properly read. but seems intended as ffa-style 'from 1st principles' Right Thing
11:41 signpost lobbes: http://paste.deedbot.org/?id=_G-o << peering info
↖
11:46 asciilifeform unpx: peering info for asciilifeform
11:46 signpost http://logs.bitdash.io/pest/2022-12-08#1017775 << ty, just snagged a copy
11:46 bitbot Logged on 2022-12-08 09:10:46 phf[awt]: http://logs.bitdash.io/pest/2022-12-07#1017772 << one of the first books that made me "sad" https://www.elsevier.com/books/swarm-intelligence/eberhart/978-1-55860-595-4 because i realized that the "man in an ivory tower" is not a thing
11:48 unpx Yes, I published that to force myself on working on it in well defined chunks instead of trying to put something by time to time without a goal. The posts will be more about how I rewrote something and why, rather than here is how to do X, because the latter can already be found in books like the ones I mention or looking
11:48 unpx how other computer algebra system do.
11:49 asciilifeform unpx: added yer at entry from pgpgram earlier; use the key asciilifeform sent you, oughta work
11:50 lobbes heya signpost, asciilifeform! Looks like my station is still processing message history (seeing replays from feb 2022 atm). I'm using blatta with the pure python serpent versus mcrypt, so I think that is adding to my lag. Gonna let it chug for a few hours then hopefully I'll be caught up
11:50 signpost phf: speaking of peerings, dunno if this was lost in the pest noise but http://logs.bitdash.io/pest/2022-12-05#1017580
11:50 bitbot Logged on 2022-12-05 14:07:03 signpost: phf: http://paste.deedbot.org/?id=RUKq
11:51 signpost hilariously just as I do this, I get another mystery replay
11:51 asciilifeform lobbes: observe that you can operate normally while the thing getdata's
11:51 signpost yup, seeing your messages via bitbot atm
11:53 asciilifeform unpx: re: algebratrons, of possible interest re state of art ('80s! and afaik still unsurpassed)
11:54 dulapbot (trilema) 2019-02-04 asciilifeform: http://www.loper-os.org/pub/stoutemyer/index.html << for the l0gz, and for all 'derive' aficionados.
11:59 unpx Oh nice
11:59 signpost unpx, I'll bake you a peering key too if you like.
12:01 unpx signpost, I'd like to
12:01 signpost sure, sec
12:02 signpost unpx: did you ever have a key registered with deedbot?
12:02 signpost http://logs.bitdash.io/asciilifeform/2022-10-21#1114152 << looks like possibly not
12:02 bitbot (asciilifeform) 2022-10-21 unpx: I should somehow connect to deedbot to register the GPG public key
12:02 unpx I tried, but looks like deedbot didn't add it, signpost
12:03 signpost yeah, thing needs an out-of-band registration hole since we don't have n00b lobbies for pest yet
12:03 signpost got a link to key somewhere?
12:03 signpost actually, you should be able to register here
12:03 signpost or at least if it breaks I'll fix the attempt
12:03 signpost !!help
12:04 signpost hm! deedbot gone
12:04 signpost sec
12:04 unpx signpost, http://logs.nosuchlabs.com/log/pest/2022-10-25#1014460
12:04 dulapbot Logged on 2022-10-25 09:38:51 unpx[busybot]: !!register https://unpx.net/d4/gpg.txt
12:05 unpx asciilifeform, tried, can't reach you somehow
↖
12:08 signpost !!help
12:10 deedbot http://deedbot.org/help.html
12:12 signpost !!key unpx
12:13 deedbot http://deedbot.org/help.html
12:13 signpost looks like it's still catching up.
12:13 deedbot http://wot.deedbot.org/C9293B16A16041E0D67790A7D5C56A34D8FB728A.asc
12:13 signpost there we go
12:14 unpx !!register http://paste.deedbot.org/?id=_KeG
12:14 signpost already reg'd ya
12:14 unpx Thanks
12:14 signpost from prior input, which contained the [foo][blah]
12:16 signpost unpx: http://paste.deedbot.org/?id=shD2
12:18 signpost seems like simplest fix to deedbot might be to make !!register take a requested-nick arg, !!register <nick> <key-url>
12:19 signpost was just a convenience that it took w/e nick currently in use by the sender; sender could /nick fart at any time to reg something else.
12:23 signpost unpx says perhaps addrcast got him my IP before he had time to update his AT
12:23 signpost pretty cool
12:24 signpost makes intros that much more convenient.
12:29 asciilifeform http://logs.bitdash.io/pest/2022-12-08#1017825 << same ip as 2w ago ?
12:29 bitbot Logged on 2022-12-08 12:05:32 unpx[jonsykkel]: asciilifeform, tried, can't reach you somehow
12:31 signpost !!register signpost http://butts.com/key.txt
↖
12:31 deedbot FC66C0C5D98C42A1D4A98B6B42F9985AFAB953C4 is already registered as signpost.
12:32 signpost alrighty, deedbot registrations will work for relayed peers now
12:32 signpost !!help
12:32 deedbot http://deedbot.org/help.html
12:32 signpost ^ updated with new param
12:40 signpost http://wot.deedbot.org/ << fixed the styles causing overlapping graph too; report in if anyone sees a buggered up page pls
12:40 signpost still regenerating, so profile pages will be updated soon.
12:45 phf signpost, i haven't use for peering yet, because i'm still single station
12:46 phf i'm still trying to figure out how to do packet-insert properly
12:47 phf actually, maybe i could just add multipeer, meanwhile. because all i need to do is a dup check…
12:48 phf i'm trying to understand how multiple parallel netchains are supposed to work…
↖
12:50 signpost ah ok. not a rush, key will be there when usable.
12:51 shinohai if unpx rejoins, will rate. (Saw in nosuchlabs logs he still has peering difficulties).
12:51 signpost shinohai: guy's in wot db now
12:52 signpost !!rate unpx 1 https://unpx.net/d4/
12:52 deedbot Get your OTP: http://paste.deedbot.org/?id=5DX1
12:53 signpost !!v 4271EEA3A812B0ECB01B7C05AC17FD065D7696A3316505630ECF229C12C10B02
12:53 deedbot signpost rated unpx 1 << https://unpx.net/d4/
~ 25 minutes ~
13:18 asciilifeform !!rate unpx 1 maths fella
13:18 deedbot Get your OTP: http://paste.deedbot.org/?id=NNmy
13:19 asciilifeform !!v 73DA01D5B98AC8387908190CA9CEE75EA83CA0FF38A0AD229A6569DE6D775F97
13:19 deedbot asciilifeform rated unpx 1 << maths fella
13:22 phf http://logs.bitdash.io/pest/2022-12-08#1017845 << wut
13:22 bitbot Logged on 2022-12-08 12:31:44 signpost: !!register signpost http://butts.com/key.txt
13:23 signpost was seeing that I got the right error message back.
13:23 asciilifeform http://logs.bitdash.io/pest/2022-12-08#1017856 << asciilifeform still thinking re possible need for ~3~ chain hashes rather than 2 ( if netchain starts being used for threading ), but imho avoidable , introduced 'inv' ( 5.4.9 in predraft spec ) for chronological g
13:23 bitbot Logged on 2022-12-08 12:48:37 phf[awt]: i'm trying to understand how multiple parallel netchains are supposed to work…
13:24 asciilifeform ... for chronological getting of 'recent' msgs
13:24 asciilifeform if operating per previous specs, is possible to walk netchain & selfchain and still miss a subthread (if such existed) because of where you started walk from
13:26 asciilifeform ( alternatively, getdata response could return a flag bit, say in formerly 'reserved' field, indicating existence of successor, which one could then fetch via a hypothetical 'getnext')
↖
13:26 phf asciilifeform, i'm talking about the case when you have message A and messages B and C that both reference A as netchain. from that point on D is essentially arbitrary (depends on if B or C arrived last, or have later timestamp, whichever)
13:26 asciilifeform ( naturally a msg could have any # of successors per netchain )
13:27 asciilifeform tree, aha
13:27 asciilifeform and yea, currently arbitrary, which is Wrong Thing
13:28 * asciilifeform leaning towards 'need new knob to make threading go properly' but not yet figured out precisely where
13:28 phf which also made me wonder, which message exactly should prod return? the latest one recieved, or whichever the station considers to be the latest one by its own sort order
13:28 asciilifeform this is why not 'unpredrafted' the predraft spec yet
13:28 asciilifeform there's possibly a painful breaking change req'd
13:30 asciilifeform phf: per intent of current spec, the 1 that the station would use as default netchain if it were to transmit a msg at the time of issuing the prod
13:31 phf yeah that makes sense
13:31 phf which brings back the whole multichains issue
13:31 phf you can easily have a case when you have A<B<C A<D<E A<B<X<Y and more because of network congestion, packet loss, etc.
13:32 asciilifeform aha, as asciilifeform understands, already happens regularly
13:32 phf and when it lands, and everyone's up to date, there's no authorative way, if it's C E or Y that should be used to netchain
13:33 asciilifeform correct
13:33 phf i think awt said his are sorted by timestamp, but then you're in a no mans land of drifting clocks
13:33 asciilifeform per asciilifeform's original intent, netchain of $msg was 'what was at the bottom of my screen when i wrote $msg'
13:34 phf if e.g. your drift is at the limit of what's acceptable drift is (5 minutes?) it's possible that your message will be chosen for the next netchain, only because your clock is running 5 minutes late
13:34 asciilifeform ideally should never be necessary to use timestamps for sort
13:34 asciilifeform (given as indeed they aint reliably ordered)
13:35 phf asciilifeform, sure, in which case you're using arrival time, which is even more arbitrary
13:35 asciilifeform asciilifeform included timestamp orig. strictly as anti-replay booby
13:35 phf i'm still talking about the case of A<B<C A<D<E A<B<X<Y
13:35 asciilifeform aha
13:36 signpost !!rate zx2c4 2 linux kernel dev and wireguard author
13:36 deedbot Get your OTP: http://paste.deedbot.org/?id=-WlA
13:37 signpost !!v C0B7CB4E3D4C257E6E711D7E374DF8569C512E4B9787DD1A936B3A72491BC488
13:37 deedbot signpost rated zx2c4 2 << linux kernel dev and wireguard author
13:37 asciilifeform per intent of new spec, netchain oughta be able to point to any previously-existing msg. but this opens q of how to sort (and wat-do with messages where netchain==0)
13:38 asciilifeform imho pestron oughta simply reject'em, unless in fact its db is empty
13:38 phf yeah, but that's not possible unless you have mechanism to join multiple chains
13:38 asciilifeform (a new talker oughta sit still long enuff to receive even 1 msg)
13:38 asciilifeform phf: they oughta be joined at the roots
13:39 asciilifeform i.e. ought not be possible to have wholly disjoint subchains
13:39 phf what are roots?
13:40 phf so just to clarify < in my diagram is "packet's netchain property", of which there's only one
13:40 asciilifeform if A <- B <- C, and e.g. B <- P, B <- Q, you have subtrees joined at roots, and all is well
13:40 asciilifeform roots being the linkages of the 'top-level' chain, there
13:40 phf ah, i get it, you're walking from the opposite direction
13:40 asciilifeform i.e. you can walk from P and Q back to B, then to A
13:41 asciilifeform aha
13:41 asciilifeform that's how getdata walks
13:41 asciilifeform atm there's no way to walk 'forward'
13:41 phf ugh
13:41 phf getdata walks from e.g. C to A
13:42 asciilifeform correct
13:42 phf and with getdata there's no way to for example get all the possible packets, in the diagram above there's no way to get from e.g. C to P or Q
13:42 asciilifeform aaha!
13:42 asciilifeform the trouble is, presently a n00b can't retrieve 'world' if all he's got is a coupla recent msg
13:43 phf that's not the only problem
13:43 asciilifeform seems to be no way to escape adding 'forward walks' , if want to fix this
13:43 phf the other problem is that we a packet loss, it's possible to get to a state where some packets were lost and nobody knows
13:43 phf *with a packet loss
13:43 asciilifeform correct, tho unlikely if erryone were regularly prodding
13:43 phf that's invalid
13:44 asciilifeform (and observe that there is no way to reduce chance of 'lost but no one knows' to 0, even in principle)
13:44 phf e.g. "everyone" sees A<B<C, one station has A<Q, but Q is lost, then B lands, no that one station sent out a packet that nobody knows about
13:45 asciilifeform well if you sent out a packet but yer cable was unplugged, the next time you send it will have selfchain pointing to the lost packet, and folx will getdata for it
13:45 asciilifeform (next time you send with a working cable)
13:45 phf asciilifeform, that's not correct
13:45 asciilifeform so eventually the lost packet gets 'unlost'
13:45 phf please reread my example!
13:45 asciilifeform phf: hm?
13:46 * asciilifeform rereads..
13:47 asciilifeform phf: did asciilifeform read the notation correctly, i.e. lost packet Q netchain-points to A ?
13:47 phf yes
13:47 asciilifeform ok;
13:48 asciilifeform sender of Q sends anuther packet, at some later time, R. selfchain of R points to Q.
13:48 phf 􏿽you have a chain A<B<C that's going on and is shared, but you have one station that recieved A and got congested. at this point it can send out any number of packets, that get lost, THEN recieve outstanding B and C. now C is the latest in the netchain, on account of being last to a
13:48 phf 􏿽rrive/having higher timestamp. so the station is going to use C to netchain
13:48 asciilifeform receivers of R getdata for Q. no ?
13:49 asciilifeform phf: correct re netchain, per current scheme
13:50 asciilifeform but assuming sender of Q at some time sends R, Q will get retrieved by those who see R. problem however is that it will be retrieved ~only~ by those who see R (or a successor of R)
13:51 phf right, the way this is recovered is because you have selfchain
13:51 asciilifeform (cuz no fwd walks presently)
13:51 asciilifeform aha
13:52 phf of course in the case of "got sepsis, going to hospital", the selfchain might not continue for weeks, so nobody will get those messages until much later "i'm baaack!" :p
13:53 asciilifeform not if erryone has working periodic prod
13:53 phf that's not correct
13:53 phf you're still missing the specifics of this example
13:53 asciilifeform (then -- peers of sender notice that his selfchain points to sumthing they haven't got, and they getdata for it)
13:53 phf oh right, right prod also sends selfchain. right
13:53 asciilifeform aha
13:54 asciilifeform prod, per current (and prev.) spec, sends 1) selfchain (broadcast) 2) netchain (broadcast) 3) selfchain (with $peer directmsgs)
13:55 asciilifeform so handles 'sepsis' for so long as the operator's station did not also get sepsis at same time
13:55 asciilifeform 'prod' presently is what we have instead of synchronicity/acks
13:56 phf i guess you could have some kind of getdata, that asks for all the packets that are being referenced by X, e.g. in A<B<C B<P B<Q can say "getdatax B" and get C P and Q. but that violates your whole "no amplification"
13:56 asciilifeform selfchain is intended to be contiguous, per operator -- if you get 1 msg from $operator, can get all prev. msgs from him
13:56 asciilifeform fwd walk.
13:56 asciilifeform but tricky, aha
13:57 asciilifeform ( 1 possible scheme )
13:57 bitbot Logged on 2022-12-08 13:26:28 asciilifeform[jonsykkel|deedbot|awt]: ( alternatively, getdata response could return a flag bit, say in formerly 'reserved' field, indicating existence of successor, which one could then fetch via a hypothetical 'getnext')
13:57 phf well, selfchain doesn't have any of these problems, on account of being objectively linear
13:57 asciilifeform aha
14:00 asciilifeform the correct way to 'walk fwd' would prolly be a cmd which returns # of 'inv' payloads req'd to catalogue all successors; which then could request 'inv's and getdata for.
14:00 * asciilifeform not likes the proliferation of moving parts, but sumthing like above is prolly necessary
14:03 phf i guess the remaining hole is that a newb might not be able to get a complete log under some specific circumstances, since netchain/selfchain mostly covers it
14:03 phf some birst of "and fuck you all i'm never coming back", that just happened to go into a separate branch, and then there's never been any more messages from that station
14:03 phf *burst
14:04 phf which is also necessarily hearsay, so is that even a problem :>
14:12 asciilifeform a peer from whom one sees msg with unknown (missed) selfchain predecessor, who drops and never seen again, will indeed leave a perma-hole in the log. but if such holes handled correctly, not mega-problem ultimately
14:12 asciilifeform ( hence 'broken heart' idea earlier, so to avoid eternal hammer of getdata when encountering said hole )
14:13 asciilifeform ditto a peer who emits a msg that is chained to an invalid (violates format rule somehow, i.e. bad uniturd) msg
14:14 asciilifeform the invalid msg ought not to simply get discarded, gotta save it with a 'don't try to display' mark or equiv.
14:14 asciilifeform (otherwise potentially eternal getdata hammer for it)
14:14 asciilifeform this not yet covered in spec.
14:27 phf right, ignoring the case of subtly maliciuos peer
14:38 asciilifeform subtly (or not) malicious peer can do various annoying things. from pov of protocol design, q re subj is how to: 1) make immed. obv. ~which~ peer 2) limit same to 'annoying' rather than e.g. 'makes chain perma-inedible'
14:39 asciilifeform (to take 1 example, prolly oughta rate-limit chained msgs. currently not in spec at all)
14:39 asciilifeform right nao sumbody could easily shit out 1TB of chained msgs and fill errybody's hdd.
14:41 asciilifeform ( aaand not even speaking of straight-out lulbugs )
14:41 bitbot Logged on 2022-10-05 16:17:44 asciilifeform[6]: in otherlulz, lulzy sideffects of yest.'s blatta bugola.
14:44 asciilifeform ... at the very least, msg-eater oughta hard-prioritize immeds/directs over hearsays in all cases (and remain responsive to operator commands nomatterwhat)
14:47 asciilifeform 1 possible scheme would be -- quota: n peers, erry peer can occupy at most 1/n bw, 1/n cpu, etc
14:48 asciilifeform (outta whatever remains from processing incoming/unidentified blackpackets at line rate)
14:49 phf kind of wish™ there was automatic machinery for that kind of stuff on the language level. at present the only language i know that supports "max n-cycles" on environment level is lua
14:51 phf it's a pain to write anyway, ough to have a rate limiter on decoder, that backs off to in-memory store, that backs off to drive store, that caps out at some particular size, and then starts evicting old or rejecting new or whatever . ain't nobody got time for that
~ 57 minutes ~
15:49 asciilifeform phf: asciilifeform was thinking moar in the vein of careful algo design + 'round robin', rather than a custom scheduler with preemption
15:50 asciilifeform ( e.g., what's example of a slow op? let's say getdata -- which may load from disk. so $peer1 asks for getdata, but if he asks again, it sits until erry other peer's possibly queued getdata is handled; etc)
15:51 asciilifeform i.e. no need to actually count cpu cycles or preempt an operation.
15:53 asciilifeform as for rate limit on decoder, is rather easy -- pick a rate you know the box can handle (the hard part is determining the rate) and throw out incoming msgs as req'd
~ 4 hours 59 minutes ~
20:53 lobbes http://logs.bitdash.io/pest/2022-12-08#1017793 << peered! Looks like packets are being received
20:53 bitbot Logged on 2022-12-08 11:41:26 signpost: lobbes: http://paste.deedbot.org/?id=_G-o << peering info
20:54 signpost cool, yep!
20:59 lobbes I've posted some of my pest (blatta-9971) crib-notes up on my blog. Most likely only of use to me, with the possible exception of the fix I applied to line 71 of blatta/batta in order to get loggin
20:59 lobbes g sent to stdout
20:59 lobbes Possibly just a peculiarity with python 2.6 versus python 2.7
~ 1 hours 5 minutes ~
22:04 awt lol lobbes you just had to find an even earlier version of python
~ 31 minutes ~
22:35 lobbes lol. In retrospect I suppose this is precisely the use case for a virtualenv. Ah well, it was still an enjoyable exercise
22:41 asciilifeform lobbes: nifty
22:41 asciilifeform $ticker btc usd
22:42 busybot Current BTC price in USD: $17203.68
22:49 asciilifeform lobbes: fwiw if a box containing pestron is config'd as rec'd in orig spec (i.e. icmp disabled) yer nmap scan won't work.
↖
22:49 asciilifeform this is intentional.
22:51 asciilifeform a key design principle is that a third party oughtn't be able to distinguish a pest box from an unused ip.
22:52 asciilifeform (assuming it aint hosting anyffin else that sits on a port)
22:53 asciilifeform ( see also. )
← 2022-12-07 | 2022-12-09 → ↑

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

Theme: Light | Dark | System Default