Show Idle (>14 d.) Chans
← 2022-09-06 | 2022-09-08 → ↓
crtdaydreams[asciilifeform]: hardcopy of sicp came today :D
crtdaydreams[asciilifeform]: http://logs.bitdash.io/pest/2022-09-06#1012359 << handle is "crt"daydreams, not "steampunk"daydreams
bitbot[asciilifeform]: Logged on 2022-09-06 18:16:22 asciilifeform[5]: steam -- simpler, mechanically, and -- with sumthing resembling modern machining -- with turbine, ~similarly efficient to the carburetted 'ice'
crtdaydreams[asciilifeform]: in all rationale though, defo merit for i.e. boiler-powered workshop using old skool belts and pulleys
crtdaydreams[asciilifeform]: high torque applications
crtdaydreams[asciilifeform]: but then again, wai mess with steam machine wen perfectly good D7 in shed that can last over9000 hours
crtdaydreams[asciilifeform]: be better off using the water for e.g. electrolysis
crtdaydreams[asciilifeform]: or better yet; Drink it. Fresh water might be scarcity in apocalypse
bitbot[asciilifeform]: Logged on 2022-09-06 20:53:49 asciilifeform[jonsykkel|crawlerbot|billymg]: ( laff, but occasional crackpot actually proposes 'compressed air car' in earnest. 'folx who can't do arithmetic are doomed to talk nonsense'(tm)(r)(jmc) )
crtdaydreams[asciilifeform]: perhaps merit to steam with complexity, could make on home lathe & mill if in a pinch
crtdaydreams[asciilifeform]: will always have shit to burn and water to boil
crtdaydreams[asciilifeform]: http://logs.bitdash.io/pest/2022-09-06#1012368 << what like cap? not sure what adding a tank would do, there's a finite potential to which you can store superheated pressurized steam efficiently
bitbot[asciilifeform]: Logged on 2022-09-06 21:05:50 jonsykkel: im joking, but jokes aside, u would have the steam engine + tank to solve the slow to revv problem. why wouldnt that work
crtdaydreams[asciilifeform]: all it would do is allow you to continue running for a little bit after the boiler has cooled
jonsykkel[asciilifeform]: u cud use superhot steam to press air into tank then put that into wheels
crtdaydreams[asciilifeform]: there's a finite linear expansion coefficient and thermal conductivity
crtdaydreams[asciilifeform]: steam engines can only go so fast
crtdaydreams[asciilifeform]: s/finite/finite limit to
jonsykkel[asciilifeform]: maybe it dosnt work, im low steam-iq so i cant say
crtdaydreams[asciilifeform]: new meaning to "runnin outta steam"
crtdaydreams[asciilifeform]: tank psi exponentially decayed fug
crtdaydreams[asciilifeform] wonders if we'll ever see airships again
jonsykkel[asciilifeform]: in non-steams, ive ben experimenting with nat traversal
jonsykkel[asciilifeform]: this is my observations
jonsykkel[asciilifeform]: 2 machines behind same nat, 1 behind difrent nat, and 1 not behind any nat
jonsykkel[asciilifeform]: the natted machines are not able to communicate with each other using the same ext.port as D is using
jonsykkel[asciilifeform]: if C forwards port, A and B can reach it, but C sees diffrent src ports than what D is seeing
asciilifeform: jonsykkel: 2 boxes under 1 nat likely won't link up, addrcast won't help, as you illustrated. fortunately this doesn't often occur in nature
asciilifeform: ( however each of'em ought to still be able to peer with stations ~outside~ that nat )
jonsykkel[asciilifeform]: ryte but im talking about boxes from different nats trying to link
jonsykkel[asciilifeform]: seems all the nats im behind cares about where packets come from in adition to port
asciilifeform: jonsykkel: does e.g. 'skype' work from behind your nat? may be worth experiment
asciilifeform: ( not all nats are drillable )
asciilifeform: konsoomer nats typically are
jonsykkel[asciilifeform]: no idea but does skype even do p2p
jonsykkel[asciilifeform]: but it does drill, just have to initiate conection from behind nat
jonsykkel[asciilifeform]: cannot use external port that someone else is using (see fig. 2, nat assigns diffrent ports for difrent hosts outside the nat)
asciilifeform: afaik with 'symmetric' nats of the type apparently victimizing jonsykkel , the only drill that worx is to hammer random ports, from both directions, until match
jonsykkel[asciilifeform]: gota read up on that
jonsykkel[asciilifeform]: why would random ports work
asciilifeform: jonsykkel: be sure to post your findings here
jonsykkel[asciilifeform]: oh i see how random hammering owkrs
jonsykkel[asciilifeform]: will do some experiments
bitbot[asciilifeform]: Logged on 2022-09-06 11:49:29 phf[awt]: awt, so for example if there's a complete pest net of n stations, everyone's online, then 1 station drops out, now the network in aggregate starts transmitting n-1 address cast messages, because everyone is looking for that 1 offline station? 2 station, n-2, etc.
awt[asciilifeform]: $ticker btc usd
busybot[asciilifeform]: Current BTC price in USD: $18885.31
asciilifeform: awt: indeed you'd want some sorta randomization & backoff there, as suggested by folx in prev thrd
asciilifeform: in fact imho oughta have it across the board, wherever a timeout triggers sumthing 'public'
asciilifeform: awt: of course yer example presupposes that the net is a 'clique' (i.e. erryone-to-erryone peering)
asciilifeform: in actual practice (even on current pestnet) this aint so
asciilifeform suspects that even very naive algo, e.g. 'if there is a cold peer in wot -- then erry second 1/60 chance of shooting addrcast to all hot peers' -- would prevent 'chorusing'
asciilifeform: notion in spec was simply that there aint any point in emitting addrcast if yer actually in contact with yer entire wot at given time
asciilifeform: (and otherwise you want periodic beacon so that the missing peer, in the event he still has a working link with 1 or more on the net, can reconnect)
asciilifeform: (ditto ~processing~ addrcast; is rather expensive, so if all yer peers 'hot', no point in doing so)
phf[asciilifeform]: the icky part is that if your or your counterparty's pest is complete, then you don't have to process anything. but with a single node falling out on either side, you start getting packets or start having to process packets
phf[asciilifeform]: in practice that means that if one of your nodes falls out, suddenly you have to drink from the firehose of address packets
asciilifeform: phf: correct
asciilifeform: the choice afaik is to 'drink always' or 'drink when missing 1 or moar peer'
asciilifeform: asciilifeform didn't see a point in 'drink always'
asciilifeform: if bandwidth were somehow in infinite supply, could simply carry ~all~ traffic in addrcast-style broadcast msgs. but in practice this'll get outta hand rather quickly.
asciilifeform: (the other , not unimportant, point, is that such 'cheat' would eat away at the p2p topological redundancy of pest. stations oughta directly link up with peers whenever possible, and operator oughta know (via hearsayism) if fails)
phf[asciilifeform]: i'm more trying to understand this particular mechanism better, because it seems like it feels like it has a potential for a firehose
phf[asciilifeform]: you have n stations, one drops out, now n-1 stations are sending n-1 packets to each other to find the missing station, indefinitely. which (n-1)*2 decrypt operations on each machine
asciilifeform: phf: the 'firehose' is that addrcasts are broadcasts and thereby may be coming from l2+
phf[asciilifeform]: it being l2 kind of reduces the load, if you consider n to be a complete pest net, something being l2 implies subgraph size m, where m<n by definition, so inseead of it being n-1 packets, it's m-1
asciilifeform: well note that 'complete n' may vary by station depending on what bounce knob is set to
asciilifeform: but yes
phf[asciilifeform]: or rather x-missing nodes, n-total stations, m-size of subgraph, ≤x*(m-x) packets, where m=n in the worst case
asciilifeform at various times tried to come up with somehow moar efficient mechanism than addrcast, but utterly failed
asciilifeform: given the prior where 'only peers have any biz knowing yer addr/port', it's afaik the only possible one
phf[asciilifeform]: asciilifeform, why not make who you're looking for public?
asciilifeform: phf: cuz then you gotta make yer own addr/port public, neh
asciilifeform: the 'who' has to be able to answer.
phf[asciilifeform]: why would you? e.g. station phf looking for station asciilieform, and here's a crypto payload that only asciilifeform will know
asciilifeform: peers are identified by keys tho (shared strictly b/w the 2 peers)
asciilifeform: rather than handles
phf[asciilifeform]: immediately that'll only solve 2x decode, but then peers can have some kind of coordination thing going
asciilifeform: (which anyone can set to anyffin)
phf[asciilifeform]: anyone can also not-retransmit which is functionally equivalent to preventing decode based on target station's nick
asciilifeform: phf: elaborate plz re 'coordination thing'
phf[asciilifeform]: lets say it's ascii looking for phf, i know i'm phf, so i decode. attacker changes that to dog, so i don't decode. but then attacker can also simply not send, with same result.
asciilifeform: 'looking for phf' in this case means 'here's a phf-encoded addr/port for asciilifeform' tho
asciilifeform: issue with coordination schemes is that not erry peer has biz being able to ask for addr/port of arbitrary peer of $station
phf[asciilifeform]: yes, but addr/port is payload, coordination can be done at the level "who are we looking for"
phf[asciilifeform]: if i get 30 packets from asciilifeform that are asking for phf, i can choose to retransmit only a subset of those. that would be one form of coordination
asciilifeform: so notion is to place the handle in addrcast outside the ciphered payload?
phf[asciilifeform]: i might know where asciilifeform is in the above scenario, because he's in my l1, or i might just wait until he comes up to send him the last packet from a particular set
phf[asciilifeform]: asciilifeform, yah
phf[asciilifeform]: but i'm also thinking out loud, because maybe there needs to be more policy around it, if one were to do it
phf[asciilifeform]: e.g. does l2 need to know who you're looking for, that's possibly a leak
phf[asciilifeform]: lets come back to this, i want to think about it some more, before i raise it as an explicit RFC :>
asciilifeform when orig wrote section, defaulted to 'no one but the target has any biz knowing anyffin', but agree that subj needs thought
phf[asciilifeform]: the policy might be something like "if you're increasing bounce you should zero out looking-for-station-nick field"
phf[asciilifeform]: so your l1 knows who you're looking for, but not l2
phf[asciilifeform]: this will give you enought rope^Wknowledge to do better coordination, letting the subnet be pretty conservative about the address requests
asciilifeform: fwiw addrcast does already include ~originator~ handle outside of ciphered blob
asciilifeform: (but not the target's)
phf[asciilifeform]: "someone is looking for someone" "phf is lookibng for someone" vs "phf is looking for asciilifeform", that seems like the kind of knowledge that's can be practically applied at different bounce levels, and then scrubbed
asciilifeform: phf: what should l1 actually do with this info tho? intention of addrcast is to diffuse as widely as possible
asciilifeform: so suppose l1 get to avoid expensively decoding the thing if they don't need it. but l2+ is stuck doing so anyway
asciilifeform: (fwiw 'expensive' may be an exaggeration, decoding an addrcast simply costs what decoding 2 ordinary packets costs )
phf[asciilifeform]: asciilifeform, well, nothing's really "expensive" since we're running this on machine from the future, but so far this is the first mechanism which is a free-for-all
phf[asciilifeform]: ignore is the other one, but it comes with an explicit policy of "station can decide what to do"
phf[asciilifeform]: x lookingfor y is the entirety of the fact, from which it's possible to reason. in the simplest case "i know where y is" or "i'm also looking for y". in which case you can reduce the incoming stream to "i'm looking for y" and then you keep a backlog of last packets of everyone who's also looking for y.
phf[asciilifeform]: so for example in a complete graph of n nodes, where one of the nodes is disconnected, the "everyone's looking for missing node" is n messages every at some die off frequency
phf[asciilifeform]: where's in current approach it's at least n^2 (but not more, since that's going to get deduped on second bounce), and there's no way to coordinate the die off
asciilifeform: phf: fwiw note that per spec, stations aint required to decode addrcasts ('may decode, if spare cycles')
phf[asciilifeform]: re coordinating the die off, if you're already in stable state of looking for y, and there's an eager node that keeps sending "looking for y" messages, you can choose to just go "yeah yeah there's a bunch of people looking for him, settle down"
asciilifeform: phf: 1 aspect not already mentioned is that decoding addrcast doesn't actually cost same as regular packet, because only need to try keys of 'cold' peers
asciilifeform: (for the payload, that is)
asciilifeform: *as two regular packets
asciilifeform: i.e. if you've no cold peers, you stop immediately once see that it's addrcast; if have 1 cold, you try only that key; 2 -- the 2 respective keys; etc
asciilifeform not made this explicit in spec, but really oughta
phf[asciilifeform]: i wrote some SIMULATION CODE
phf[asciilifeform]: because i can't graph theory rightn ow
phf[asciilifeform]: so far i've discovered that a complete graph pest net of 10 with 1 missing generates 648 packets if everyone node were to send out the request once
phf[asciilifeform]: a 15 node graph with 3 missing generates 4752 packets
phf[asciilifeform]: a 20 node graph with 3 missing generates 13872…
phf[asciilifeform]: actually that's the simulation code in case anyone wants to check it for mistakes http://paste.deedbot.org/?id=nd1x
asciilifeform: phf: possibly also 'can't graph theory' but e.g. 10 where 1 missing oughta result in each of the 9 present stations shooting precisely 8 each (1 getaddr, given as 1 missing peer, going to the 8 remaining -- not counting self)
asciilifeform: similarly for the others ( 15 w/ 3 missing -- each of the present 12 shoots 11 getaddrs in total , etc )
asciilifeform: what am i missing
phf[asciilifeform]: propagation
phf[asciilifeform]: wait, let me fix some stuff in my code, possibly stupid
asciilifeform: phf: if the graph is fully connected, there'll be no propagation, as the thing'll get deduped
asciilifeform: (or rather, there'll be 1 bounce's worth)
phf[asciilifeform]: well, that's not what my code is doing :D
phf[asciilifeform]: ah i think i understand where i'm wrong
asciilifeform also aint thinking straight, as the getaddrs are unique per shooter and will in fact propagate to all peers, within bounce limit
asciilifeform: err, addrcasts
asciilifeform oughta come back to this thrd when awake
phf[asciilifeform]: right, i'm not wrong, because in my simulation there's no red layer. so a station generations 1 unique getaddr, that is then sent to all peers
phf[asciilifeform]: ok, so on 10 1 i get (:TOTAL-SENT 648 :TOTAL-RECEIVED 648 :SAMPLE-SENT 72 :SAMPLE-RECEIVED 72)
phf[asciilifeform]: current state of simulation code http://paste.deedbot.org/?id=TzYt
phf[asciilifeform]: the propagation logic is in “meat”, please to rea
shinohai[asciilifeform]: $ticker btc usd
busybot[asciilifeform]: Current BTC price in USD: $19338.76
jonsykkel[asciilifeform]: ur code relays packets to the guy it recved from
jonsykkel[asciilifeform]: dosnt make a big difrence in results tho
phf[asciilifeform]: ah poop that breaks the clean interface
jonsykkel[asciilifeform]: # of pakets sent can be reduced somwat by adding a propagation delay before relaying. only relay to ppl u didnt yet recv a copy from. such mechanism alredy exists in specful pestron in form of hearsay buffer. maybe can be generalized for all pakets that are to be flod routed
jonsykkel[asciilifeform]: but wil not change the results of this particular test, cuz all nodes are interconected
phf[asciilifeform]: jonsykkel, the argument from the relevant thread is that there's nothing to hook the concept of "copy" to
jonsykkel[asciilifeform]: i dont undersand
jonsykkel[asciilifeform]: hash of message is hook innit (or wat is huk here)
phf[asciilifeform]: jonsykkel, maybe i'm misunderstanding your proposal also, but each instance of packet in my code correspondes correspondence to what would be a unique hash in prod
phf[asciilifeform]: but there's also no other data on each packet except origin and hash
jonsykkel[asciilifeform]: presumably prod=addrcast
phf[asciilifeform]: i meant "hash in production", and yes each packet is an addrcast
jonsykkel[asciilifeform]: but it wont be unique since u are relaying them wihtout modification
phf[asciilifeform]: wait, i think i understand what you're saying "only relay to ppl u didnt yet recv a copy from."
phf[asciilifeform]: that mechanism is already in my code
phf[asciilifeform]: that's the (unless (cache ...) ...) check
jonsykkel[asciilifeform]: sec gota think
phf[asciilifeform]: "such mechanism alredy exists in specful pestron in form of hearsay buffer." right, that's correct, but as far as i understand address message is a broadcast, it's already supposed to share same machinery as a regular broadcast, which is what i'm emulating in simulation
jonsykkel[asciilifeform]: the cache doesnt do the same thing, if u recv a packet and immediately broadcast it, u might send the packet to a guy who has alredy sent the same packet to u but it hasnt arrived yet
jonsykkel[asciilifeform]: it doesnt affect ur simulation cuz theres no alive node that is >1 distance from any other alive node
jonsykkel[asciilifeform]: (and the packets are receved instantly)
jonsykkel[asciilifeform]: i supose could affect a real net even if 100%interconected, but less likely
phf[asciilifeform]: i think all this idea communicates is that there might be slightly more packets in air, then the simulation predicts (i'm not sure that's correct, i'm failing to visualize it, because end of day)
phf[asciilifeform]: the delay just adds jitter though, to probabily of that falling out, but doesn't necessarily predict it
phf[asciilifeform]: *prevent it
phf[asciilifeform]: jeez, let me retype that sentance
phf[asciilifeform]: the delay just adds jitter though to the probabily of the backets being in air despite the cache, but otherwise the delay doesn't prevent that situation from happening
phf[asciilifeform]: in related, i sort of assumed that the delay on hearsay was there so that you could get missing packets before you spool them to write only irc log, so that you preserve order, rather than for p2p purposes. i don't know if i'm correct though
jonsykkel[asciilifeform]: if i understand u corectly, the delay inded dosnt improve things for the first bounce, it probably even makes sense to skip it for first bnc, but it does make a difrence after that
phf[asciilifeform]: that's my intuition, i'll have to revisit this point though
jonsykkel[asciilifeform]: i think primary purposes of hearsay for messages is to give the imediate message a chance to arive , or in the case where it never arives, colect the list of peers that u received same mesage from so can be listed in irclog
jonsykkel[asciilifeform]: purposes of hearsay bufer delay, that is
jonsykkel[asciilifeform]: and the same info can be used incidentaly to reduce # of packets in air
phf[asciilifeform]: well, order of arrival matters
phf[asciilifeform]: or the other option is that my code is buggy. i think i'm going to stop working on it for now
signpost[asciilifeform]: http://paste.deedbot.org/?id=Kc1c << in other news, onlinecodes lisp prototype works now. working through sbcl's optimization warnings atm, refactoring, etc
signpost[asciilifeform]: planning on turning this prototype into a little command line tool that can send/receive a given file to an IP:PORT
jonsykkel[asciilifeform]: ur code propagates packets depth first
jonsykkel[asciilifeform]: but i think ends up with right numbers for math reasons
jonsykkel[asciilifeform]: re phfcode, not onlinecode, onlinecode - nice
crtdaydreams[asciilifeform]: http://logs.bitdash.io/pest/2022-09-07#1012570 << mspaint is literally goto wen want to explain something
bitbot[asciilifeform]: Logged on 2022-09-07 23:24:29 jonsykkel: at least thats wat proof by mspaint says http://zzz.st/up/PJvbnNoR/20220908_052234.png
jonsykkel[asciilifeform]: its a powerful beast to have in ur toolbox
← 2022-09-06 | 2022-09-08 → ↑
Random(pest) | Download hourly DB snapshot | Get Source Code