| 07:51 |
punkman |
asciilifeform: I think a ping-pong mechanism might be useful for Pest. Case: I start station up, ping all peers in Wot, if X or Y doesn't answer, I can go and look for their new IP address. Case 2: I have received no messages for a couple hours, I do "/ping ALL" and see if any stations are still online, if I need to reconfigure something, etc |
| |
↖ |
| 07:56 |
punkman |
can be implemented as special direct message that is not displayed by default |
| |
~ 31 minutes ~ |
| 08:27 |
punkman |
if we add current timestamp to ping/pong, we can also see how close our clocks are with any given peer and possible emit msg to operator if clock difference is larger than X seconds |
| |
↖ |
| |
~ 1 hours 1 minutes ~ |
| 09:29 |
punkman |
why not have hash of last msg from peer in "3.1.3.2. NetChain (Direct Messages)"? |
| |
↖ |
| 09:32 |
* |
punkman is going through spec and writing code outline |
| |
~ 1 hours 43 minutes ~ |
| 11:15 |
punkman |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057452 << meant last direct message from peer, in case it wasn't clear |
| 11:15 |
dulapbot |
Logged on 2021-09-11 05:29:11 punkman: why not have hash of last msg from peer in "3.1.3.2. NetChain (Direct Messages)"? |
| |
~ 2 hours 6 minutes ~ |
| 13:22 |
asciilifeform |
punkman: this actually is already in my working draft... |
| 13:23 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057449 << this, otoh, is quite unnecessary, on account of the AT mechanism -- recall, [http://www.loper-os.org/pub/pest/pest_FE.html#22-peers-and-keys]['Additionally, at least one of the peers must have a routable, static address (here and below: IPv4 address and port, in a.b.c.d:p notation), and it must |
| 13:23 |
dulapbot |
Logged on 2021-09-11 03:51:43 punkman: asciilifeform: I think a ping-pong mechanism might be useful for Pest. Case: I start station up, ping all peers in Wot, if X or Y doesn't answer, I can go and look for their new IP address. Case 2: I have received no messages for a couple hours, I do "/ping ALL" and see if any stations are still online, if I need to reconfigure something, etc |
| 13:23 |
asciilifeform |
be known to the other peer.'] |
| 13:23 |
asciilifeform |
if at least one of a pair of peers has a static ip, it will never 'lose' the other |
| 13:25 |
asciilifeform |
(the AT is updated when a packet is received. and 'Ignore' packets will be received (tho i did not specify how often..) from every peer with a working connection) |
| 13:27 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057451 << you get this for free when you exchange already-defined cmds (incl. 'Ignore'), so not sure why would want a dedicated one |
| 13:27 |
dulapbot |
Logged on 2021-09-11 04:27:35 punkman: if we add current timestamp to ping/pong, we can also see how close our clocks are with any given peer and possible emit msg to operator if clock difference is larger than X seconds |
| 13:28 |
asciilifeform |
(ALL packets include timestamp) |
| |
~ 16 minutes ~ |
| 13:44 |
punkman |
"Ignore" msg is not gonna get an ACK with other side's timestamp though, and if "Direct message" the ACK only includes sender's timestamp, right? |
| |
↖ |
| |
~ 16 minutes ~ |
| 14:01 |
signpost |
there's a use-case for the ping/pong mechanism in measuring loss, which would allow me to tune a fountain code |
| |
↖ |
| 14:02 |
signpost |
could implement this atop though. |
| |
~ 1 hours 14 minutes ~ |
| 15:16 |
punkman |
I think being able to handle stations with unreliable connection is a good thing. Also why I like "getdata" catchup mechanism. |
| |
↖ |
| 15:24 |
punkman |
would be easy to build ping "on top" of direct message. no need to have in protocol. if building things on top though, would be nice to have a "give me your supported station/client features" direct message command |
| |
↖ |
| 15:38 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057465 << asciilifeform's current thinking is that the 0xFE ack mechanism is braindamaged, and there oughta be a dedicated ACK command message type. |
| 15:38 |
dulapbot |
Logged on 2021-09-11 09:44:21 punkman: "Ignore" msg is not gonna get an ACK with other side's timestamp though, and if "Direct message" the ACK only includes sender's timestamp, right? |
| 15:39 |
* |
asciilifeform atm writing spec sections for 'getdata', 'rekey-offer', 'rekey-slice' |
| 15:40 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057466 << hm i thought half the appeal of fountains is that no need to measure, the receiver simply says 'enough' when it gets the req'd N of slices |
| |
↖ |
| 15:40 |
dulapbot |
Logged on 2021-09-11 10:01:09 signpost: there's a use-case for the ping/pong mechanism in measuring loss, which would allow me to tune a fountain code |
| 15:41 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057468 << asciilifeform agrees, tho with the proviso that at least 1 peer in a pair gotta have a reliable (and staticly ip'd) connection |
| 15:41 |
dulapbot |
Logged on 2021-09-11 11:16:52 punkman: I think being able to handle stations with unreliable connection is a good thing. Also why I like "getdata" catchup mechanism. |
| 15:42 |
asciilifeform |
otherwise no way for'em to connect except via hearsay |
| 15:42 |
asciilifeform |
(via third peer) |
| 15:42 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057469 << the 'your supported features' thing is what the 'version' field is for, neh |
| 15:42 |
dulapbot |
Logged on 2021-09-11 11:24:53 punkman: would be easy to build ping "on top" of direct message. no need to have in protocol. if building things on top though, would be nice to have a "give me your supported station/client features" direct message command |
| 15:47 |
* |
asciilifeform can picture a hypothetical future megaprotocol where can e.g. 'gimme next frame of bingoboingo's film', 'search query'/'result', etc. p2pisms, and need trb-style flag bits to indicate support. these can go in the currently reserved byte. but we aint there yet. ) |
| 15:49 |
asciilifeform |
for 'getdata', my current approach is: stations have a dedupe buffer (as given in 0xFE) but this is merely a 15min.-long subset of a larger (up to operator) buffer which can be used to answer 'getdata's. |
| |
↖ |
| 15:49 |
asciilifeform |
i.e. built-in logotron of sorts. |
| 15:51 |
* |
asciilifeform also reworking the 'fork' handling mechanism, in light of above -- simply because your station was switched off for a day does not mean that it oughta mark all yer peers as forked -- if it can successfully retrieve unbroken selfchains for all of'em |
| |
↖ |
| 15:52 |
asciilifeform |
and, relatedly: if we have ACKs, then possibly oughta reject in-wot hearsay pertaining to a 'live' peer, categorically ? (how then define 'live' ? when to accept in-wot hearsay again ?) |
| |
↖ |
| 15:53 |
asciilifeform |
and, again relatedly, if we have a concept of 'live', oughta indicate w/ emulated irc join/part msgs on console ? |
| 15:54 |
* |
asciilifeform still not certain ACKs are a good idea at all. |
| 15:58 |
signpost |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057473 << they have tunable parameters which impact the amount of data necessary to transmit before probability of decoding the message goes to 1 |
| |
↖ |
| 15:58 |
dulapbot |
Logged on 2021-09-11 11:40:33 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057466 << hm i thought half the appeal of fountains is that no need to measure, the receiver simply says 'enough' when it gets the req'd N of slices |
| 15:58 |
signpost |
can certainly just pick values that are pretty good, and piss until other end says enough |
| 15:59 |
signpost |
you can make more efficient use of the wire if you have a measurement |
| 15:59 |
signpost |
(and yes, can infer from when "enough" comes too) |
| 15:59 |
signpost |
so there are different approaches |
| 15:59 |
signpost |
I'm not strictly in favor of ping/pong, was just speculating a reason to exist |
| 16:02 |
signpost |
also certainly cases where spray-and-pray is desired, and should not ever have an ack from the listener. |
| |
~ 33 minutes ~ |
| 16:36 |
asciilifeform |
signpost: imho broadcasts oughtn't get ack'd |
| |
↖ |
| 16:37 |
asciilifeform |
re versions -- a 'version' cmdtype would be reasonable, a la trb's (i.e. sends a string) |
| 16:37 |
asciilifeform |
1 side sends 'version' -- other replies with 'version' likewise. |
| 16:37 |
asciilifeform |
(again a la trb) |
| 16:37 |
asciilifeform |
this'd double as a 'ping' ditto |
| 16:38 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057488 << a yes, the redundancy degree |
| 16:38 |
dulapbot |
Logged on 2021-09-11 11:58:33 signpost: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057473 << they have tunable parameters which impact the amount of data necessary to transmit before probability of decoding the message goes to 1 |
| 16:39 |
* |
asciilifeform suspects that lubyism will need dedicated experiments to tune properly (and for various scenarios -- long-haul international; gsmism; etc) |
| 16:40 |
* |
asciilifeform recalls the europistan<->piz udp experiment, where iirc was found that packets ~never lost, but occasionally arrive outta order |
| 16:40 |
signpost |
yup |
| 16:41 |
signpost |
also perhaps MTU discovery comes in, but these are all problems to have once a basic item is in place. |
| 16:42 |
asciilifeform |
eh 508byte 4evah, imho |
| 16:42 |
asciilifeform |
permitting reassembly is an allcomers hole -- given as you can't authenticate the frags. |
| |
↖ |
| 16:42 |
asciilifeform |
(iirc we discussed in agonizing detail) |
| 16:42 |
signpost |
ah, that is a great point. |
| 16:42 |
* |
signpost sets aside. |
| 16:43 |
asciilifeform |
btw imho oughta permit >508, but with proviso that the excess bytes are rngola and uninterpreted. |
| 16:43 |
asciilifeform |
(this -- pill against whatever nonsensical censor ids that barfs on '508 bytes udp -> evil' |
| 16:43 |
asciilifeform |
) |
| |
~ 35 minutes ~ |
| 17:19 |
punkman |
happy anniversary, 20 years since 9/11. Here's Alex Jones on 9/12 |
| |
~ 37 minutes ~ |
| 17:57 |
signpost |
punkman: "prison planet" is looking pretty apt these days eh? |
| 17:58 |
punkman |
signpost: "info wars" as well |
| 18:01 |
signpost |
yup, problem with the guy has always been he can't filter |
| 18:01 |
signpost |
just gets nic'd up and excited about w/e is fed his way |
| 18:01 |
billymg |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-10#1057421 << i enjoyed this, pretty good as a normie marketing campaign for pest too imo |
| |
↖ |
| 18:01 |
dulapbot |
Logged on 2021-09-10 16:53:45 bingoboingo: Took a break from seeing how dumb I could take bubblewrap chasing sound freaks to lament how Internet unfolded https://www.youtube.com/watch?v=Cd0lc5UkLw4 |
| 18:02 |
signpost |
still curious why folks want normies anywhere |
| 18:02 |
billymg |
i used to be a normie |
| 18:02 |
punkman |
signpost: I wonder now though, has Jones even been wrong about anything? |
| 18:03 |
billymg |
the default is to start life as a normie, some can break out of it, some can't (or won't) |
| |
↖ |
| 18:03 |
signpost |
seems like sandy hook happened, but what do I know |
| 18:05 |
signpost |
billymg: sequencing matters, lest normie uptake corrupt the ability for thinking men to have their freedom. |
| |
↖ |
| 18:06 |
signpost |
if normies end up making it onto thinking-man-net, great! can't be a design goal of the thing though, or in comes "the consumer has come to expect" |
| |
↖ |
| 18:07 |
signpost |
see above where my own desire to maximize bittorrent-esque download speed sucks in an unacceptable compromise (in re: MTU) |
| 18:07 |
signpost |
gotta be wary of these. |
| 18:07 |
billymg |
signpost: of course, would never suggest to compromise anything (ANYTHING) for the normie |
| |
↖ |
| 18:08 |
punkman |
signpost: if torrent-speed is needed, might as well bootstrap proper torrent connection through Pest |
| 18:09 |
signpost |
nah, online-codes provides for a superior swarm-spread of large binwads |
| |
↖ |
| 18:09 |
signpost |
but yeah, one can always use what exists too |
| 18:09 |
signpost |
the o-c method doesn't require large MTU, just would possibly squeeze maor bitz |
| 18:10 |
signpost |
(also, perhaps because o-c is more efficient, it nets out. worthy experiment at some point) |
| 18:10 |
punkman |
well if not torrent, any separate protocol you like |
| 18:10 |
signpost |
yup |
| |
~ 52 minutes ~ |
| 19:03 |
punkman |
https://www.geertvandenbossche.org/post/the-last-post |
| |
↖ |
| 19:03 |
punkman |
"I am getting vilified for pretending to have a crystal ball (which, in fact, I never did) whereas ‘nobody could reasonably predict the outcome of this pandemic’. To me, such allegations simply illustrate that many of our experts and scientists, even including a substantial number of renowned professors, are so stuck within their small silos |
| 19:03 |
punkman |
that they have simply lost touch with reality." |
| |
~ 55 minutes ~ |
| 19:59 |
bingoboingo |
billymg tyvm |
| |
~ 1 hours 22 minutes ~ |
| 21:22 |
scoopbot |
New post on Bingology - The Blog of Aaron 'BingoBoingo' Rogier: Dead Internet Theory And Searching For The Sticky |
| |
↖ ↖ |
| |
~ 18 minutes ~ |
| 21:41 |
signpost |
punkman: https://www.meissavaccines.com/vaccine-pipeline << these folks are apparently working on an attenuated virus vaccine |