Show Idle (>14 d.) Chans
← 2022-12-07 | 2022-12-09 → ↓
phf[asciilifeform]: 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
bitbot[asciilifeform]: 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.
phf[asciilifeform]: makes this very point that you just made
unpx[asciilifeform]: 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
unpx[asciilifeform]: Still broken?
unpx[asciilifeform] is working on some Grobner basis stuff
unpx[asciilifeform]: Hello lobbes!
lobbes[asciilifeform]: hi unpx (odd, I only see your hello from the logs, not my station; possibly it is eating through the backlog atm)
lobbes[asciilifeform]: ah yup, there's the message history. Nice!
awt[asciilifeform]: welcome lobbes!
asciilifeform: welcome lobbes !
asciilifeform: unpx: i do see your msgs (and not only in log.)
bitbot[asciilifeform]: 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
asciilifeform sadly not has the cycles atm to properly read. but seems intended as ffa-style 'from 1st principles' Right Thing
bitbot[asciilifeform]: 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
unpx[asciilifeform]: 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
unpx[asciilifeform]: how other computer algebra system do.
asciilifeform: unpx: added yer at entry from pgpgram earlier; use the key asciilifeform sent you, oughta work
signpost[asciilifeform]: phf: speaking of peerings, dunno if this was lost in the pest noise but http://logs.bitdash.io/pest/2022-12-05#1017580
bitbot[asciilifeform]: Logged on 2022-12-05 14:07:03 signpost: phf: http://paste.deedbot.org/?id=RUKq
asciilifeform: lobbes: observe that you can operate normally while the thing getdata's
signpost[asciilifeform]: hilariously just as I do this, I get another mystery replay
signpost[asciilifeform]: yup, seeing your messages via bitbot atm
lobbes[asciilifeform]: 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
asciilifeform: unpx: re: algebratrons, of possible interest re state of art ('80s! and afaik still unsurpassed)
dulapbot: (trilema) 2019-02-04 asciilifeform: http://www.loper-os.org/pub/stoutemyer/index.html << for the l0gz, and for all 'derive' aficionados.
signpost[asciilifeform]: unpx, I'll bake you a peering key too if you like.
unpx[asciilifeform]: signpost, I'd like to
signpost[asciilifeform]: unpx: did you ever have a key registered with deedbot?
bitbot[asciilifeform]: (asciilifeform) 2022-10-21 unpx: I should somehow connect to deedbot to register the GPG public key
unpx[asciilifeform]: I tried, but looks like deedbot didn't add it, signpost
signpost[asciilifeform]: yeah, thing needs an out-of-band registration hole since we don't have n00b lobbies for pest yet
signpost[asciilifeform]: got a link to key somewhere?
signpost[asciilifeform]: actually, you should be able to register here
signpost[asciilifeform]: or at least if it breaks I'll fix the attempt
signpost[asciilifeform]: hm! deedbot gone
dulapbot: Logged on 2022-10-25 09:38:51 unpx[busybot]: !!register https://unpx.net/d4/gpg.txt
unpx[asciilifeform]: asciilifeform, tried, can't reach you somehow
signpost[asciilifeform]: looks like it's still catching up.
signpost[asciilifeform]: already reg'd ya
signpost[asciilifeform]: from prior input, which contained the [foo][blah]
signpost[asciilifeform]: seems like simplest fix to deedbot might be to make !!register take a requested-nick arg, !!register <nick> <key-url>
signpost[asciilifeform]: 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.
signpost[asciilifeform]: unpx says perhaps addrcast got him my IP before he had time to update his AT
signpost[asciilifeform]: makes intros that much more convenient.
bitbot[asciilifeform]: Logged on 2022-12-08 12:05:32 unpx[jonsykkel]: asciilifeform, tried, can't reach you somehow
deedbot[asciilifeform]: FC66C0C5D98C42A1D4A98B6B42F9985AFAB953C4 is already registered as signpost.
signpost[asciilifeform]: alrighty, deedbot registrations will work for relayed peers now
signpost[asciilifeform]: ^ updated with new param
signpost[asciilifeform]: http://wot.deedbot.org/ << fixed the styles causing overlapping graph too; report in if anyone sees a buggered up page pls
signpost[asciilifeform]: still regenerating, so profile pages will be updated soon.
phf[asciilifeform]: signpost, i haven't use for peering yet, because i'm still single station
phf[asciilifeform]: i'm still trying to figure out how to do packet-insert properly
phf[asciilifeform]: actually, maybe i could just add multipeer, meanwhile. because all i need to do is a dup check…
phf[asciilifeform]: i'm trying to understand how multiple parallel netchains are supposed to work…
signpost[asciilifeform]: ah ok. not a rush, key will be there when usable.
shinohai[busybot]: if unpx rejoins, will rate. (Saw in nosuchlabs logs he still has peering difficulties).
signpost[asciilifeform]: shinohai: guy's in wot db now
signpost[asciilifeform]: !!v 4271EEA3A812B0ECB01B7C05AC17FD065D7696A3316505630ECF229C12C10B02
asciilifeform: !!rate unpx 1 maths fella
asciilifeform: !!v 73DA01D5B98AC8387908190CA9CEE75EA83CA0FF38A0AD229A6569DE6D775F97
deedbot[asciilifeform]: asciilifeform rated unpx 1 << maths fella
bitbot[asciilifeform]: Logged on 2022-12-08 12:31:44 signpost: !!register signpost http://butts.com/key.txt
signpost[asciilifeform]: was seeing that I got the right error message back.
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
bitbot[asciilifeform]: Logged on 2022-12-08 12:48:37 phf[awt]: i'm trying to understand how multiple parallel netchains are supposed to work…
asciilifeform: ... for chronological getting of 'recent' msgs
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
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')
asciilifeform: ( naturally a msg could have any # of successors per netchain )
phf[asciilifeform]: 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)
asciilifeform: tree, aha
asciilifeform: and yea, currently arbitrary, which is Wrong Thing
asciilifeform leaning towards 'need new knob to make threading go properly' but not yet figured out precisely where
asciilifeform: this is why not 'unpredrafted' the predraft spec yet
phf[asciilifeform]: 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
asciilifeform: there's possibly a painful breaking change req'd
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
phf[asciilifeform]: yeah that makes sense
phf[asciilifeform]: which brings back the whole multichains issue
phf[asciilifeform]: 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.
asciilifeform: aha, as asciilifeform understands, already happens regularly
phf[asciilifeform]: 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
asciilifeform: correct
phf[asciilifeform]: i think awt said his are sorted by timestamp, but then you're in a no mans land of drifting clocks
asciilifeform: per asciilifeform's original intent, netchain of $msg was 'what was at the bottom of my screen when i wrote $msg'
phf[asciilifeform]: 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
asciilifeform: ideally should never be necessary to use timestamps for sort
asciilifeform: (given as indeed they aint reliably ordered)
phf[asciilifeform]: asciilifeform, sure, in which case you're using arrival time, which is even more arbitrary
asciilifeform: asciilifeform included timestamp orig. strictly as anti-replay booby
phf[asciilifeform]: i'm still talking about the case of A<B<C A<D<E A<B<X<Y
signpost[asciilifeform]: !!rate zx2c4 2 linux kernel dev and wireguard author
signpost[asciilifeform]: !!v C0B7CB4E3D4C257E6E711D7E374DF8569C512E4B9787DD1A936B3A72491BC488
deedbot[asciilifeform]: signpost rated zx2c4 2 << linux kernel dev and wireguard author
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)
asciilifeform: imho pestron oughta simply reject'em, unless in fact its db is empty
phf[asciilifeform]: yeah, but that's not possible unless you have mechanism to join multiple chains
asciilifeform: (a new talker oughta sit still long enuff to receive even 1 msg)
asciilifeform: phf: they oughta be joined at the roots
asciilifeform: i.e. ought not be possible to have wholly disjoint subchains
phf[asciilifeform]: what are roots?
asciilifeform: if A <- B <- C, and e.g. B <- P, B <- Q, you have subtrees joined at roots, and all is well
phf[asciilifeform]: so just to clarify < in my diagram is "packet's netchain property", of which there's only one
asciilifeform: roots being the linkages of the 'top-level' chain, there
asciilifeform: i.e. you can walk from P and Q back to B, then to A
phf[asciilifeform]: ah, i get it, you're walking from the opposite direction
asciilifeform: that's how getdata walks
asciilifeform: atm there's no way to walk 'forward'
phf[asciilifeform]: getdata walks from e.g. C to A
asciilifeform: correct
phf[asciilifeform]: 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
asciilifeform: the trouble is, presently a n00b can't retrieve 'world' if all he's got is a coupla recent msg
phf[asciilifeform]: that's not the only problem
asciilifeform: seems to be no way to escape adding 'forward walks' , if want to fix this
phf[asciilifeform]: 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
phf[asciilifeform]: *with a packet loss
asciilifeform: correct, tho unlikely if erryone were regularly prodding
phf[asciilifeform]: that's invalid
asciilifeform: (and observe that there is no way to reduce chance of 'lost but no one knows' to 0, even in principle)
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
asciilifeform: (next time you send with a working cable)
phf[asciilifeform]: 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
asciilifeform: so eventually the lost packet gets 'unlost'
phf[asciilifeform]: asciilifeform, that's not correct
asciilifeform: phf: hm?
phf[asciilifeform]: please reread my example!
asciilifeform rereads..
asciilifeform: phf: did asciilifeform read the notation correctly, i.e. lost packet Q netchain-points to A ?
asciilifeform: sender of Q sends anuther packet, at some later time, R. selfchain of R points to Q.
asciilifeform: receivers of R getdata for Q. no ?
phf[asciilifeform]: 􏿽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
phf[asciilifeform]: 􏿽rrive/having higher timestamp. so the station is going to use C to netchain
asciilifeform: phf: correct re netchain, per current scheme
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)
phf[asciilifeform]: right, the way this is recovered is because you have selfchain
asciilifeform: (cuz no fwd walks presently)
phf[asciilifeform]: 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
asciilifeform: not if erryone has working periodic prod
asciilifeform: (then -- peers of sender notice that his selfchain points to sumthing they haven't got, and they getdata for it)
phf[asciilifeform]: that's not correct
phf[asciilifeform]: you're still missing the specifics of this example
phf[asciilifeform]: oh right, right prod also sends selfchain. right
asciilifeform: prod, per current (and prev.) spec, sends 1) selfchain (broadcast) 2) netchain (broadcast) 3) selfchain (with $peer directmsgs)
asciilifeform: so handles 'sepsis' for so long as the operator's station did not also get sepsis at same time
asciilifeform: 'prod' presently is what we have instead of synchronicity/acks
phf[asciilifeform]: 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"
asciilifeform: selfchain is intended to be contiguous, per operator -- if you get 1 msg from $operator, can get all prev. msgs from him
asciilifeform: fwd walk.
asciilifeform: but tricky, aha
phf[asciilifeform]: well, selfchain doesn't have any of these problems, on account of being objectively linear
bitbot[asciilifeform|asciilifeform]: 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')
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.
asciilifeform not likes the proliferation of moving parts, but sumthing like above is prolly necessary
phf[asciilifeform]: 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
phf[asciilifeform]: 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
phf[asciilifeform]: which is also necessarily hearsay, so is that even a problem :>
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
asciilifeform: ( hence 'broken heart' idea earlier, so to avoid eternal hammer of getdata when encountering said hole )
asciilifeform: ditto a peer who emits a msg that is chained to an invalid (violates format rule somehow, i.e. bad uniturd) msg
asciilifeform: the invalid msg ought not to simply get discarded, gotta save it with a 'don't try to display' mark or equiv.
asciilifeform: (otherwise potentially eternal getdata hammer for it)
asciilifeform: this not yet covered in spec.
phf[asciilifeform]: right, ignoring the case of subtly maliciuos peer
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'
asciilifeform: (to take 1 example, prolly oughta rate-limit chained msgs. currently not in spec at all)
asciilifeform: right nao sumbody could easily shit out 1TB of chained msgs and fill errybody's hdd.
asciilifeform: ( aaand not even speaking of straight-out lulbugs )
bitbot[asciilifeform]: Logged on 2022-10-05 16:17:44 asciilifeform[6]: in otherlulz, lulzy sideffects of yest.'s blatta bugola.
asciilifeform: ... at the very least, msg-eater oughta hard-prioritize immeds/directs over hearsays in all cases (and remain responsive to operator commands nomatterwhat)
asciilifeform: 1 possible scheme would be -- quota: n peers, erry peer can occupy at most 1/n bw, 1/n cpu, etc
asciilifeform: (outta whatever remains from processing incoming/unidentified blackpackets at line rate)
phf[asciilifeform]: 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
phf[asciilifeform]: 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
asciilifeform: phf: asciilifeform was thinking moar in the vein of careful algo design + 'round robin', rather than a custom scheduler with preemption
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)
asciilifeform: i.e. no need to actually count cpu cycles or preempt an operation.
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
lobbes[asciilifeform]: http://logs.bitdash.io/pest/2022-12-08#1017793 << peered! Looks like packets are being received
bitbot[asciilifeform]: Logged on 2022-12-08 11:41:26 signpost: lobbes: http://paste.deedbot.org/?id=_G-o << peering info
lobbes[asciilifeform]: 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
lobbes[asciilifeform]: g sent to stdout
lobbes[asciilifeform]: Possibly just a peculiarity with python 2.6 versus python 2.7
awt[asciilifeform]: lol lobbes you just had to find an even earlier version of python
lobbes[asciilifeform]: lol. In retrospect I suppose this is precisely the use case for a virtualenv. Ah well, it was still an enjoyable exercise
asciilifeform: lobbes: nifty
asciilifeform: $ticker btc usd
busybot: Current BTC price in USD: $17203.68
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.
asciilifeform: this is intentional.
asciilifeform: a key design principle is that a third party oughtn't be able to distinguish a pest box from an unused ip.
asciilifeform: (assuming it aint hosting anyffin else that sits on a port)
← 2022-12-07 | 2022-12-09 → ↑
Random(pest) | Download hourly DB snapshot | Get Source Code