asciilifeform: (nuffin stops a peer from later adding the warez to his own share and then pass to ~his~ l1. is the logical way to propagate it.)
asciilifeform: fileshareism only makes sense b/w direct peers
crtdaydreams: and if peers forwarding packets it'd be possible to tell though
crtdaydreams: and pests __may__ send arbitrary rubbish to other peers anyway
asciilifeform: unpeered station can't send you anyffin, crtdaydreams
crtdaydreams: or would unpeered station send you file?
crtdaydreams: and would $peer fetch packet for you a bit like how the NAT Breakout works?
asciilifeform: ( if you aint a peer, i.e. can't talk to $station -- talk to yer own peers, see if they have whatcha want )
dulapbot: Logged on 2022-03-25 19:03:05 crtdaydreams: re: pest filesharing, how would filesharing permissions be executed? i.e. an file transfer eqiv of /query for each file to be transferred where peer can reject or accept (and also cancel transfer and discard packets) or will you be able to set a peer to "allow files / always accept"
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-03-25#1088912 << can't picture any need for anyffin moar granular than 'l1 peers can ask for index & files'
crtdaydreams: On the pest side of things, traffic analysis to see which peers are sending large volumes of data, would it be to the whole network as to obfuscate in the current way?
crtdaydreams: re: pest filesharing, how would filesharing permissions be executed? i.e. an file transfer eqiv of /query for each file to be transferred where peer can reject or accept (and also cancel transfer and discard packets) or will you be able to set a peer to "allow files / always accept"
mangol: so peers can transmit indices using the same chunk mechanism
mangol: and an "index" of files available on a peer can be another bag-of-bytes
mangol: the maymounkov-bigdown paper talks about (ID, position) tuples. apparently the ID can be either peer ID or file ID
asciilifeform: likewise, in principle several peers can send you chunks simult.
billymg: peer list*
billymg: i tried fiddling with the peershots knob (number of times it calls getaddr, since node list is incomplete in a single call) but the current "5" setting seems sufficient
billymg: nothing appears to be wrong with the crawler either, its logs continue to print out "found new peer!" almost hourly (which it finds when it pings and gets a response from a previously unknown peer returned to it by the getaddrs call to an existing node)
bitbot: Logged on 2022-03-11 15:18:45 whaack: curious as to whether any heathen node ever returns a trb node as a peer
asciilifeform: enemy has no biz learning how many peers you have, or which peer a packet verified as having been issued by, by timing packets in flight (enemy can be assumed to possess all transmitted packets and accurate timing for same)
crtdaydreams: I ask because 2.4s current wording is explicitly that IPs do not update even if the key is peered. Wherin the AT command issued in 2.5.2 explicity states it will be updated.
crtdaydreams: If someone currently peered sends a message from a new IP not currently registered in AT, will the AT update or will the message be discarded as martian before it can be processed?
mangol would like to have a "drip" protocol where you subscribe to peers in your WoT, and they propagate interesting content to you
dulapbot: Logged on 2022-03-20 21:10:39 signpost: upstack, should just do a DHT on it, ask peers for $hash
signpost: upstack, should just do a DHT on it, ask peers for $hash
crtdaydreams: Yo ho, all together, hoist the torrents high! All together, peers and seeders, never shall we buy!
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-03-16#1084626 << lolyes. asciilifeform would like to meet the fella who thinks he has over9000 folx worth exchanging keys & directly peering with
PeterL: I guess it helps to think of a pest network more like a single channel on traditional irc, where there are a handful of people talking, rather than e.g. freenode which could have thousands. It is easy enough to set up multiple pest stations, so you can have disjoing sets of peers
dulapbot: Logged on 2021-11-29 13:30:15 signpost: the correct social topology is human-sized, e.g. the number of reasonable pest peerings.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-03-16#1084540 << in principle you can have any # of stations you like on a pestnet if you set a reasonable bounce cutoff. however asciilifeform's official pov is that a group of mutual ~peers~ must be <= 'dunbar' number. the design reflects
thimbronion: shinohai: possibly for that particular peer in the at
whaack: right, but i somehow have a bunch of peers, not just the 2 i -connect'd to
whaack: curious as to whether any heathen node ever returns a trb node as a peer
whaack: my node reports this node as one of its peers, but not vice versa http://bitdash.io/nodes/91.42.83.47-8333
whaack: !w peers 91.42.83.47
billymg: whaack: in the case of those two you spot checked just now, the second indeed hasn't returned peers in a while (possibly ever, the crawler doesn't track this)
billymg: whaack: asciilifeform's watchglass intentionally does not include the relay byte in order to be compatible with trb. my crawler tries both with/without that byte in order to coax peers out of the node being probed
whaack: ^ looks like a bug though, there should probably be some 'unrecognized peer format' repsonse
whaack: maybe heathen nodes can't properly return peers as per watchglass
whaack: !w peers 24.6.168.141
whaack: !w peers 13.126.144.12
watchglass: 103.6.212.28:8333 : reported peers: 141.156.198.187 157.90.98.106 181.164.89.120 199.247.7.208
watchglass: 103.6.212.28:8333 : reported peers: 13.126.144.12 24.6.168.141 37.191.249.99 39.101.136.226 45.134.142.40 80.238.125.164 82.27.75.0 91.42.83.47 94.199.178.17:3201 138.201.28.24
whaack: !w peers 103.6.212.28
billymg: and i don't know enough to say whether it means "don't see" or "sees, but doesn't return in peers list"
whaack: or are you only looking at peers of trb nodes?
billymg: whaack: for some reason no other node scanned by the crawler has returned your new node as one of its peers
crawlerbot: 71.191.220.241 (Alive), h=726746, v=99999, United States - peers: 19 - last probed: 18m ago
crawlerbot: 205.134.172.28 (Alive), h=726746, v=99999, United States - peers: 19 - last probed: 18m ago
crawlerbot: 205.134.172.27 (Alive), h=726746, v=99999, United States - peers: 31 - last probed: 17m ago
crawlerbot: 94.176.238.102 (Busy? (No answer in 15 sec.)), h=726080, v=99999, Lithuania - peers: 35 - last probed: 17m ago
crawlerbot: 208.94.240.42 (Alive), h=726746, v=99999, United States - peers: 61 - last probed: 17m ago
crawlerbot: 205.134.172.26 (Alive), h=726729, v=99999, United States - peers: 65 - last probed: 17m ago
crawlerbot: 205.134.172.4 (Alive), h=726746, v=70001, United States - peers: 78 - last probed: 17m ago
crawlerbot: 75.106.222.93 (Could not connect!), h=726162, v=99999, United States - peers: 218 - last probed: 18m ago
watchglass: 103.6.212.28:8333 : reported peers: 108.28.120.178 162.202.32.106 173.249.0.235 178.84.195.232 212.227.253.11
watchglass: 103.6.212.28:8333 : reported peers: 51.38.41.205 65.21.135.149 71.82.69.245 73.214.155.8 74.64.37.97 76.184.249.78 83.99.247.25 84.28.57.90 85.214.185.51 94.209.184.8
whaack: !w peers 103.6.212.28
whaack: word, curious as to why 205.134.28 is not a peer
billymg: yeah dunno, your node is obviously connected to (and returning) plenty of peers. just that none of those peers has included your node in its list yet (at least not in what it returns to the crawler's getaddr requests)
billymg: !w peers 54.39.156.17
watchglass: 205.134.172.28:8333 : reported peers: 98.179.250.220 108.170.10.173 144.76.138.23 146.158.193.203 149.74.120.231 188.182.153.82 198.244.209.139 213.168.187.27
watchglass: 205.134.172.28:8333 : reported peers: 15.237.117.105 18.162.133.34 58.136.85.143 70.179.52.221 73.189.164.139 78.73.16.97 79.161.192.147 80.132.117.126 92.45.110.115 95.112.6.42
billymg: !w peers 205.134.172.28
billymg: i'm a bit curious why the crawler hasn't picked up your new node by now. all of those peers returned by watchglass are heathen nodes btw, i just looked them up in the db
watchglass: 103.6.212.28:8333 : reported peers: 85.173.165.66 88.214.194.20 89.245.66.230 91.121.133.13 98.224.28.183 103.88.92.99 178.18.251.68 178.63.103.8 178.198.72.156 178.201.224.213
watchglass: 103.6.212.28:8333 : reported peers: 24.20.153.86 37.49.81.219 39.99.232.25 46.105.76.211 47.153.182.115 54.249.229.7 54.255.73.190 68.181.4.12 71.199.59.71 82.221.106.178
billymg: !w peers 103.6.212.28
crawlerbot: 205.134.172.26 (Alive), h=726491, v=99999, United States - peers: 13 - last probed: 24m ago
crawlerbot: 205.134.172.28 (Alive), h=726490, v=99999, United States - peers: 28 - last probed: 25m ago
crawlerbot: 71.191.220.241 (Alive), h=726490, v=99999, United States - peers: 38 - last probed: 26m ago
crawlerbot: 208.94.240.42 (Alive), h=726491, v=99999, United States - peers: 51 - last probed: 25m ago
crawlerbot: 205.134.172.27 (Alive), h=726491, v=99999, United States - peers: 54 - last probed: 24m ago
crawlerbot: 205.134.172.4 (Alive), h=726491, v=70001, United States - peers: 59 - last probed: 25m ago
crawlerbot: 103.36.92.112 (Busy? (No answer in 15 sec.)), h=726489, v=99999, Singapore - peers: 85 - last probed: 25m ago
crawlerbot: 75.106.222.93 (Could not connect!), h=726162, v=99999, United States - peers: 218 - last probed: 26m ago
mats: asciilifeform: no lol, they haven’t fought a peer adversary in a long time
crawlerbot: 205.134.172.26 (Alive), h=726051, v=99999, United States - peers: 14 - last probed: 25m ago
crawlerbot: 205.134.172.28 (Alive), h=726051, v=99999, United States - peers: 29 - last probed: 26m ago
crawlerbot: 71.191.220.241 (Alive), h=726051, v=99999, United States - peers: 29 - last probed: 26m ago
crawlerbot: 205.134.172.4 (Alive), h=726051, v=70001, United States - peers: 46 - last probed: 25m ago
crawlerbot: 208.94.240.42 (Alive), h=726051, v=99999, United States - peers: 50 - last probed: 25m ago
crawlerbot: 205.134.172.27 (Alive), h=726051, v=99999, United States - peers: 61 - last probed: 25m ago
crawlerbot: 75.106.222.93 (Could not connect!), h=726044, v=99999, United States - peers: 218 - last probed: 26m ago
shinohai: Well that gets me different msg anyway, though %peer <handle> just spits back usage.
shinohai: jonsykkel: Got yer latest smalpest to press/build but evidently am thick and cannot seem to peer with anyone.
verisimilitude: Tor still provides protection against one's peers, similarly to how TLS works in, say, open Wi-Fi networks.
asciilifeform: loaded a page ? serve it up to yer peers. peer loaded a page? mirror it. and so on, recurse.
dulapbot: Logged on 2021-11-28 19:37:11 asciilifeform: signpost: somewhat apropos, thought of your lubytron in context of possible pheature: pestron takes a local dir and 'hosts'. peers (and optionally broader pestnet members, e.g. l2/l3) can visit e.g. http://localhost:8000/signpost and see his 'www'.
asciilifeform: billymg, bonechewer : not only, but breaks peer list in various ways; often enuff deliberately ignores trb nodes (which dun advertise support for various prb rubbish); throws headersfirstisms, bloomfilterisms, & other garbage which often enuff banned by flagship-build trb noades immed.
crawlerbot: 85.167.102.77:8333 - Alive, v=99999, h=408671 - last probed: 33m ago - peers returned: None
crawlerbot: 94.176.238.102:8333 - Alive, v=99999, h=725720 - last probed: 35m ago - peers returned: 11
crawlerbot: 205.134.172.26:8333 - Alive, v=99999, h=725782 - last probed: 35m ago - peers returned: 17
crawlerbot: 205.134.172.28:8333 - Alive, v=99999, h=725785 - last probed: 2m ago - peers returned: 17
crawlerbot: 82.79.58.192:8333 - Alive, v=99999, h=725782 - last probed: 35m ago - peers returned: 36
crawlerbot: 208.94.240.42:8333 - Alive, v=99999, h=725782 - last probed: 35m ago - peers returned: 44
crawlerbot: 103.36.92.112:8333 - Alive, v=99999, h=725782 - last probed: 35m ago - peers returned: 45
crawlerbot: 205.134.172.4:8333 - Alive, v=70001, h=725782 - last probed: 35m ago - peers returned: 48
crawlerbot: 205.134.172.27:8333 - Alive, v=99999, h=725782 - last probed: 35m ago - peers returned: 51
crawlerbot: 54.38.94.63:8333 - Alive, v=88888, h=725782 - last probed: 36m ago - peers returned: 52
crawlerbot: 71.191.220.241:8333 - Alive, v=99999, h=725785 - last probed: 2m ago - peers returned: 55
crawlerbot: 54.39.156.171:8333 - Alive, v=99999, h=725782 - last probed: 35m ago - peers returned: 78
crawlerbot: 75.106.222.93:8333 - Alive, v=99999, h=725785 - last probed: 2m ago - peers returned: 218
billymg: asciilifeform: could we be generous and count all trb-compat nodes?
asciilifeform: using billymg's excellent widget, and expanding circle to 'trb-compat', currently seeing 29 after subtracting the bot itself
signpost: I could still see reason to opportunistically blast bits at a peer as fast as one can in certain cases.
signpost: all peers being equal is another problem.
billymg: PeterL: the bot is still running, presumably because not peered with you. though if you also crashed asciilifeform's station then the bot has no peers and is effectively dead
thimbronion: asciilifeform: do you see there being some sort of "prod interval" per peer, where no additional prods will be sent to a specific peer within a certain period of time?
cgra: asciilifeform: re slow peers: 205.134.172.6 is slow for me, some 20-120kB/sec transfer rate. also inv's only one block at a time, when blocks 800kB+
asciilifeform: cgra: interestingly, occasionally drifts to random peer, but then nearly always reverts to the lan noad
asciilifeform: given as packets arrive in ~arbitrary order, and multiple peers may have $file to offer
asciilifeform: the peer has a chance to do sumthing else b/w requests
asciilifeform: 1 upside of this is that it doesn't bring the peer to its knees in so doing
asciilifeform: cgra: did try it w/ buncha randomly-picked peers, did not manage to get it stuck thus far
cgra: hmm, i remember as if some trb peer used to be a slow-link one. could try making cement-mode start off with such a peer, and see if makes operator sad or not
cgra: asciilifeform: prolly just gotta take time to see experimentally/think through staring at the code, whether significantly still could lock-in to a slomo-peer
jonsykkel: how does peers know wat blok to send then?
asciilifeform: the peculiar thing is that asciilifeform sees virtually no dupes from the lagging peers
asciilifeform does suspect that 'fastest' peer in fact delivers the asked block 1st, to the degree that the 'ask' in fact takes place in parallel
asciilifeform: cgra: interestingly, as-written it seems to gravitate to pulling blox from fastest (at given time) peer
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-17#1079658 << does 'level-by-level' here also mean 'branch-by-branch'? ie. can validate transactions one by one, as they stream from peer, if provided with enough related higher-level merkle hashes
asciilifeform: interestingly, seems to 'automagically' sync from 'fastest' atm peer
asciilifeform: the practical pill is likely to be to use -connect and pick a reliable peer when syncing w/ cement
asciilifeform: other problem is that any peer who is sending anyffin at all, ties up the whole noad.
asciilifeform: gnarly. 'slow' peer at a given time is usually simply 1 who is busy. 30sec later the same may be 'fastest' peer.
cgra keeps thinking of smth like "spread getdatas of the block range N to peers, follow peer response times and avoid overloading slow peers. buffer populates, verify block every time the lowest block in range N available, adjust buffer afterwards"
asciilifeform: tho because of the asinine pseudo-multithreadedness, only 1 peer can send/recv at a time
asciilifeform: cgra: trying to think of better algo, which doesn't result in n peers attempting to send in same $block
cgra: i mean, a peer won't advertise blocks (in response to getblocks) more at a time than a half of it's sendbuffer can hold
cgra: asciilifeform: normal getdata's are limited by the getblocks response size of the peer, or some other case in mind?
cgra: a fast node responds fast to your getdata chain and allows it going forward, while slow peers' sendbuffers build up at that pace
cgra: asciilifeform: re cement getdata algo, wanna point out that in theory there's also a risk of sendbuffer flooding some trb peer, especially with a lower-than-default sendbuffersize, if peer's upload is slow, and/or peer stuck at the same time doing smth else
dulapbot: Logged on 2022-02-17 09:52:45 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-17#1079578 << prolly won't surprise cgra that asciilifeform concluded that doing ~anything~ in parallel in trb is ~impossible w/out removing locks and potentially opening gates of hell. asciilifeform's draft 'usecement' is 100% serial, asks for 1 block at a time (and wastefully, 'getdata' to each connected peer, thinking atm how to reduce the bw guzzling)
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-17#1079578 << prolly won't surprise cgra that asciilifeform concluded that doing ~anything~ in parallel in trb is ~impossible w/out removing locks and potentially opening gates of hell. asciilifeform's draft 'usecement' is 100% serial, asks for 1 block at a time (and wastefully, 'getdata' to each connected peer, thinking atm how to reduce the bw guzzling)
dulapbot: (trilema) 2016-01-08 asciilifeform: 'Paul Graham is one of those plutocrats whose thirst to be recognized as a thoughtleader among his peers is obvious. For Paul Graham, Silicon Valley Ideology is the ideology America should run on, and ergo, being a puppet of Silicon Valley Ideology, Paul Graham thinks himself a political genius.'
asciilifeform: adlai: lemme know when you've a pest station, will send you a peering key
verisimilitude: I'm inclined to believe two hundred and fifty-six direct peers is sufficient for a Pest station.
asciilifeform: guess is based on 'astronomical' observations and observable political faces.
signpost: fwiw I grant the arbitrary nature of ratings, and have considered whether it'd be better as an ordered list of peers.
dulapbot: Logged on 2022-01-31 21:14:40 asciilifeform: iirc we discussed hypothetical pestronic wot, where yer peers can ask for yer ratings. and imho this wins, but strictly because eliminates the need for 'wot lives on 1 d00d's www', rather than because it makes any kinda sense to keep ratings seekrit
asciilifeform: whaack: likewise, pest (as currently pictured in spec) lets you invite peers to make db queries when it makes sense . i.e. 'getdata' cmd.
asciilifeform: iirc we discussed hypothetical pestronic wot, where yer peers can ask for yer ratings. and imho this wins, but strictly because eliminates the need for 'wot lives on 1 d00d's www', rather than because it makes any kinda sense to keep ratings seekrit
dulapbot: Logged on 2021-11-28 19:37:11 asciilifeform: signpost: somewhat apropos, thought of your lubytron in context of possible pheature: pestron takes a local dir and 'hosts'. peers (and optionally broader pestnet members, e.g. l2/l3) can visit e.g. http://localhost:8000/signpost and see his 'www'.
cgra: i believe the spam guard can cause a stuck sync, for example, when all the peers send their new best block inv's to us too early, and now register that block as 'known by us', and won't respond with hash of that block anymore to our later getblocks requests
cgra: (but had plenty of peers to play with)
asciilifeform: 'headers-1st'ism -- at least as seen in prb -- effectively forces you to uncritically accept lengthy chain from 1 peer at a time when syncing
dulapbot: Logged on 2022-01-28 13:43:36 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-28#1077027 << the problem here is that all known noades afaik send 'their latest' block unsolicited to all peers. 99%+ of the 'bastards' received by a syncing noad, are these
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-28#1077027 << the problem here is that all known noades afaik send 'their latest' block unsolicited to all peers. 99%+ of the 'bastards' received by a syncing noad, are these
asciilifeform: i.e. all chains recorded as they are, but what to do w/ a 'call me x' would depend on the station's pov re the offered handle. (if corresponds to l1 peer -- accept uncritically; if l2+ -- '1st come, 1st serve')
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-27#1076891 << the 1 aspect did not discuss, but worth mentioning, is that 'evil' l1 peers can of course mutate yer messages. but this imho is obv. and such a betrayal will not stay seekrit for long.
asciilifeform: i.e. doesn't req. rekeying w/ peers
asciilifeform: 'hey peerz, starting tuesday i'ma call meself 'bobert', plox to AKA bob bobert' pgpsigned, bob
PeterL: but what I am looking for is a way to renick without having to rebuild your whole peer network
PeterL: but say I want to peer with both bobs, how is that handled?
asciilifeform: PeterL: bob's l1 peers will see 'bob'; his l2+ will see two suffixed bobs as soon as they first collide and henceforth
PeterL: I'm thinking of the situation where two nets come together, both have a guy named "bob", can one pick a different name without having to re-peer with everybody?
PeterL: does that work if you want to peer with two people who both have the same handle though?
dulapbot: Logged on 2022-01-27 08:24:23 PeterL: asciilifeform: should there be a "rename" command to change a peer's name?
PeterL: asciilifeform: should there be a "rename" command to change a peer's name?
dulapbot: Logged on 2022-01-26 19:25:12 asciilifeform: if you blow away yer station's hdd, you naturally will need to pgpgram yer peers & rekey. will lose yer 'S's, but 1) this won't affect yer direct peerings, and you'll need to poke'em anyway 2) if you give a strong fuck re what l2+ sees yer handle as, you make a new one.
asciilifeform: if you blow away yer station's hdd, you naturally will need to pgpgram yer peers & rekey. will lose yer 'S's, but 1) this won't affect yer direct peerings, and you'll need to poke'em anyway 2) if you give a strong fuck re what l2+ sees yer handle as, you make a new one.
asciilifeform: ... all this w/ no long-term keys and no bignums. the only seekrits yer storing are your peer keys, 1 'S' for yer last broadcast, and 1 'S' per direct peer (for direct msgs.)
asciilifeform: dr.evil can set up his faux chain to seem 'oldest' to a new peer who relies 100% on his station for log catchup (via getdata). but if sees the genuine article (via sumbody else) 1st -- then no dice.
asciilifeform: ... for l1 (i.e. peers), can ignore lock/unlock, or possibly emit brief warning if peer's msg broke chain ('hey, didja format yer hdd?')
dulapbot: Logged on 2022-01-26 10:05:54 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-25#1076608 << msgs from direct peers, from receiver's pov, always authentic (and fork which contradicts'em -- bogus)
asciilifeform: theoretically still oughta work w/ current blatta and a nat-less peer
asciilifeform: w/ a 0xfa blatta, ~2~ pnojes in principle will peer if both already sitting on given pestnet
asciilifeform: shinohai: w/ current blatta, theoretically you'll be able to peer with folx who aint nat'd even from that pnoje
asciilifeform: ( as asciilifeform understands, currently you'll only have working peerings in own lan, on that thing )
asciilifeform: and relayed by same peer
dulapbot: Logged on 2022-01-26 10:05:54 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-25#1076608 << msgs from direct peers, from receiver's pov, always authentic (and fork which contradicts'em -- bogus)
jonsykkel: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-26#1076616 << green will at first store yellow as designated relayer for blue, but then if his direct peer blue talks then that is new genuine blue?
dulapbot: Logged on 2022-01-25 23:45:43 jonsykkel: wat then happens if blue(a) unpeers yellow and peers with red instead? and starts talking
dulapbot: Logged on 2022-01-25 23:45:38 jonsykkel: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-24#1075838 << ok, so if blue(b) speaks after green has stored yellow as designated blue relayer, it will show up as "blue-fake1" or watever in greens console? (even tho direct peer) while messages from blue(a) will show up as just "blue".
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-25#1076608 << msgs from direct peers, from receiver's pov, always authentic (and fork which contradicts'em -- bogus)
jonsykkel: wat then happens if blue(a) unpeers yellow and peers with red instead? and starts talking
jonsykkel: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-24#1075838 << ok, so if blue(b) speaks after green has stored yellow as designated blue relayer, it will show up as "blue-fake1" or watever in greens console? (even tho direct peer) while messages from blue(a) will show up as just "blue".
whaack: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-24#1075987 << word. vex, you've been following along enough to know that *someone* is going to have to peer for you to be able for you to talk in pestnet, right? atm i'm not going to risk losing my peers who may care about their snr
asciilifeform: PeterL: he aint your peer. he's sitting somewhere in your l2+.
PeterL: solution: don't let dr. evil be your only peer into the pestnet?
asciilifeform: ^ in which thread, asciilifeform came up w/ interning hearsays and counting the relaying peers, to allow ~some~ distinguishing mark.
dulapbot: Logged on 2022-01-24 11:41:33 PeterL: the other messy time is if A and B each have a different peer named C, how do things get handled if A and B peer?
asciilifeform thinks he's finally cleaned up all the gaffes in spec where referred to a l2+ station as a 'peer'
asciilifeform: atm the only things which are distinguishable are 1) msgs from l1 peers 2) arbitrary msgs w/ distinct speakers 3) ~relayers~ of msgs from l2+ peers 4) chains.
thimbronion: right - no way to block the l2 peer that didn't respond to the challenge - only the l1 peer that is the conduit
asciilifeform: w/ the current logic, doubt that A and B would stay peered for long, unless one of'em is willing to give his C the boot.
PeterL: the other messy time is if A and B each have a different peer named C, how do things get handled if A and B peer?
asciilifeform: given addr cast, there oughta be no such thing as a 'broken peering' while peer's station is standing
asciilifeform: orthogonally, asciilifeform still considering variant of this, but corrected -- the idea is, one ought not to process an in-wot hearsay if the speaker corresponds to a 'warm' peer. (you'll either defo get the immed. copy, eventually, or oughta prod him then getdata for it until you do)
asciilifeform: for instance, they would not have seen messages preceding their peering
PeterL: although, if you are seeing messages from L2 then they must be connected to one of your peers, presumably they would have the intervening messages?
asciilifeform: only peers
PeterL: would you only be able to "getdata" from peers, or can you ask for intervening messages from L2?
asciilifeform: forked until $peer returns and relays the original's; or until resolved by %resolve (which loox like you'd still need, ugh)
thimbronion: asciilifeform: let's say the peer via which first hearsay message from alice goes offline. Now we receive a message from alice that breaks the chain. Alice is permaforked?
dulapbot: Logged on 2022-01-23 23:55:51 asciilifeform: thimbronion, jonsykkel , et al : had possibly interesting idea for auto-resolution of forks. record the first l1 peer via whom you received a hearsay bearing that speaker. the chain of the fork received via that peer is to be considered genuine.
jonsykkel: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-23#1075817 << say u have following net: http://zzz.st/up/vFniopMQ/20220124_081722.png where square=pestron, color=handle, line=peering. noone has ever sent any msg, then blue(a) broadcasts a msg. yellow guy records msg and relays to red and green. red records msg. green rejects msg cuz in-wot hearsay (draft 4.3.1 step8). now blue(b) broadcasts
jonsykkel: reading draft now, understanding is that fork has occured if recv msg that overlaps with previously recorded chain in time dimension (or msg that predates genesis, presumably), and is strictly relevant for non peers
jonsykkel: im not clear on wat a fork is exactly, prev understanding was that fork = 2+ msgs exists with same selfchain value (chain has fork shape to it), and can occur for peers as well as non peers
asciilifeform: (and if one of yer peers ~isn't~ applying it, will be immediately clear ~who~)
asciilifeform: on contemplation, not clear that forks can even occur at your station if all of your peers apply this rule.
dulapbot: Logged on 2022-01-21 18:00:55 asciilifeform: thimbronion: a msg from a direct peer is prima facie authentic
dulapbot: Logged on 2022-01-23 23:55:51 asciilifeform: thimbronion, jonsykkel , et al : had possibly interesting idea for auto-resolution of forks. record the first l1 peer via whom you received a hearsay bearing that speaker. the chain of the fork received via that peer is to be considered genuine.
asciilifeform: thimbronion, jonsykkel , et al : had possibly interesting idea for auto-resolution of forks. record the first l1 peer via whom you received a hearsay bearing that speaker. the chain of the fork received via that peer is to be considered genuine.
dulapbot: Logged on 2022-01-21 20:47:44 asciilifeform: given addr cast, all peers oughta be able to connect directly at all times. (hence wai asciilifeform removed 'in-wot hearsay' section; tho fughot to specify that station simply should not route a hearsay purporting to come from an in-wot handle...)
asciilifeform: so forks aint a concern when yer actually peered. still annoying tho that afaik there is no 'final solution' to l2+ collision.
asciilifeform: given addr cast, all peers oughta be able to connect directly at all times. (hence wai asciilifeform removed 'in-wot hearsay' section; tho fughot to specify that station simply should not route a hearsay purporting to come from an in-wot handle...)
asciilifeform: thimbronion: btw in your reread note the new mechanism for explicitly showing your current chain tips to a peer.
thimbronion: i.e. if somehow the log was missing from all peers, getdata could fail
thimbronion: yeah I get it now. didn't realize before that forking was only for hearsy. thought perhaps it was for letting you know you missed a message from a peer.
asciilifeform: ( who has key -- is your peer , definitionally )
asciilifeform: thimbronion: a msg from a direct peer is prima facie authentic
asciilifeform: pestron oughta be able to store arbitrary mass of logs, but in such a way that only getdata (which only can come from a peer) can cause you to look on disk
dulapbot: Logged on 2022-01-09 15:05:39 billymg: you don't have to nuke the whole db, just go into sqlite and delete the key for the user you just unpeered
asciilifeform: points to 'If the "offending" message was a Broadcast Text, at least one GetData request is issued to each peer of the station.'
asciilifeform: the simplest way to make this happen is that folx specify x MB for how much pestnet log they're willing to store, and then chances are that 1 of yer peers will fill you up when asked.
asciilifeform: atm there aint much in the way of anyone having an 'l2' much 'l3', except by happenstance when various peerings didn't work
asciilifeform: the folx who l1 peers of asciilifeform , don't even need to see the forkolade (and won't rebroadcast it)
jonsykkel: 2 diffrent continuations from presumably 2 diff nonpeers
asciilifeform: otherwise, in cases where $original is not a direct peer of yours, you have no means to distinguish
dulapbot: Logged on 2022-01-19 22:06:08 asciilifeform: if $genuine is a peer, you can autoresolve the fork and simply throw out the rest
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-19#1075128 << to be concrete, can auto-resolve ~once you get an immediate msg from the peer~ and not otherwise
asciilifeform: if $genuine is a peer, you can autoresolve the fork and simply throw out the rest
jonsykkel: pestron is supposed to keep track of breaks/fork for nonpeers?