#pest | 2022-07-11

crtdaydreams: I just released a patch that fixes %unpeer

00:02

crtdaydreams: I get it it's just that I already tested unpeer several times tonight

00:03

awt: patched with 9974

00:03

yup seems ok now

00:03

awt righto. I ought to set up testing w/ blatta myself and try and replicate it

00:04

I'll have a go tonight, gtg for now

~ 7 hours 32 minutes ~

07:36

PeterL: may I ask for my sites rss to be added to scoopbot please?

~ 1 hours 12 minutes ~

08:49

crtdaydreams: sure, what is the feed?

08:50

PeterL: 0xcdd.com/rss.xml

08:50

http only

08:54

OK, I'll get that added in just a bit

~ 41 minutes ~

09:35

hmm, it looks like I already added your site a while ago

09:37

PeterL oh oki, all good, I haven't uploaded in yonks but will probably be throwing something up soon

09:38

although, looks like the bot is down at the moment.

09:41

gave it a kick, back up again.

09:46

9974: http://share.alethepedia.com/blatta/9974-fix-exhume.vpatch http://share.alethepedia.com/blatta/9974-fix-exhume.vpatch.sig

~ 44 minutes ~

10:30

Running 9974

10:31

👍

~ 43 minutes ~

11:15

http://logs.nosuchlabs.com/log/pest/2022-07-10#1009277 << let me belaborate on this point for a second. an unreliable or otherwise mobile node might go down for arbitrary periods of time. when it comes back, afaiu right now the only form of communication it can do is ignore packet, to establish proper AT, and then wait for

11:16

broadcast OR prod to figure out what's missing. question is, why, when a mobile node comes back, not allow it to ask for packets forward? i'm not saying that this needs to be done, but more like what's the justification for doing a poll in this case, instead of pull?

11:18

isn't that what prod does?

11:20

IIUC, the response to a prod message will include the latest nethash, so once you get that you just use getdata until you work back to your lastest message

11:21

PeterL: correct

11:21

ah see i misunderstand prod. i thought that it's periodically sent by the counterparty, and it contains latest hash, which you then can check against your packets, and do a request. so in other words you connect and wait for a periodic prod to come in, rather than initiate prod.

11:22

*misunderstood

11:23

prod and getdata will each generate a single line of response, if you just say 'give me everything after ##' then you could get a response of unlimited size

11:25

or you could put an N on a request, and at get most N packets. as of right now you're at parity, 5mb of data requires 5mb of request

11:29

asciilifeform: at this point of practical pestronics you have to be pretty careful about what you respond to :> e.g. your "PeterL: correct" confirms two different messages on bitdash and on nosuchlabs

11:31

pestronic proof of work, you want 5mb of data! you send 5mb of request!

~ 30 minutes ~

12:01

http://logs.bitdash.io/pest/2022-07-11#1009136 << this lul existed in fleanode era fwiw. but good point

12:01

Logged on 2022-07-11 11:29:15 phf[billymg]: asciilifeform: at this point of practical pestronics you have to be pretty careful about what you respond to :> e.g. your "PeterL: correct" confirms two different messages on bitdash and on nosuchlabs

12:14

http://logs.bitdash.io/pest/2022-07-11#1009135 << asciilifeform dun like 'ddos amplifiers' (even given that we have message expirations and deduplication), imho oughta know exact mass of what yer asking for in advance

12:14

Logged on 2022-07-11 11:25:14 phf[billymg]: or you could put an N on a request, and at get most N packets. as of right now you're at parity, 5mb of data requires 5mb of request

12:22

http://logs.bitdash.io/pest/2022-07-11#1009140 << why wouldn't you know exact mass in my example? you ask for n packets you get n packets. or you mean just in general that trading 1 packet for n packets is that?

12:22

Logged on 2022-07-11 12:14:53 asciilifeform[billymg]: http://logs.bitdash.io/pest/2022-07-11#1009135 << asciilifeform dun like 'ddos amplifiers' (even given that we have message expirations and deduplication), imho oughta know exact mass of what yer asking for in advance

12:23

phf: the latter

12:24

poses a problem if replayed ( and yes, theoretically deduplication prevents, but in practice implementing the spec has not been trivial for the folx attempting... arguably asciilifeform's sin, for failing to make it trivial to implement )

12:28

the other thing, phf : the logic whereby getdata responses bypass the timestamp expiration filter requires knowing the hash of expected msg ~in advance~

12:28

morning

12:28

which is incompat. with 'send me N'

12:29

wb whaack

12:30

*

asciilifeform recognizes that the spec loox to readers like a chaotic spew, but in fact actually did attempt to think it through as a logical whole

12:31

hm, can't see phf now.

12:32

oh wait, yes I can.

12:32

wb signpost

12:32

howdy asciilifeform

12:33

for some reason still not exchanging packets with ya directly.

12:33

hm asciilifeform's at entry for signpost is stamped 6 jul

12:35

mind trying 66.69.38.97:7778 ?

12:35

*

asciilifeform added

12:35

cool, looks like worx now

12:35

ty

12:35

odd that it didn't update automagically

12:36

I apparently had an old entry for you in my own AT.

12:36

*

asciilifeform spent weekend on moar seeming interminable meat plumbing

12:36

or incorrect in either case

12:36

a

12:37

http://logs.bitdash.io/pest/2022-07-11#1009150 << there was no implication of that, but you know just because thought through doesn't mean thought through well. in this particular case the question was philosophical, because clearly that decision was intentional

12:37

Logged on 2022-07-11 12:30:38 asciilifeform[billymg]: recognizes that the spec loox to readers like a chaotic spew, but in fact actually did attempt to think it through as a logical whole

12:38

phf: encouraged to point out seemingly nonsensical moving parts tho, there's no guarantee that the thing is in fact properly reduced

12:38

asciilifeform not had , unfortunately, much time to return to the chalkboard & refine

12:39

hm yeah i can't see phf

12:39

erp nvm

12:40

my chat just has a different order than bitdash.io

12:40

schrodinger's phf

12:40

lol

12:41

i'm connected at different times through asciilifeform or awt, because i can't multichat yet :>

12:41

any criticism is with respective relays!

12:41

a, phf still shooting single-action via slime eh

12:41

lol

12:41

... bolt-action pestron lol

12:42

at this point the slime part i have least objection to :D once (br"... became muscle memory…

12:42

phf is vietcong, sniping the pest patrol one by one

12:44

http://glyf.org/screenshots/pest-slime.png

12:45

cheap&angry

12:46

solves asciilifeform's multi-line paste gripe, so already ahead of weechat.

12:47

indeed

13:01

hey billymg, the links in your log that point to ossasepia for trilema logs no longer work.

13:02

*

signpost looks forward to linking messages by message hash.

~ 43 minutes ~

13:45

http://logs.bitdash.io/pest/2022-07-10#1009088 << added

13:45

Logged on 2022-07-10 23:42:22 crtdaydreams[signpost]: and billymg; http://paste.deedbot.org/?id=6gfd peering info

13:47

signpost: do you mean log links that start in logs.ossasepia.com/log/trilema?

13:53

if that's what you meant i wasn't able to do "ilog tunneling" with ossabot links because her logger at one point got out of sync with dulapbot

13:53

same with eric's

13:54

yeah, I clicked one that went nowhere on her site.

13:54

*

billymg needs to disable this feature for bitbot/dulapbot when in #pest, but the way it's currently implemented is by bot, not chan

13:54

not a big deal

13:54

solves itself when folks quote lines by message hash in the future.

13:55

hey awt, what do you have in your AT for billymg?

13:55

signpost: indeed does, but q was re historical logs. afaik there aint any clean solution (other than asciilifeform's 'solution', where declared own log 'canonical' and invited folx to send in whatever's missing)

13:56

signpost: yeah i brought that up recently also, and then went to look for the previous thread (because i remembered it being discussed before)

13:56

Logged on 2022-06-20 16:33:35 billymg: asciilifeform: regarding syncing of line indices between logotrons, what if we added a field containing the hash of speaker (minus hearsay), chan, timestamp, payload to the db?

13:56

(ossasepia) 2020-04-20 diana_coman: in other things, since I am looking again at the annoying issue with log lines and numbers and whatnots - my current thinking is to ditch that source of trouble entirely and simply use hashes for each line to identify it uniquely AND across whatever bots

13:56

yeah, somebody'd have to retroactively munge harder identifiers into historic log

13:57

but this getting harder is part of the history, not a big deal imho

13:57

some historian can sit down and solve if they feel motivated.

13:57

signpost: so long as the archived line is actually in there somewhere, you can find it, in a pinch, via text search

13:57

yup

13:58

the only historic chan that aint in asciilifeform's db at all is #o, where at one pt bot was unceremoniously kicked and asciilifeform went 'wai log them if they dun want'

13:58

err, #e

13:58

#o is in

14:12

signpost: billymg 205.134.172.29:7778 2022-07-11 11:10:53.076080

14:12

billymg: 9975, 9974 might be interesting to you - fixed a bug where %unpeer deleted random keys

14:13

wonder if that's the issue, that maybe my key got nuked on billmg's end

14:13

could have been at least at some point

14:13

signpost: i've got a key for you still

14:14

starting in 'DHq'

14:14

billymg: are you seeing this key using the %wot command?

14:14

those bytes of the key are now leaked to the internets, lol

14:15

did i miss something where commands changed from /command to %command?

14:15

yah

14:15

slash still works apparently; I'm using it

14:15

with weechat's setting to send unknown commands

14:15

yeah, that's why i was confused

14:16

awt: shows same key whether via /wot signpost or %wot signpost

14:16

I left slash in because why not

14:17

billymg: ok just wanted to make sure they peer_id for the key was associated with the correct peer and that there aren't multiple floating about in the db.

14:17

I typically move to another buffer to issue sensitive commands, lest I accidentally fart a whole key to the wrong one.

14:17

it's bound to happen

~ 52 minutes ~

15:10

signpost: asciilifeform found only 1 'final solution' for the 'missile codes into wrong buffer' problem -- separate boxes / kvm

15:17

jonsykkel

wat if ur kvm fails and sends codes to wrong box

15:17

jonsykkel: what if yer ceiling fails and drops yer roof on you, similarly

15:17

jonsykkel

indeed

15:17

(suspect, moar likely)

15:18

jonsykkel

i gotta get that ceiling fixd up asap

15:23

test

15:24

don't know why i think that it makes sense to write custom binary parser every time..

15:26

you just need to install a second ceiling under the first one to catch it if it happens to fall down

~ 2 hours 20 minutes ~

17:46

random

17:47

/dev/random

17:48

echo "echo"

~ 27 minutes ~

18:16

!!help

18:21

http://deedbot.org/help.html

!!help

18:21

deedbot

18:22

awt: ^ oughta be usable now. seems like it gets stuck.

18:22

might be a bug on the deedbot side, not sure. I'm at some point going to get a pest station feeding directly into its postgres db to remove complication.

18:23

*

signpost leaves deedbot logs up for now.

18:26

!e uptime

18:26

!e uptime

18:27

whaack: time since my last reconnect : 2d 22h 42m

18:28

!e view-height

18:29

whaack: time since my last reconnect : 2d 22h 44m

18:31

check

18:31

signpost: doesn't look like it's just deedbot that gets stuck.

18:31

!c uptime

18:31

!. uptime

18:31

billymg: time since my last reconnect : 8d 1h 48m

18:31

block_height: 744613

18:31

mins_since_last_block: -2

18:32

it often seems as if my bot wants one more message before it sends a reply

18:33

$uptime

18:33

*

shinohai now reminded he needs to update bot station

18:33

busybot

The bot has been up for: 22 days 3 hours 50 minutes and 11 seconds

18:35

!c uptime

18:37

!c uptime

18:39

!c uptime

18:40

ok, one more time

18:40

!c uptime

18:40

billymg: last reconnect: 1m ago; last restart: 1m ago

18:40

there we go

18:41

in working on this i updated the crawlerbot pairing for billymg, forgot to revert

18:41

Logged on 2022-07-09 12:02:30 billymg: i have it on my todo list to move my pest station to a local box, possibly that'll fix some of the lingering issues (not being able to peer with some people, join/part)

18:44

!c net-summary

18:44

Bitcoin Network (IPv4 Nodes Active Within the Last 48 hours) Global: 7343; TRB-Compatible: 29; TRB: 15

18:44

TRB-Compatible by Country: United States: 7; Germany: 4; Romania: 3; Singapore: 3; Brazil: 1; Canada: 1; Italy: 1; Algeria: 1; France: 1; Andorra: 1; Sweden: 1; United Kingdom: 1; Belgium: 1; Ukraine: 1; Spain: 1; Bulgaria: 1;

18:45

TRB by Country: United States: 9; Canada: 1; Romania: 1; Lithuania: 1; France: 1; New Zealand: 1; Norway: 1;

18:51

that's an all time high for TRB nodes (since the crawler started keeping track of the stat)

18:52

!c trb-status

18:52

75.106.222.93 (Alive), h=744612, v=99999, United States - peers: 267 - last probed: 29m ago

18:52

205.134.172.4 (Alive), h=744612, v=70001, United States - peers: 70 - last probed: 30m ago

18:53

85.164.243.42 (Alive), h=744612, v=99999, Norway - peers: 68 - last probed: 31m ago

18:53

54.38.94.63 (Alive), h=744612, v=88888, France - peers: 68 - last probed: 30m ago

18:54

54.39.156.171 (Alive), h=744612, v=99999, Canada - peers: 66 - last probed: 30m ago

18:54

82.79.58.192 (Alive), h=744612, v=99999, Romania - peers: 53 - last probed: 30m ago

18:54

208.94.240.42 (Alive), h=744612, v=99999, United States - peers: 44 - last probed: 30m ago

18:56

71.114.46.117 (Alive), h=744612, v=99999, United States - peers: 39 - last probed: 32m ago

18:57

185.254.196.12 (Alive), h=312191, v=99999, United States - peers: 26 - last probed: 30m ago

18:57

205.134.172.6 (Busy? (No answer in 15 sec.)), h=744343, v=99999, United States - peers: 34 - last probed: 30m ago

18:57

205.134.172.28 (Alive), h=744612, v=99999, United States - peers: 15 - last probed: 30m ago

18:57

94.176.238.102 (Busy? (No answer in 15 sec.)), h=744609, v=99999, Lithuania - peers: 24 - last probed: 30m ago

18:57

205.134.172.26 (Alive), h=744612, v=99999, United States - peers: 32 - last probed: 30m ago

18:57

103.6.212.28 (Alive), h=743581, v=99999, New Zealand - peers: 15 - last probed: 29m ago

18:57

205.134.172.27 (Alive), h=744612, v=99999, United States - peers: 4 - last probed: 30m ago

19:08

$ticker btc usd

19:08

busybot

Current BTC price in USD: $19919.9

19:08

sub-20k corn again

~ 19 minutes ~

19:28

evenin' signpost o/

19:41

whaack: for some reason bots seem often to be behind.

19:41

pestbot: ping

19:41

pestbot

pong

19:41

whaack: for some reason pestbot is usually up to date

19:43

Something about being connected to only one other station. Not sure what's going on though.

19:48

awt ... latency issue?

19:48

(Mine only connected to me but lately have noticed a bit of delay)

19:48

shinohai: depends on what you mean by latency

19:50

In any case, the current set of bots we have don't really care about history. The order buffer for them is really just an annoyance.

19:58

for bots, setting order_buffer_check_seconds and order_buffer_expiration_seconds to like 10 should speed things up quite a bit.

↖ ↖ ↖ ↖

20:05

broadcast pkt using new packet parser/generator (take 4, maybe without selfchain?)

20:06

ok, works

20:12

broadcast pkt using new packet parser/generator (take 3)

~ 21 minutes ~

20:33

phf: neato

20:34

*

asciilifeform loox fwd to reading phf's wunderwaffe

~ 2 hours 50 minutes ~

23:24

it's pretty gnarly, but that's by design

~ 33 minutes ~

23:57