Results 501 ... 750 for 'peer'...

← | Results 501 ... 750 found in asciilifeform for 'peer' | →

asciilifeform: (the msgs from ~peers~ are already known to be authentic)

asciilifeform: jonsykkel: would have to gag, rather than unpeer, if not in l1

jonsykkel: if idjit inside net making u assrape io by spamming old msgs is unpeer time anyway

jonsykkel: imo need something like: 1. check if fits end of chain stored for peer P, if yes its a valid continuation, done 2. check if fits anywhere else in chain, if yes its a fork, done 3. now can be determined that have break in chain, put in order buffer

asciilifeform: all you need is 1 'escaped' peer.

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: PeterL: ( whereas any pest peer of thimbronion's can trivially generate a log 'proving' that ' thimbronion : let's go shoot kennedy tonight ' -- proving 0 )

asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-18#1074149 << recall, it's a symmetric key, either half of the peering can 'sign' with it

asciilifeform: jonsykkel: re 'remap' -- there's an arithmetical issue : atm peer can have >1 handle

jonsykkel: another idea could be to have peer specific knob for "display name" or smth that pestron uses when displaying msgs to operator console (could simply be bool like - always display messages from this peer using first handle in H)

PeterL: pest 0xfb section 3.2.4. Do all handles and peer names also have this limitation?

signpost: (this is important because with a fixed src-to-bin mapping, anyone can confirm for himself what the proper hash of a build should be. this allows him to trust his friendly peers to provide a cached build of an item, but verify independently)

jonsykkel: there're some details missing from algo that i can see: chek protocol version, invalid command, handling ignore pakets (specially with regard to rekeying), update peer packet stamp + key specific stamp + at entry

jonsykkel: my prog can be peered with a blatta that has this patch aplyd http://zzz.st/up/jT70pm4A/9983-tmp-disgusting-hack.vpatch http://zzz.st/up/pG8KEMVi/9983-tmp-disgusting-hack.vpatch.jonsykkel.sig

bitbot: (pest) 2022-01-13 asciilifeform: ( prolly obv imho, but nobody but the 2 peers who are using a key have any biz knowing even leading N bits of it )

asciilifeform: (i.e. if peer sends >x MB and it didn't consist of ACCEPTed blox -> ban)

dulapbot: Logged on 2021-12-01 12:38:40 asciilifeform: ... the other obvious pill is to keep per-peer memory odometer and permaban hogs, but not obvious how to cleanly implement.

cgra: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-11#1072528 << you're right, i forgot the collection had a handful of these as well. the only, strictly permanent leaking item is "mapAlreadyAskedFor", while "setInventoryKnown" leaks until peer disconnects, "mapAddresses" accumulates for ~two weeks until gc starts to follow, and some others have 2min-24h accumulation times.

shinohai: billymg: ack, was actually gonna get with you re: pest today, since I think yer one of the last few folx I haven't properly peered to.

billymg: shinohai: btw i'm checking my peering info that i last sent you for pest, looks like i might've sent my irc port rather than the udp

shinohai: btw asciilifeform if ya got time in a bit imma pgpgram you a new pest key and try to re-peer with ya.

dulapbot: Logged on 2022-01-09 13:47:17 mod6: Over in #pest, just ran `/quote unpeer whaak` and was about to enter his updated key and AT info. but now, blatta won't even restart. Just keep getting this message over and over on start up: http://paste.deedbot.org/?id=pgIv

dulapbot: Logged on 2022-01-07 19:38:27 billymg: thimbronion: found a bug in blatta. if you /unpeer with someone you have keyed it will crash inside get_keyed_peers() in lib/state.py because it iterates though the peer_ids in the keys table, but one will be missing from the list of peers

mod6: < billymg> mod6: just saw this, unpeering before unkeying currently triggers this bug << ahh, ok good to know for the future. some of this may also be, at least partially, related to the fact that I had whaack's nick in there misspelled.

billymg: you don't have to nuke the whole db, just go into sqlite and delete the key for the user you just unpeered

billymg: mod6: just saw this, unpeering before unkeying currently triggers this bug

mod6: Over in #pest, just ran `/quote unpeer whaak` and was about to enter his updated key and AT info. but now, blatta won't even restart. Just keep getting this message over and over on start up: http://paste.deedbot.org/?id=pgIv

billymg: probably oughta manually peer the bot with a few others

billymg: thimbronion: found a bug in blatta. if you /unpeer with someone you have keyed it will crash inside get_keyed_peers() in lib/state.py because it iterates though the peer_ids in the keys table, but one will be missing from the list of peers

signpost has thought about this as perhaps a message type to request a lubyistic transfer, which opens a side channel and blasts lubywads to peer

signpost: suppose you're taking messages from peers all the time without ending, yeah

asciilifeform: and imho loggers oughta peer with as many folx on pestnet as can be mustered, for max robustness

shinohai: jonsykkel: peered and added yer key do you need any of my info for yer at ?

jonsykkel: no idea if will peer, never tested outside nat. by default updates at entry with whatever src port found in incoming udps though

jonsykkel: (aka will look like cast originated from that peer, if only look at stuff inside Text field)

jonsykkel: asciilifeform: theres isnt wot entry for self, but the addr casts are rebroadcast, so you get your own casts returned back to you and decryption will succeed for peer that you originally created that cast for

dulapbot: Logged on 2021-12-30 15:48:14 jonsykkel: asciilifeform: are you meant to check that speaker field matches peer that you successfully decrypted addr cast from? (if not, how to distinguish bounce baks of own addr casts)

jonsykkel: asciilifeform: are you meant to check that speaker field matches peer that you successfully decrypted addr cast from? (if not, how to distinguish bounce baks of own addr casts)

shinohai: jonsykkel: iff'n ya want to peer using yer smol pest, feel free to gpgram me a key.

bitbot: (pest) 2021-12-01 billymg: i'm also wondering what to do in the logger with the hearsay annotations in the future. should log bots just peer with everyone in the net? should it just be stripped off, or maybe shown on hover? there's also the issue that [] are valid characters in IRC nicks

whaack: thimbronion: do i have to also peer you?

thimbronion: whaack: peered you.

shinohai: signpost: ack peering now

dulapbot: Logged on 2021-12-28 13:59:04 shinohai: send mekey in gpgram and ill peer with you

billymg: http://logs.nosuchlabs.com/log/asciilifeform/2021-12-28#1069936 << whaack, signpost: i'm in #pest as well. pgpgram your peer info and i'll add you

shinohai: send mekey in gpgram and ill peer with you

signpost: lmk if anyone else wants to peer up. not sure exactly how many stations are currently running.

signpost: thimbronion: may I peer with your station? same key as before?

signpost: maybe harmless? I'm not currently peered with anyone with this instance, I believe.

asciilifeform: whaack: lemme know when you have one built, i'll pgp you a peering key for my station

dulapbot: Logged on 2021-12-16 13:11:46 shinohai: http://logs.nosuchlabs.com/log/asciilifeform/2021-12-14#1069228 <<< to satiate curiosity I tried this, does indeed peer with blatta and crash instance shortly thereafter.

shinohai: http://logs.nosuchlabs.com/log/asciilifeform/2021-12-14#1069228 <<< to satiate curiosity I tried this, does indeed peer with blatta and crash instance shortly thereafter.

cgra: does asciilifeform (or anyone else) have a good reason why isn't the peer being banned for pushing bad blocks in the following cases:

dulapbot: Logged on 2021-12-06 09:34:56 asciilifeform: afaik currently all (incl. prb) noades throw their 'latest' block at all peers; so yer stuck processing (often enuff, if node not fully synced -- expensively rejecting) it

asciilifeform: afaik currently all (incl. prb) noades throw their 'latest' block at all peers; so yer stuck processing (often enuff, if node not fully synced -- expensively rejecting) it

cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-12-05#1068777 << what i was contemplating here, was not out-of-order reception of blocks, but the opposite: fix the last out-of-orderism the old 'getblocks, sometimes mixed with new top block adverts' mechanism has. and prevent getting stuck while catching up, because of some block ending up barred by every peers' [http://cgra.net/2021/12/trb-defect-exhibition-oom-and-other-spam#

jonsykkel: http://www.loper-os.org/?p=3969#selection-7395.0-7399.232 << does this mean most recent message from that peer, or from anyone?

dulapbot: Logged on 2021-12-03 06:37:20 jonsykkel: could send ignore packets to random ipv4 addrs. if pestron from another net happens to receive correctly sized martian packet, it will store addr in fake wot and start "communicating" at regular intervals. if have enough of these fake peers would be difficult for snoop to even tell who actual peers are

jonsykkel: could send ignore packets to random ipv4 addrs. if pestron from another net happens to receive correctly sized martian packet, it will store addr in fake wot and start "communicating" at regular intervals. if have enough of these fake peers would be difficult for snoop to even tell who actual peers are

jonsykkel: right, but does the peer get marked as unforked?

asciilifeform: (to be more exact, via a common path through their net, technically not even need to have common direct peer)

asciilifeform: a pair of peers that is able to make contact will always have a valid AT for one another (and after 'Address Cast' is in place, it'll suffice for them to be in contact with their net, then can always establish AT for one another via a common peer)

asciilifeform: thimbronion: per '2.4. The AT': '... AT (Address Table), which holds the last known address of each WOT peer.'

asciilifeform: the spec calls for only 1 per peer at a given time (dunno if i made this properly clear)

asciilifeform: thimbronion: unrelatedly, prolly oughta gc unused AT entries when the peer in question has a live one

asciilifeform: ... the other obvious pill is to keep per-peer memory odometer and permaban hogs, but not obvious how to cleanly implement.

asciilifeform: peer addresses sadly can't be 100% whitelisted (trb net aint own planet, sadly, needs to link w/ miners at the very least) but what one could do is to only share with peers ones which a) on whitelist of known trb nodes b) not in (a) but have supplied a valid block.

dulapbot: Logged on 2021-11-30 15:36:51 signpost: asciilifeform: this is how I'm thinking about it, that "www" is a dead, inert thing I've synced to my local disk from peers, with basically unspecified hospitality provided to the traditional net if desired.

signpost: asciilifeform: this is how I'm thinking about it, that "www" is a dead, inert thing I've synced to my local disk from peers, with basically unspecified hospitality provided to the traditional net if desired.

asciilifeform: thinking further re this -- imho the Right Thing would be for all reachable peers to maintain synced local copies of such 'www'. (and optionally station operator can route the port on which the station emulates http server to world)

signpost: the correct social topology is human-sized, e.g. the number of reasonable pest peerings.

asciilifeform: thimbronion: with your current logic, a msg which is coming via multiple peers will display one effectively at random.

thimbronion: asciilifeform: currently indicates which peer (the first). I can change it to embargo simple hearsay messages as well.

asciilifeform: ( per spec tho oughta indicate via which peer(s) came the hearsay; 1 of the uses of the embargo buffer is to give an extended 'now' moment (given as in reality msgs cannot actually arrive simultaneously, on x86 not even if via multiple nics, given there's 1 bus..) to make this possible.

dulapbot: Logged on 2021-11-28 23:03:12 asciilifeform: the 'who gave copies' thing is there to deal with the case where e.g. thimbronion peers asciilifeform and bitbot , signpost peers asciilifeform and bitbot , asciilifeform not peered bitbot but gets a hearsay from same via thimbronion and signpost

asciilifeform: per spec oughta trigger on all hearsays if multiple peers relayed

asciilifeform: the 'who gave copies' thing is there to deal with the case where e.g. thimbronion peers asciilifeform and bitbot , signpost peers asciilifeform and bitbot , asciilifeform not peered bitbot but gets a hearsay from same via thimbronion and signpost

asciilifeform: thimbronion et al : asciilifeform while rereading pest spec found a logical bug : in 4.2.3.3, station is asked to count distinct peers who sent duplicates of a hearsay msg ; but to simply count'em is flawed, as likely ~all~ the station's peers will send'em due to bounceback.

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: (because the bloated peer state i injected, wasn't cleaned up, but kept for extra 15mins)

asciilifeform: atuttle: if yer interested in pest, i rec to join the wot -- then possibly can peer with someone on the experimental pestnet.

asciilifeform: further re the O(peers * packets) thing -- factually it's O(packets), exactly like anyffin whatsoever to do with packets (yer looking at each one, or whatever % cpu capacity allows) given as in practice you'll want at least as many cpu cores as you have peers, to achieve line-rate (Gb/s or whatever yours is) liquishit-rejection

atuttle: on the other hand, if n_peers*m_packets scalability obstacle *was* deliberate, that's okay, but acknowledging the deliberate obstacle would be helpful to people trying to understand the spec. Also there might be better ways (I cannot think of any right now, but might in the future) to achieve the same goal.

atuttle: anyways, if the n_peers*m_packets scalability obstacle was *not* deliberate, there are a few ways to fix it.

jonsykkel: unless plan on having 10k peers

atuttle: jonsykkel, yes, O(N*M) for N peers and M packets...

jonsykkel: it only has to do verify hmac for each peer for each incoming packet

jonsykkel: pestron B sends "hi" to his peer pestron C

jonsykkel: so you just drop packets if peer starts spamming, then drop peer when notice

dulapbot: Logged on 2021-11-24 17:59:52 jonsykkel: purpose of pausing is simply to cut link to peer? should this be implemented as skiping over his keys when verifying incoming udp paket?

asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-24#1067467 << only if there was buncha items direct-messaged or hearsayed only via ~that~ peer

dulapbot: Logged on 2021-11-24 17:06:08 jonsykkel: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-24#1067407 << right, this is what i thouht at first, but then if pause peer you will still probably receive hearsay from said peer if someone else in net relays his messages

jonsykkel: purpose of pausing is simply to cut link to peer? should this be implemented as skiping over his keys when verifying incoming udp paket?

jonsykkel: (unless aforementioned hearsay messages get added to peers chain?)

dulapbot: Logged on 2021-11-24 09:24:41 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-24#1067396 << lolno. reread that section : 'Temporarily disable all communication with the peer identified by HANDLE, without discarding any data.'

jonsykkel: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-24#1067407 << right, this is what i thouht at first, but then if pause peer you will still probably receive hearsay from said peer if someone else in net relays his messages

dulapbot: Logged on 2021-11-24 04:07:45 jonsykkel: packets from paused peers should be processed normally except messages not sent to operator?

asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-24#1067396 << lolno. reread that section : 'Temporarily disable all communication with the peer identified by HANDLE, without discarding any data.'

jonsykkel: packets from paused peers should be processed normally except messages not sent to operator?

gregory5: my own implementation of Pest 0xFD is almost ready. can someone add me to their peers?

billymg: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-21#1067097 << i was thinking the same re: the intro text, "Pest is a peer-to-peer network protocol intended for IRC-style chat."

asciilifeform: likewise, you might be sending from $ip1 nao, but $ip2 on entirely diff. isp 10sec from nao, and the peers don't give a damn. they'll answer to the most recent one which spoke.

asciilifeform: nobody but a peer has any biz at all knowing that there's a box at $ip.

jonsykkel: if operator sets to +15min and his peer sets to -15min ur fukd tho

jonsykkel: this is what i mean, if your clock is +16min relative to peers, all msgs will be rejected so you have bigger problems than dedup margin

asciilifeform: jonsykkel: keep in mind that the only type of spamola that costs palpable cpu is replays of ~valid~ packets (i.e. from a peer) -- and, of course, packets actually generated by a peer (the solution to this is arguably a 'hog' alarm + unpeer)

asciilifeform: anuther observation -- a station possib. should have some awareness of whether an originated message actually went out before updating own net/self hash. (we dun have 'acks', but a broadcast msg is expected to come back verbatim, given as rebroadcasts are to all peers incl. originator)

dulapbot: Logged on 2021-11-17 12:04:00 BingoBoingo: And generally the young adults today seem less retarded than self and peers at their age, but maybe I'm just picky about the ones I entertain?

dulapbot: Logged on 2021-11-14 20:36:40 asciilifeform: ( note that notion there is to send a copy of the black to ~erry peer~, rather than as a net broadcast )

dulapbot: Logged on 2021-11-14 14:49:16 asciilifeform: punkman: imho this oughta be strictly for 'hey $peer, i'm over-here'

asciilifeform: orthogonally to all of this, asciilifeform was asked (in meatspace) 'can i make an equivalent of old-style moderated group w/ pest?' -- answr is 'you can, if you can find folx who want to inhabit one, simply pick a moderator and peer with him in star topology'

asciilifeform: (and, recursively, your peers will too)

PeterL: thimbronion: http://paste.deedbot.org/?id=Cevk << crashes if you try to send a dm to a handle that you do not have as a peer

BingoBoingo: And generally the young adults today seem less retarded than self and peers at their age, but maybe I'm just picky about the ones I entertain?

asciilifeform: that way if there's an immediate (i.e. direct from peer) copy of a given msg on the way to your station, that one is treated as canonical (and rebroadcasts will have bounce==1)

signpost: BingoBoingo: sure, but from the 60s/70s nostalgia you get the psychedelic revival which had significant impact on the views/behavior of me and my peers.

thimbronion: A suggestion for a possible debugging technique for those who are not able to peer: create a separate net with only yourselves. much less noisy.

dulapbot: Logged on 2021-08-12 08:54:46 cgra: asciilifeform: haven't tested this, but i suspect that an obey_sendbuffersize node (A), when catching up blocks, may end up banning peer (B) with >2x the sendbuffersize, if B advertises blocks with full capacity, in response to A's "getblocks"

shinohai: thimbronion: unpeered bot from myself then manually added key, etc using weechat. Restarted bot. It still spits out msg: 2021-11-15 11:50:55.736051 Discarding message to unknown handle or handle with no key

dulapbot: Logged on 2021-11-14 20:33:05 asciilifeform: ... a copy of erry outgoing ~black~ packet oughta be sent to some random handful of at addrs ~other~ than the intended peer's.

asciilifeform: ... an alt-variant of this would be to queue a random-soup packet to ea. peer (along with the actual black for the actual addressee) and send'em in random order, when directmsging.

asciilifeform: for e.g. warez this'd be obscenely bw-hungry, but i can't think of a reason why a chat directmsg shouldn't travel (as copies of 'black') to erry peer in at (incl. obv. the intended addressee; none of the others will react to it)

asciilifeform: ( note that notion there is to send a copy of the black to ~erry peer~, rather than as a net broadcast )

asciilifeform: ... a copy of erry outgoing ~black~ packet oughta be sent to some random handful of at addrs ~other~ than the intended peer's.

asciilifeform: still imho safe mechanism for requesting peer addrs via broadcast would be a win.

asciilifeform: with a 'gimme my port' cmd, it'd suffice for 1 of them to simply be able to reach any other unnatted peer.

asciilifeform: (per current spec, 1 peer in any pair gotta be un-natted)

dulapbot: Logged on 2021-11-11 11:22:54 asciilifeform: btw for troo 'hole punching , if we were to a msg type where yer peer tells you your ephemeral port, then a pair of peers where ~both~ are natted could link up if either of'em has a peer who isn't and is reachable.

asciilifeform: i.e. if you can reach ~1~ peer, oughta be able to securely transmit a 'here i am' to each $peer in yer wot.

asciilifeform: fwiw theoretically even nao, if yer station wasn't behind a nat, and none of its peers 'drifted', can already copy config w/out fiddling

thimbronion: asciilifeform: such that all one needs is a shared key and one peer?

asciilifeform: thimbronion: the other notion behind 0xfe msg is to reduce the amt of avoidable gruntwork in setting up peerings to begin with.

asciilifeform: most elementarily : when either it or the peer have drifted to a new ip and/or ephemeral nat port

thimbronion: asciilifeform: yes. For example, is this for the case when you've already peered with someone, but one party changes IP?

asciilifeform: thimbronion: re 'when would a station know a peer key but not a valid AT entry' ?

dulapbot: Logged on 2021-11-14 15:20:39 punkman67: alternative implementation: "have_you_seen_handle" message, you send to all your peers, they reply with "ip:port:last_seen_timestamp" for requested handle

punkman67: alternative implementation: "have_you_seen_handle" message, you send to all your peers, they reply with "ip:port:last_seen_timestamp" for requested handle

dulapbot: Logged on 2021-11-14 14:34:39 asciilifeform: would be imho reasonable to rate-limit these (i.e. accept, say, 1 per peer per 5min)

asciilifeform: hence why not save the fingerwork and let it do so, rather than 'hey $peer, plz add 1.2.3.4:5567 for my AT, kthx' via humantext

asciilifeform: imho these oughta be sent strictly when necessary -- otherwise you leak info to entire pestnet which folx dun have necessarily any biz knowing (concretely -- the # of peers you have)

asciilifeform: i.e. if you ~know~ where (addrwise) a peer is , you oughta be speaking directly.

punkman: there is no way for peers to filter it anyway, only recipient can discard non "ip:port" message, after decrypting it anyway

asciilifeform: punkman: even when individual peers rate-limit, you can still get a pretty thick flood if yer pestnet is populous

asciilifeform: punkman: imho this oughta be strictly for 'hey $peer, i'm over-here'

asciilifeform: you'll still need at least ~one~ peer's addr to get on a pest net, but from there on, any peer with whom you have a valid key will be contactable henceforth without fiddling, for so long as he is reachable via a broadcast on that net.

asciilifeform: if the addressee receives, he makes contact, and this becomes his current AT entry for the sending peer. otherwise nuffin happens.

asciilifeform: this'd obviate the need to exchange AT entries with ~every~ peer, while exposing nuffin to folx whose biz it aint.

asciilifeform: would be imho reasonable to rate-limit these (i.e. accept, say, 1 per peer per 5min)

asciilifeform: 0xFE and 0xFD: broadcast (a la 0x00, i.e. to all member of a pestnet whose $maxbounce permits'em to hear), bearing not text but a ciphrogram, keyed to a peer for whom the sender wishes to find ip:port.

asciilifeform: phunphakt: if somehow, under some odd circumstances, two pest peers do not know one another's ips, but know expected port, they can find each other in...

asciilifeform ( seeing plenty of 'ignores' from both peers, iguess these don't update the timestamp ? )

asciilifeform: 'at' shows 'None' for both of my peers tho, for last-incoming time

asciilifeform: also i readded peers , and issued a helloworld, but seeing nuffin in pestlog

asciilifeform: and of course one can still send a peer new key 'by hand' / pgpgram.

asciilifeform: ideally all peers rekey at least erry 24h

asciilifeform: asciilifeform's proposed rekey algo, for reference : peer A takes 512bit sA from trng, sends sha512(sA) ('key offer') to peer B. the latter does same; sB; sends sha512(sB) to A. then A sends sA to B, who verifies that it hashes to the earlier hash; if yes, sends his 'key slice' similarly to A. new mutual key is sA ^ sB ^ the key they had the conversaion with.

asciilifeform: but this is imho a luxury. per asciilifeform's orig. spec 'at least 1 peer in a pair must have a routable public addr/port known to the other'

asciilifeform: btw for troo 'hole punching , if we were to a msg type where yer peer tells you your ephemeral port, then a pair of peers where ~both~ are natted could link up if either of'em has a peer who isn't and is reachable.

asciilifeform: 55565 is defo an ephemeral port. these'll stay open if the station sprays at least 1 packet/s to ea. peer. thimbronion's current draft doesn't have this yet tho.

asciilifeform: thimbronion: this of course for display purpose only. (if station only has 1 at entry for a peer, and you're transmitting dm to him (or broadcast) , oughta use that entry, even if nothing yet received from it. otherwise you have '2 trains waiting'.)

dulapbot: Logged on 2021-11-09 11:50:20 asciilifeform: a good short-term kludge imho would be to consider all peers in wot 'online' so that irc client will at least give tab-completion, the current behaviour is quite frustrating

asciilifeform: a good short-term kludge imho would be to consider all peers in wot 'online' so that irc client will at least give tab-completion, the current behaviour is quite frustrating

asciilifeform: shinohai: prolly the cleanest way to do it is to consider all peers from whom received a packet in past 10min 'online', others -- not

shinohai: I'm really liking pest/blatta .... and have plenty of time to dedicate to debugging - so any tuned in that want to peer or test, feel free to DM me gpgram with keyz

asciilifeform: thimbronion: imho best way to implement rubbish is a 'synchronous mode', where sends e.g. n msg/s to ea. peer, and if there's a payload, it 'catches the bus'

asciilifeform: incidentally, thimbronion et al, i had the thought that if 'rubbish' packet is sent at last 1/s to ea. peer, the 'ephemeral' port will remain open.

asciilifeform recalls how mp rejected multiple offers to set up ordinary irc net, because 'must' peer with fleanode/other classic net despite none of the latter wanting anyffin to do with such thing, 'how will the camwhores log in' etc

asciilifeform: it would mean that port gotta be set manually (via 'AT') before a peering can work

asciilifeform: a nat with an inbound rule oughta be sufficient (for both sides of a peering in fact)

thimbronion: asciilifeform: I thikn that's it. Currently blatta updates the at to the last address and port a message from a peer was received from.

asciilifeform: ( if a permanent port is known for a peer, that's the 1 that oughta be used for contact )

asciilifeform: ( unless shinohai peered asciilifeform while i was speaking this )

asciilifeform: ought to show time of last ~received~ valid packet from peer, per sect. 2.5.1

shinohai: I don't have asciilifeform peered yet, did not have info for at

asciilifeform: (i.e. i peered shinohai but nfi whether successful contact)

asciilifeform saw billymg, but not peered him yet, nick wasn't marked 'billymg(awt)' even tho only had the latter

asciilifeform: i have thimbronion peered but see only self in #pest

billymg: thimbronion: i did the peer, at, key commands for your station

billymg: i've got blatta running and can connect to it from my IRC client, can any of those connected share their peer info?

dulapbot: Logged on 2021-11-07 18:13:19 signpost: although it was born breaking teeth on the fact that IRC servers cannot be deployed redundantly (i.e. with cycles in the peerings)

asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-07#1063701 << 1 peer in a pair does need an ext. routable ipv4, in all fairness. but dun have to be in a dc.

signpost: although it was born breaking teeth on the fact that IRC servers cannot be deployed redundantly (i.e. with cycles in the peerings)

signpost: all of us have computers on the internet, which is already a peer-to-peer network, so why should there be?

PeterL: I feel like connect is the right word, you connect to a pest network by peering with somebody in it

shinohai: Also anyone tuned in that is testing this welcome to ping me if they want to peer. Will send deets via gpgram.

shinohai: Imma try thimbronion's new thing today .... but the genesis was nice thing thus far, I even got bot to peer.

punkman: thimbronion: "peer"

shinohai: Still poking blatta with a stick thimbronion and found the def for `peer_handler` would barf if peer already existed in db, added an except an worx fine now.

thimbronion: But yes probably best to peer up using the commands.

signpost: thimbronion: is the config.py not used now, and I should instead peer up with you via commands?

thimbronion: signpost: you'll need to run the /peer, /at, and /key commands to connect.

shinohai: So I *did* figure out that db trashing only causes barf if you dont run both UNPEER and UNKEY right after one another. So far, seems fine.

shinohai: I crashed my server - it seems that the db gets trashed if you UNPEER someone

asciilifeform: shinohai: per spec, pair of peers shares a key

thimbronion: discovering some bugs with the commands where they crash/error when there are no peers/addresses

shinohai: nah I open the port I'm using when was experimenting with former implementation. That one acted much like regular irc server but could /PRIVMSG a peer

thimbronion: And messages aren't coming through between peers?

shinohai: when running /WOT or /AT it *does* show peer's name

thimbronion: shinohai: did you add a key and address for the peer?

shinohai: thimbronion: Any tips on how to interact between peers using weechat? Am able to start blatta server, add peers to AT but ... nothing else.

dulapbot: Logged on 2021-10-24 20:15:06 thimbronion: Just noting here that there is a mistake in Alcuin 9994 and all previous versions regarding keys. Whereas two peers should use the same key to encrypt/sign and decrypt/verify, instead alcuin has a concept of remote and local key pairs associated with each peer. So peer a encrypts with Ka, peer b with Kb and the opposite for decryption.

thimbronion: Just noting here that there is a mistake in Alcuin 9994 and all previous versions regarding keys. Whereas two peers should use the same key to encrypt/sign and decrypt/verify, instead alcuin has a concept of remote and local key pairs associated with each peer. So peer a encrypts with Ka, peer b with Kb and the opposite for decryption.

dulapbot: Logged on 2021-10-21 11:22:35 cgra: thimbronion: i'm looking at shinohai's publication of alcuin. Server.handle_udp_data()'s 'unknown peer' debug print wouldn't work, because string format args not as a tuple

cgra: thimbronion: i'm looking at shinohai's publication of alcuin. Server.handle_udp_data()'s 'unknown peer' debug print wouldn't work, because string format args not as a tuple

asciilifeform: verisimilitude: why do you want to store (outside of your personal irc console logs) info that doesn't need to be relayed to any pest peers ?

dulapbot: Logged on 2021-10-04 01:35:59 punkman: http://logs.nosuchlabs.com/log/asciilifeform/2021-10-03#1060620 << if peer gets request to fill 5k message gap, could decide to only send 10 or 50, and requester will eventually send more getdata requests

punkman: http://logs.nosuchlabs.com/log/asciilifeform/2021-10-03#1060620 << if peer gets request to fill 5k message gap, could decide to only send 10 or 50, and requester will eventually send more getdata requests

asciilifeform: signpost: imho lubyism is a++ for pest-style known-peers net, as the need to separately authenticate the frags falls away (i.e. can generally trust that a direct peer is not sending garbage frag)

signpost: one lovely consequence of the encoding stream is that, for items multiple peers have, multiple peers can start spraying blocks at you, and you'll reap the benefit of the parallelism without them coordinating with each other on what to send you.

punkman: I'm thinking it might also be nice to have a "ranged" getdata, I sent getdata request with from_hash (last hash we have before gap) to last_hash (hash we just got that informed us about the gap), and peer blasts all the messages we need to fill gap, without having to send a getdata for each

punkman: I'm not handling that scenario either, my AT is IP->Peer map, guess I should convert it to IP:Port->Peer too

asciilifeform: it depends heavily on the bw of your station, that of your peers (folx on gsm 'pay-per-byte' may wish you wouldn't send chaff and certainly won't wish to send any themselves, i expect) etc

punkman: thimbronion: does your pest peer eat packets yet?

punkman: was planning to use separate ircd, but this seems handy, can make it think it has a connected user for each WoT peer

asciilifeform: upstack, must remind folx that whether $box keeps up 'at line rate' will depend also on # of ~keys~ in the wot (and not strictly # of peers, recall that at various times there may be >1 key per)

asciilifeform: in fact, with these, you can compute e.g. S = SHA384(K + Message) and cache the state for SHA384(K) per peer, and farm the remainder out to worker threads

PeterL: also, if your n peers each send you the message, and you drop a %, you will still get most messages. direct messages will be affected though

asciilifeform: peer will do the getdata cycle, wait his turn, etc

asciilifeform: PeterL: the cure for ddos as offered in pest is not simply 'can process at nic line rate' but also the ease of switching to fallback line in flight (all you gotta do is to start sending from it, and peers will start replying there as soon as each receives even 1 valid packet from said new line)

dulapbot: Logged on 2021-09-10 15:50:45 asciilifeform: the important thing to note is that a net of say 100 people will contain quite a bit moar (largely dupe) traffic than you'd ever want in your console -- but still useful for multipath propagation/resilience. so any per-peer rate limit must affect only console imho.

asciilifeform: handles are simply a thing a peer can have N of

asciilifeform: punkman: of course he does. chains are stored per-peer

punkman: perhaps better to keep counter with set of peers instead of integer per message

asciilifeform: anyways dupes counted, but a given peer only counts as '1' for this purpose no matter how many times he sent the dupe (if he is broken somehow. an in-spec peer will never send same msg twice under any circumstances.)

PeterL: I thought you were describing a malicious peer that was rebroadcasting messages with altered timestamps to make it look like other people were trying to flood the network

PeterL: if a peer sends the same message twice in two different red packets, the second one gets dropped when you see you already have that message

PeterL: right, and we expect roughly our entire peerset to each send us a red packet with the same message

PeterL: so in your exacmple who is the bad peer?

PeterL: right, that is how it is supposed to work, and people de-dupe as they receive the same packet from multiple peers

punkman: and everyone else thinks it's someone in subset of peers

punkman: only subset of peers knows that it's B

punkman: no because A sends m1_bounce=0 to B. B starts sending m1_bounce=1 at line rate to a subset of peers, the subset of peers starts rebroadcasting m1_bounce=2 to everyone else

PeterL: although, this brings up a question, iiuc the peers displayed are only the ones with 1 bounce? if you have your bounce setting high, what would get displayed for a message from your L3, the first peer you see a message from? or anybody with bounces = 2?

PeterL: and 2) the messages will all appear as hearsay of the form $any_user($bad_peer):message , which will make it pretty obvious who is misbehaving

PeterL: punkman: two things: 1) when you see the flood, you can drop the max_bounces to 1, then either it stops or $Bad_Peer is the only one sending and it is obvious

punkman: first part for Station not to misbehave, second part to know which peers are misbehaving and warn operator

punkman: so I guess my Station needs to keep track of what message it has rebroadcast to which peer, and also what rebroadcast message Station has received from which peer

punkman: as receiver of these rebroadcasted messages, you can't tell who the evil peer is

punkman: looking at my naive implementation, evil peer can rebroadcast all messages timestamped within 15min, always setting bounces=1, causing other peers to also keep rebroadcasting same messages,

asciilifeform: and likewise it is necessary to permit multiple handles for one peer key, for this reason.

asciilifeform: exactly as was always possible on irc. simply here requires special handling, otherwise everyone is perma-stuck with one handle, to individually ask every peer at the same time to change (and during said switchover, for messages to be lost) is impractical

asciilifeform: punkman: both of these is so that it is possible for a peer to change handles (from the one under which you initially added him to your wot)

punkman: does this mean having multiple handles for single peer? if yes, why?

punkman: "Let H be the set of all handles found in the station's WOT for the peer who was found to have sent the packet; e.g. {shalmaneser, ShalmaneserTheGreat}."

← | →