PeterL: hey everybody
PeterL: asciilifeform: did you see this one? 2021-11-16 08:17:42.811785 [71.191.220.241:50725] <- 52a65a94ca2003b8
PeterL: I think the idea is once we get the kinks ironed out on what the spec should actually contain that people will write a couple versions in languages like c,d,ada, etc
PeterL: so yes, it is good to write your own
PeterL: http://btc.info.gf/paste/b670e8@raw << here is some of the debug log, let me know if you think having more of it would help diagnose the connection problem?
asciilifeform: jonsykkel: plox to repost in #a , seems like the bot lost your logline
asciilifeform: PeterL: i looked through own debug log, not 1 of your packets made it here, still nfi why
asciilifeform: seems clear that your station is sending (at least far as dbg log goes) as is mine
asciilifeform: jonsykkel: is odd, because you're defo within 3 bounces of it
PeterL: maybe our keys don't match or something?
asciilifeform wonders whether awt's proggy has a < where there oughta be a <=
asciilifeform: PeterL: if they didn't match, you'd see martians
asciilifeform: and ditto on my end
asciilifeform: while neither of us appears to have
asciilifeform: hm possibly
asciilifeform: arguably we only have a bucket brigade of this length cuz peering dunwork reliably yet
asciilifeform: right
asciilifeform must bbl
billymg: jonsykkel: can you pgpgram me your peering info just so we can see if that solves the logging issue?
billymg: jonsykkel: ok, added you
jonsykkel: alrite, test
jonsykkel: seems to work
billymg: nice
billymg: those /alias commands also work in weechat, very helpful
billymg: only slightly different syntax: https://weechat.org/files/doc/stable/weechat_user.en.html#alias_commands
billymg: the /quote thing was driving me nuts
jonsykkel: yeah terrible ux
awt: oh nice to know they work in weechat too
awt: patch for hash based deduplication coming tonight or tomorrow morning
PeterL: http://logs.bitdash.io/pest/2021-11-16#1000692 << saw this one come through twice?
bitbot: Logged on 2021-11-16 17:08:40 billymg: those /alias commands also work in weechat, very helpful
awt: same
PeterL: looks like I got the same message from awt and jonsykkel ?
awt: dedup was pretty messed up, but it was over-dropping rather than under-dropping, so still don't have an explanation for occasional double messages.
awt: best guess so far is some how two duplicate messages are being sent to one peer from the source.
awt: it is difficult to diagnose though because it is intermittent.
awt: ohhhhhhhh
awt: possible the message was sent once with one timestamp, and then to another peer with a *different* timestamp
awt: so next patch should fix if that's the problem
PeterL: why would the timestamps be different?
awt: PeterL: because gor broadcast messages blatta grabs the timestamp each time it packs a message for a peer.
PeterL: hmm, shouldn't timestamp be constant based on when it got the message, and then the same time used for all peers?
awt: no I'm talking about originating a message not rebroadcasting
awt: timestamp isn't touched for rebroadcasting
PeterL: so for broadcasting, it should build the message (timestamp, user, message) and then pack that to each peer
awt: PeterL: right
PeterL: right, it should be the same thing when generating - you make a single message and then broadcast it to each peer
awt: should be yes
awt: is not
awt: regarding bounces, the way I tested it when developing was to set up a chain of length three, set MAX_BOUNCES to 0, and verify that the third station never received the message.
awt: Testing 9988
jonsykkel: nice
awt: So nice blatta sent it twice lol
jonsykkel: feature
awt: Interesting fact I discovered while fixing dedup: blatta was writing all rubbish messages to the log table in the db. You may find your db file to be somewhat large. After upgrading you can delete all entries in your log table. Won't break anything. Best to do before starting up blatta though.