Hide Idle (>14 d.) Chans
← 2021-09-11 | 2021-09-13 → ↓
asciilifeform open to persuasion on subj, but has difficulty justifying why to make folx type longer command
billymg: i noticed that pattern also, but i thought it worked with 'peer' and 'pause' because those work as verbs, e.g. "to peer with someone" means to add them as a peer
billymg: or to pause something
billymg: but 'key' didn't fit in the same way
asciilifeform: actually in 100yo+ lit cipher machines are referred to as 'keyed' or 'unkeyed'
asciilifeform: and to this day
billymg: aha, yes, but the use there is different
billymg: "one sec, i need to key in your number"
asciilifeform: mno, not 'key in'. but 'key'.
asciilifeform: e.g. in usg lit, 'this device is unclassified when unkeyed'
billymg: asciilifeform: hmm, in that example meaning "unlocked"?
asciilifeform: meaning, not containing a cipherkey.
asciilifeform: (in whatever designated receptacle for same)
billymg: ahh, hmm. i admit i wasn't familiar with that usage before
asciilifeform: example usage in reich: '... The device itself is an UNCLASSIFIED controlled cryptographic item (CCI) as long as it is unkeyed. When keyed, it assumes the classification level of the key in use. ' etc
billymg: interesting, i guess it works pretty well then for what it describes
asciilifeform genuinely bbl
punkman: interesting background on this company we all know now https://www.statnews.com/2017/01/10/moderna-trouble-mrna/
punkman: "mRNA is like software: You can just turn the crank and get a lot of products going into development."
punkman: "Yet Moderna could not make its therapy work, former employees and collaborators said. The safe dose was too weak, and repeat injections of a dose strong enough to be effective had troubling effects on the liver in animal studies."
signpost: most of the shrinks belong in prison.
signpost: asciilifeform: re-digesting pest. it comes to mind that were the station aware of wot ratings, it could weight the capacity it's willing to dedicate to each peering, but I think this is something to deal with once problem's had, if at all.
signpost doesn't wish to overcomplicate things, just pointing out the area of potential improvement.
signpost: I am more willing to dedicate repeater capacity to your packets than some newb I let peer up for the first time.
signpost: were one to implement a pest node with an interface from which to extract usage, and with which to adjust capacity allocations, the rest can be handled by some other program, as simple or complicated as one wants.
signpost: again. totally fine to leave for later. can first invent a bed and then discuss what kinds of sheets are desired.
signpost can imagine future scenarios where someone important "talking" absolutely *must* get through.
signpost reads on
signpost: am I correct that PAUSE means "ignore the output of this peer and do not forward"?
signpost: how does this differ with GAG/UNGAG?
signpost loves the ACHTUNG/SCRAM mechanism for honorable death
signpost: occurs to me that involving intentionally opposable messages in some manner might remove the need for manual intervention when e.g. self-chain forks happen.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-12#1057658 << direct support for wot is definitely part of asciilifeform's picture of the thing. queue prioritization (beyond 'in the back / in the front') has considerable overhead tho, so only makes sense if the traffic volume in fact justifies it
dulapbot: Logged on 2021-09-12 12:16:13 signpost: asciilifeform: re-digesting pest. it comes to mind that were the station aware of wot ratings, it could weight the capacity it's willing to dedicate to each peering, but I think this is something to deal with once problem's had, if at all.
signpost: indeed. merely pointing out areas where interesting problems arise. it's good to let interesting problems happen first, before trying to solve.
asciilifeform: signpost: difficult to include opposable-anything directly in the protocol w/out bringing in rsa
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-12#1057666 << great question -- (UN)PAUSE is for a peer; (UN)GAG is for any message in general incl. hearsay. currently they're uncoupled, but possibly some kinda coupling is justified
dulapbot: Logged on 2021-09-12 12:22:20 signpost: how does this differ with GAG/UNGAG?
asciilifeform: i.e. unpeering w/out gagging will still have you picking up same thing as hearsay if even one peer still peers with $victim
asciilifeform: gag == killfile functionality for messages
signpost: ah. one's "I wish to no longer drink from this pipe for now", and other "I wish to hear nothing of this $derp"
asciilifeform: correct
signpost: makes sense.
asciilifeform: not only 'hear nothing' but 'not rebroadcast' also
asciilifeform: i.e. messages matching a speaker in the killfile get dropped after decoding
signpost: regarding netchain, seems like threading comes in via choosing to specify an older broadcast message, rather than most recent
signpost: (this is mighty cool protocolization of the hyperlink backreferences currently used)
asciilifeform: not specified atm because no irc client supports any such thing
asciilifeform: but it's why i put it there.
asciilifeform: signpost: on asciilifeform's open-problems list, currently : 1) what's the optimum way to do acks? 2) what's a reasonable way to handle forks ? (trigger; indication; and resolution) ?
asciilifeform: ( there's this, but still leaves questions )
dulapbot: Logged on 2021-09-11 11:51:15 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
signpost: were the netchain used in UI you'd notice that suddenly folks that were agreeing on netchain suddenly forking off into chunks of the conversation
signpost: not distinguishable from them choosing to address different parts of the conversation, and it's unclear if a distinction is needed.
asciilifeform: one can still sort by time on ui end
signpost: they are in either case talking about what they're referencing, and in both cases the result is an accurate view of how coherent the convo has been.
asciilifeform: 'netchain' is simply a riff on usenet's original representation.
signpost: can perhaps draw lines along the left gutter to show how much or little agreement there is on line-of-history, or one could dream up lots of other representations
signpost likes the idea that the thing shows exactly wtf has passed through the eye of the station without further interpretation/inference
asciilifeform intended, in 'pest', to make a kind of 'construction kit' for interesting protocols -- can be extended for wot, warez, hypothetically even distributed video hosting, telephones, other exotica
signpost: indeed, all that oughta be achievable
signpost: regarding forks, can I simply getdata my peers for the history I've missed?
asciilifeform: that's the point of getdata, yes. but not guaranteed to get the sought item (or to get it in time)
signpost: if your friends don't want to catch you up, seems like you're forked indeed
asciilifeform: you gotta time it out at some pt and declare $peer forked, if can't get an unbroken selfchain for him w/ getdata
asciilifeform: signpost: not necessarily 'don't want', can be vagaries of the net, that no one answered in time
signpost: this is because getdata pulls things from the cache, right?
signpost: which times out?
asciilifeform: even let's suppose everyone stores infinite log.
asciilifeform: the ~emitter~ of the getdata (i.e. the station that needs to ask for the missing msgs) has to time out at some point
asciilifeform: because otherwise, what, will embargo every incoming message from that peer, forever, until someone deigns to answer..?
signpost: this is why sync order never really made sense to me in trb, seems backwards
signpost: why not work backwards from what you're seeing in the present moment, assuming your peers are friends. which in this case they are.
asciilifeform: signpost: in trb was as it was because erryone could agree on block 0
signpost: "just saw $x, plz gimmeh block parent of $x"
signpost: when not peered with friends, better yeah, start from dawn of history
signpost: and if your friends are all wrong about what tip of history is, you're fucked for reasons entirely other than pest-tronics
asciilifeform: signpost: think about it for a sec, it is trivial to fabricate infinitely many paths backwards to the genesis block. there'd be no possibility of even the concept of a canonical one, if sync worked backwards.
asciilifeform: (this in re bitcoin strictly! not pest, lol)
signpost goes and grunts at the section on netchain again
asciilifeform will return shortly.
signpost: trying to wrap my head around whether there's such thing as a real line of history here from which one can be forked.
signpost: with a direct peer, it seems I should be able, just like in a phone conversation that temporarily loses connection, "hey buddy, I lost ya for a moment. what did you say?"
signpost: and if you give me a line of packets that never meets up with what I caught previously, I start to wonder indeed what's up with asciilifeform
signpost: or with the wire between us. it's actionable signal if this happens
punkman: I think getdata should be for "I lost ya for a moment", not for catching up with weeks of chat
punkman: could have different mechanism for importing months' worth of chat from friend's archive
signpost: punkman: yeah, and without all messages being signed, you're really left with line of history being no more specific than "this is what was said before punkman"
signpost: cannot be said what was said before god
signpost: I don't think there's any need to try to construct such a god either.
signpost will afk for a bit then grunt more of this into head.
punkman: lack of public keys requires weird contortions
signpost: dunno it's undesirable. you have pretty good assurance that your buddy said w/e if you're directly peered.
signpost: if you want to swear, stick signed material into the chatternet
asciilifeform: punkman: the whole protocol is one big 'weird contortion' around the fact that we can't do rsa at line rate but 'want to play anyway because fuckerryone'
asciilifeform: asciilifeform's scheme does not try to do the impossible (e.g. opposable signatures at line rate on pc) but next best thing -- nomoar ddos (reject at Gb/s easily on even 8core box; agnostic of ip, so if you have 9000 nics -- you're in biznis for so long as ~1~ can send/receive packets; rejection of replays; and finally, you get to have a ~reasonable~ if not perfect idea that you're talking at time T to same person as a
asciilifeform: t T-1.)
asciilifeform: not a replacement for opposable gpg-type signatures by any means. but imho enuff to get the fuck off ddos-and-mitm-net.
asciilifeform: upstack -- forgot to mention -- there's the problem of in-wot-hearsay. 99.999% of it will be completely useless 100% of the time ;
dulapbot: Logged on 2021-09-12 12:38:13 asciilifeform: signpost: on asciilifeform's open-problems list, currently : 1) what's the optimum way to do acks? 2) what's a reasonable way to handle forks ? (trigger; indication; and resolution) ?
asciilifeform: thing needs a rejection mechanism for it, and not merely the simplistic one in 0xFE.
dulapbot: Logged on 2021-09-11 11:52:56 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 ?)
asciilifeform will brb
billymg: asciilifeform: question re: spec, in 4.1.2.3, when a message is rebroadcast up to the bounces limit, does this include the originator of the message (who also receives an ACK/receipt)? or would it only be rebroadcast to every WOT peer excluding the originator of the message?
punkman: billymg: no ACK for broadcast messages, unless next version adds it
billymg: punkman: in 4.1.1 Common Prologue for All Packets, step 9 mentions the ACK behavior. that's what led me to believe it would occur for both broadcast and direct messages
dulapbot: Logged on 2021-09-11 12:36:45 asciilifeform: signpost: imho broadcasts oughtn't get ack'd
billymg: punkman: ah, apologies, i must have missed that in the discussion
punkman: went to look 4.1.1 and thought wtf, this is not "Common prologue...", then saw that under 4.2 it starts with 4.1.1 again
billymg: punkman: ha, yeah, known bug
dulapbot: Logged on 2021-09-08 13:28:30 asciilifeform: re 0xFE -- lulzily no one noticed that 4.1 and 4.2 numbering is entirely fucked.
punkman: suppose I want to send a paragraph-sized quote that needs 3x320 bytes, if first message said "1 of 3", then station could delay sending to IRC client, until it has all 3 parts gathered.
punkman: so you don't get interruptions inbetween longer messages. same for bot answers with many lines
punkman: https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8 "there are over 40 different bridge projects." still wondering who the fuck uses all these things
asciilifeform: punkman: not sure why to delay sending; the thing to do might be to delay display (on receiver end) for a multiparter. but not sure whether the req'd complexity is a net gain
asciilifeform: (realize that sending the frags together would not guarantee their arrival together anywhere)
asciilifeform suspects that all of this can be accomplished with existing spec's selfchain/netchain
punkman: asciilifeform: delay display (on receiver end) << yes this is what I meant
punkman: and if receiver doesn't get N of N messages in say 5 seconds, then can start displaying anyway
punkman: if you send 3of3 first, the selfchain pointing to 2of3, then send 2of2, selfchain pointing to 1of3, you get an approximation of this
asciilifeform: ^ imho is the Right Thing
asciilifeform: when using conventional irc client as the control head though, you can only make a chain of length 2
asciilifeform: (given as irc permits 512byte, and that includes the msdos-style 2-char line end)
asciilifeform: plug the string PRIVMSG and etc
punkman: hmm indeed, chunking at IRC client side is not in our control
asciilifeform: a hypothetical irc-free implementation could emit chains of any length you like
asciilifeform: but we aint there yet
asciilifeform: thinking again about 'getdata' : this won't work as given. because if timestamp indicates 'stale' (>15min in the past) the answer to the 'getdata' will be tossed.
dulapbot: Logged on 2021-09-11 11:49:42 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.
asciilifeform: presently i can think of exactly 2 solutions :
asciilifeform: a) TWO timestamps, one concerning a packet, and the other -- the message therein; the former must be 'fresh', the latter -- could be an ancient msg sent as a response to getdata. this is imho a horrid kludge.
asciilifeform: b) ONLY <15min old msgs can be requested in a 'getdata'.
dulapbot: Logged on 2021-09-12 12:59:04 punkman: I think getdata should be for "I lost ya for a moment", not for catching up with weeks of chat
asciilifeform: and yes (b) means that if yer station loses its net connection for >15min (or potentially even smaller interval) you lose track of all chains.
asciilifeform: the obvious advice is 'don't do that'.
asciilifeform: (a) is imho ridiculous and mentioned strictly for completeness.
asciilifeform: ... this is more of a problem than seems at first. consider the case where your station loses connectivity for a spell. you notice after coupla hrs and find out that you sent your last 10 msgs into the void, they went nowhere.
asciilifeform: your peers notice that your self/net chains are outta sync. they request the missing msgs but lolno, because they're old.
asciilifeform thinking further, there's 0 point to there being such a thing as a fork alert re a ~direct peer~.
asciilifeform: the only point of the selfchain with direct peer is to be able to request a missing msg in the event of packet loss.
asciilifeform: the case where selfchain is important, is the 'hearsay' case.
asciilifeform: so far the only solution asciilifeform can think of, is 'pest is not for casualtards who don't have 24/7 fiber. if you don't have at home, get a box in a dc.'
asciilifeform: there simply should not be such a thing as a >15min outage.
asciilifeform: who can think of a better/moar-inclusive solution -- plox to write in.
dulapbot: Logged on 2021-09-10 08:59:32 PeterL: verisimilitude: have you thought of adding comment functionality to your blog?
verisimilitude: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-10#1057182 The idea is it uses multiple copies in a way which prevents tampering from reasonably happening, without a hash checksum or whatnot.
dulapbot: Logged on 2021-09-10 09:01:28 PeterL: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-09#1057145 << You say your scheme is ideal, but after reading the article I am not sure what your scheme is or how it helps anything?
verisimilitude: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057543 We've had similar ideas, bingoboingo; why make smart machines when making others act like dumb machines is so much easier?
dulapbot: Logged on 2021-09-11 17:22:23 scoopbot: New post on Bingology - The Blog of Aaron 'BingoBoingo' Rogier: Dead Internet Theory And Searching For The Sticky
bingoboingo: verisimilitude: Maybe? Just I'm not sure what to do with it and you seem to have ideas.
dulapbot: Logged on 2021-09-11 23:58:05 asciilifeform: initial unpublished draft had 'addkey'/'rmkey' but i like the consistency of 'unkey'/'unpeer'/'ungag'/'unaka'
verisimilitude: It's more of an issue on anonymous forums, bingoboingo, where it's much easier to plug a machine in.
verisimilitude: The larger forums are overrun by it.
verisimilitude: Topic is one protection; about the only product one can praise without suspicion is a specialized book, preferably with a dead author.
verisimilitude: Another aspect is treating others as nonhuman until proven otherwise.
verisimilitude: I've a website, with real work, and original work at that; ergo, I'm human, more human than one who builds nothing.
verisimilitude: Storing encrypted messeges in the deduplication buffer is an obvious optimization; I've been thinking about per-peer deduplication buffers, but there doesn't seem to be justification for them.
thimbronion: asciilifeform: encryption question: in updating to the new packet structure, I'm finding that a requirement of the encryption lib is that the packet must be divisible by 16, as 16 bytes is the block size. According to the spec, red packets are 424 bytes, which is not divisible by 16, causing the serpent lib to barf. Is the algo broken or am I missing a step maybe?
verisimilitude: Padding would be the answer, right?
thimbronion: I'm seeing one other anomaly while packing the red packet, but need to investigate further before I can ask anything.
thimbronion: verisimilitude: yes, but then the packet wouldn't be the size specified in the spec
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-12#1057805 << it's no optimization of any kind, if yer storing unauthenticated and undecrypted (i.e. can't see the timestamp yet) enemy can fill you to the ears with replayed material
dulapbot: Logged on 2021-09-12 20:20:15 verisimilitude: Storing encrypted messeges in the deduplication buffer is an obvious optimization; I've been thinking about per-peer deduplication buffers, but there doesn't seem to be justification for them.
dulapbot: Logged on 2021-09-10 14:26:11 asciilifeform: punkman: if you're storing items you have not authenticated -- enemy can fill you
asciilifeform: must. not. store. unauthed. packets. not hard concept imho.
dulapbot: Logged on 2021-09-10 14:28:38 asciilifeform: but not if you can be induced to ~store~ garbage.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-12#1057806 << cipherblock chaining. i suppose i oughta specify it explicitly. (is why the nonce is there.)
dulapbot: Logged on 2021-09-12 20:36:51 thimbronion: asciilifeform: encryption question: in updating to the new packet structure, I'm finding that a requirement of the encryption lib is that the packet must be divisible by 16, as 16 bytes is the block size. According to the spec, red packets are 424 bytes, which is not divisible by 16, causing the serpent lib to barf. Is the algo broken or am I missing a step maybe?
asciilifeform: ( and you pad it. )
dulapbot: Logged on 2021-09-12 20:38:00 thimbronion: verisimilitude: yes, but then the packet wouldn't be the size specified in the spec
asciilifeform: ( the ~message~ is 424 bytes long, but recall that there is also nonce/bounces/version/reserved/command. )
asciilifeform was planning to put worked examples of encrypt/decrypt in 5.2.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-12#1057793 << soo yer not only asking to double (triple? ntuple? in general case) the req'd amt of bandwidth taken up, but also asking receiver to burn a buncha cpu cycles finding the correct alignment?! all to avoid using checksums?
dulapbot: Logged on 2021-09-12 19:50:15 verisimilitude: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-10#1057182 The idea is it uses multiple copies in a way which prevents tampering from reasonably happening, without a hash checksum or whatnot.
asciilifeform: it's arguably the 1 application where hashes can be absolutely relied on.
asciilifeform: (it's a fucking otp soup, there's 0 possibility of constructive manipulation of either body or hash forfuckssake)
asciilifeform: ^ this in re [http://verisimilitudes.net/2021-09-09][[verisimilitude's article], nought to do w/ pest
asciilifeform: ^ this in re verisimilitude's article, nought to do w/ pest
vex: yessir oughtta work
dulapbot: Logged on 2021-09-12 19:32:10 asciilifeform: so far the only solution asciilifeform can think of, is 'pest is not for casualtards who don't have 24/7 fiber. if you don't have at home, get a box in a dc.'
vex: If you can't afford shoelaces, you can't afford shoes
← 2021-09-11 | 2021-09-13 → ↑
Random(asciilifeform) | Download hourly DB snapshot | Get Source Code