Hide Idle (>14 d.) Chans
← 2021-09-15 | 2021-09-17 → ↓
verisimilitude: It's regrettable I've added little good thought to Pest so far, then. I'll need to consider other optimizations and whatnot.
verisimilitude: Was Usenet not rather ignorant of IP addresses, asciilifeform?
verisimilitude: Bittorrent doesn't seem to much care, either.
scoopbot: New post on A Syndication of Verisimilitudes: A Review of the ``GunPey'' Video Game
punkman: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-15#1058250 << I wonder how much worse it gets on residential or phone internet connections
dulapbot: Logged on 2021-09-15 18:45:56 asciilifeform: punkman: we did a similar udp trial in the #t days, found iirc 0 loss (can't seem to dig out the log ptr tho. if anyone recalls, plox to write in)
punkman: interesting idea "TigerBeetle does double-entry accounting like Newton’s Third Law. For every transfer to an account, there is an equal and opposite transfer from a different account."
punkman: verisimilitude: URL not loading here
punkman: asciilifeform: so I get why packet fragmentation strictly unwanted, and we can't do RSA at line rate. But what if we put, say 1kb, signature *in* message.text, now we have message.text fragmentation, which doesn't create the hole that fragged packets do..
punkman: we kinda already have message.text fragmentation any time we send a text bigger than 320b, and ordering is mostly solved by selfchain
punkman: and with theoretical client support, signing key only needs to be kept at terminal, not station
punkman: flow of messages that can be comfortably read as chat, is much lower than packet rate, I assume RSA (or maybe hash-based signature scheme) can keep up with that
punkman: also after you assemble 4-5 packets into message.txt+sig, you verify sig once, you know it's authentic message from speaker, and then can drop all subsequent packets about same message (after symmetric decryption but before sig verification)
punkman: having pubkey per peer also gives us collision-free speaker identities, and automatic symmetric keying
dulapbot: Logged on 2021-09-16 06:09:10 punkman: asciilifeform: so I get why packet fragmentation strictly unwanted, and we can't do RSA at line rate. But what if we put, say 1kb, signature *in* message.text, now we have message.text fragmentation, which doesn't create the hole that fragged packets do..
asciilifeform: what THE FUCK???
asciilifeform: let's have the complexity and slowness of rsa, PLUS the all-to-all symmetric key exchange chore ???
asciilifeform: DAFUQ, WHY????
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-16#1058324 << and when i want the thing to be a general-purpose routing fabric for warez ??
dulapbot: Logged on 2021-09-16 06:23:40 punkman: flow of messages that can be comfortably read as chat, is much lower than packet rate, I assume RSA (or maybe hash-based signature scheme) can keep up with that
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-16#1058326 << it only does if EVERY PACKET IS SIGNED AND VERIFIED AT LINE RATE omfg
dulapbot: Logged on 2021-09-16 06:29:31 punkman: having pubkey per peer also gives us collision-free speaker identities, and automatic symmetric keying
asciilifeform: observe that absolutely nothing prevents you from pasting a pgpgram into yer console if you want to.
asciilifeform: the kind that people verify manually, at their leisure.
asciilifeform: otoh a chat proggy where simply ~displaying~ a line takes A FULL SECOND is fucking ridiculous.
asciilifeform: (not to mention that ~sending~ would, similarly)
asciilifeform: aaaand this'd be ~in addition~ to the key-for-every-pairing-of-peers chore !
asciilifeform utterly mind-boggled at the 'kind of confusion of ideas which could lead to such a thought'
punkman: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-16#1058334 speaker-identity becomes separate from station-identity
dulapbot: Logged on 2021-09-16 09:39:50 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-16#1058326 << it only does if EVERY PACKET IS SIGNED AND VERIFIED AT LINE RATE omfg
punkman: but yes 1 second delays would be annoying
punkman: was more thinking of construction of "SignedChat" "on top", not required for base protocol
punkman: possibly interesting ACK model https://github.com/lithdew/reliable
asciilifeform: punkman: i can't think of very many uses for a signed chat where the signing doesn't help against the gnarliest problems of 'is this genuine packet? should i flood it to peers?' etc
asciilifeform: but if someone can -- then implement, why not
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-16#1058346 << what was interesting there? seems on 1st pass like an ad-hoc variant of tcp
dulapbot: Logged on 2021-09-16 10:39:50 punkman: possibly interesting ACK model https://github.com/lithdew/reliable
dulapbot: Logged on 2021-09-16 04:06:57 verisimilitude: This amused me: https://geneva.cs.umd.edu/posts/usenix21-weaponizing-censors
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-16#1058316 << lulzy: 'Excludes any kind of security issue, for example, the possibility for a "man-in-the-middle" or a distributed denial of service attack, because this is a consensus bug bounty challenge not a security bug bounty program.'
dulapbot: Logged on 2021-09-16 03:49:46 punkman: https://www.tigerbeetle.com/20k-challenge
asciilifeform: 'Any potential correctness bug that is nevertheless detected by TigerBeetle through an assertion that results only in a crash is explicitly out of scope for a correctness bug, and may be considered as a liveness bug only.'
asciilifeform: hilarious academi-shitware aesthetic. a++.
punkman: asciilifeform: idea as I took it, could we bundle ACKs for received packet, in other packet we are sending anyway, instead of dedicated ACK packet
asciilifeform: punkman: imho acks entirely not needed when we have getdata
asciilifeform: selfchain/netchain effectively ~is~ 'ack bundled in packet we're sending anyway', if you think about it
punkman: yeah, getdata being "inverse" ACK, >I did not receive this, plz resend
punkman: although in direct message, you can't getdata for lost message, unless you get a later message, telling you lost packet's hash
amberglint: Hello everyone
amberglint: asciilifeform: I wanted to alert you to this: https://twitter.com/swmckay/status/1438313135585247234
amberglint: Hopefully he will send the docs to Bitsavers to scan and post
amberglint: It took me a while to find a way here
amberglint: The Contact link on loper-os.org still points to defunct Freenode
asciilifeform: wb amberglint !
asciilifeform would update the contact, but doesn't currently have a ready www-based widget for dulapnet
asciilifeform: punkman: will take a look, ty
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-16#1058363 << hm, so far nuffin there, just somebody 'i found some docs...'
dulapbot: Logged on 2021-09-16 11:38:07 amberglint: asciilifeform: I wanted to alert you to this: https://twitter.com/swmckay/status/1438313135585247234
asciilifeform: bomolochus: wb
bomolochus: hola asciilifeform !
bomolochus: on an entirely non-techincal topic, isn't it a wonder how the usg press organs will gladly regurgitate "died of covid! and you unvaccinated sinners did it!" and repeatedly refuse to mention any comorbidities evident to the naked eye in the inevitably embedded slideshows?
asciilifeform: bomolochus: almost 2y old continuous lulz.
bomolochus: here's my favorite: archive.is/bxhNi "large new jersey family"
billymg: bomolochus: lol "large" indeed
bomolochus: epic title work.
dulapbot: (trilema) 2015-09-16 asciilifeform: i suspect that ~this~ magical apogee is not reached until you get to 'too big for the crematorium' max level.
shinohai tips hat to bomolochus
asciilifeform: wb shinohai
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-16#1058369 << thinking about this, asciilifeform aint sure that he wants 1-click luser access to dulapnet. the current 'this tall to ride' seems just about perfect imho.
dulapbot: Logged on 2021-09-16 12:00:57 punkman: asciilifeform: https://kiwiirc.com/embedding
shinohai: ty asciilifeform ... Summer travels soon to come to end, perhaps can catch up on "Pest" discussion.
bomolochus: shinohai: hola
asciilifeform: shinohai: looking fwd to your comments
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-16#1058361 << asciilifeform did not specify the frequency with which 'ignore' is issued; but expects that it will happen at least erry coupla min. and as soon as it does, the receiver learns of the gap and getdata's to fill it, neh
dulapbot: Logged on 2021-09-16 11:23:04 punkman: although in direct message, you can't getdata for lost message, unless you get a later message, telling you lost packet's hash
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-16#1058313 << rather interesting. asciilifeform somehow escaped ever having seen this tetrisism.
dulapbot: Logged on 2021-09-16 00:50:53 scoopbot: New post on A Syndication of Verisimilitudes: A Review of the ``GunPey'' Video Game
asciilifeform thought that he had seen all major variants, turns out -- not
asciilifeform updated the 'contact' link on his www to a log ptr to the orig. dulapnet announcement. will leave it at this for nao.
shinohai: btw I abandoned #therealbitcoin chan on fleanode when they did the forced sslism thing, so dunno if jurov wants to keep it going or abandon when he resurfaces.
asciilifeform: shinohai: asciilifeform was unable to connect to whatever the fuck remained of fleanode even w/ sslism
asciilifeform: afaik it's dead.
asciilifeform: as far as asciilifeform's concerned, until can replace it & the rest w/ pest nets, #a will serve as the interim replacement for #trb as well.
asciilifeform: of course if jurov wants to stand up own 'dulapnet' (could even do so on the iron i supply him with pro bono!) i'll join there .
asciilifeform: under no circumstances however will asciilifeform participate in the reich's replacement-fleanodes or any such thing.
dulapbot: Logged on 2021-06-16 13:48:01 shinohai: "muh Swedish lawz"
asciilifeform: !q uptime
dulapbot: asciilifeform: time since my last reconnect : 92d 14h 28m
shinohai: The only thing *any* of those faux-fleanodes, twitters, et all are good for is trolling. Yours truly has always had a penchant for it, can't help himself.
shinohai: $uptime
busybot: The bot has been up for: 56 days 21 hours 15 minutes and 12 seconds
asciilifeform: shinohai: i hear the latest coup lured away ~100% of the 'mainstream' opensores cruft -- gcc, kernel, etc chans
asciilifeform: simply stating for the record that asciilifeform doesn't give a fuck, and will happily do without ever speaking with any such people again, if it means to also be free of fleanodism in all of its manifestations.
shinohai: It did, the lisp chan went over there too sadly, I actually sometimes *did* learn a thing or three from that chan.
asciilifeform: erry visit by asciilifeform to a heathen irc chan ended in just about identical barf. so not missing'em at all.
asciilifeform intends to eventually replace dulapnet server with a 'guest door' into his pest net.
asciilifeform: come to think of it, oughta define the concept in 0xFD. 'guest door' is similar to a standard console except that it cannot execute control commands; starts pre-'joined'; and forces e.g. 'guest_' prepended to a user's chosen (via NICK) handle.
asciilifeform still not sure that this belongs in the protocol spec per se; possibly oughta be an external proggy, with some kinda filtration (how do you kick out a spammer w/out closing the guest door entirely?)
bomolochus: looks like an implementation detail from here, derivable from spec.
bomolochus: what derives from spec would actually just be the heresay messages; if asciilifeform wanted to have a station where allcomers could send messages to his primary station that would be a decently beefy bit of work that i don't think is pertinent to the spec.
bomolochus: and hm, upon 3rd? 4th? reread of spec, i don't know that the implementation details of auth behind 2.5.2 `user` command is so appropriate; 'promisetronic' in ourgot.
shinohai: I must say bomolochus I'm digging your new handle you Malaka you.
bomolochus: is there some sophisticated meaning to the proper noun usage there shinohai?
asciilifeform: bomolochus: the reason why 2.5.2 reads: '... This is a password, or a derivative thereof; the exact authentication mechanism is unspecified.' is rather simple :
asciilifeform: bomolochus: standard irc (per the rfc) does not even specify a salted hash pw , but simply plaintext pw
asciilifeform: imho this is unacceptable for any but station-and-irc-client-on-single-machine setup
asciilifeform: (and even in the latter, questionable -- through elementary misconfig the thing can end up exposed to world)
asciilifeform: some irc clients permit extensions to the login mechanism (e.g. fleanode's variant) and salted hashes etc. and so asciilifeform wrote 'unspecified'.
dulapbot: Logged on 2021-09-16 15:50:20 bomolochus: is there some sophisticated meaning to the proper noun usage there shinohai?
bomolochus: i am perhaps thick, but i do not see how specifying where usernames are encoded in implementing clients is particularly germane to the box-to-box protocol
asciilifeform: bomolochus: the thing's of 0 use without specified user i/o. per my spec this is deliberately -- at minimum -- something that e.g. 'irssi' or 'xchat' will talk to without modification.
asciilifeform: nor will i tolerate an item incompatible with my www logotron.
bomolochus: is username that pest stations understand being on disk a requirement for a functional xchat connection to it as an irc server?
asciilifeform: bomolochus: how do you imagine an irc-compatible i/o without a username/pw ?
asciilifeform: stored nonvolatilely
bomolochus: whence this nonvolatile requirement?
asciilifeform: bomolochus: why the fuck would you want the login creds for the console to evaporate if the box loses mains ?
bomolochus: but this is not your concern at the spec level; that's the station implementer's concern.
bomolochus: would be coherent with `pass' if simply described as "the exact storage mechanism is unspecified"
asciilifeform: bomolochus: the way asciilifeform sees it, some items (i.e. per-peer packet counters) may be volatile; others -- may not. specified which may not.
bomolochus: in the case of pass, your objection maps to "why the fuck would you want an authentication routine that accepts any password?!"
asciilifeform: this is important esp. in a protocol with rekeys, where in fact you lose your peerings if you lose storage. and cannot be backed up meaningfully.
asciilifeform: bomolochus: indeed
bomolochus: moreover what if the drive shits the bed, nsa steals server etc. specify both mechanisms or neither imho.
asciilifeform: if the drive is stolen, drowned, or burns down, you gotta rebuild your peerings.
asciilifeform: via same out of band means that you built'em to begin with.
asciilifeform: i don't see any way around this.
bomolochus: a shitty station implementation that sucks to work with is just a shitty station implementation that sucks to work with. network will have no idea about handle storage or auth mechanism implementations; ergo promisetronic and not worth including in spec.
asciilifeform: the Right Thing, i suspect, would be a synchronization mechanism so that one could have two identical stations working in lockstep. if one goes down, immediate rekey on the other, and you carry on as before.
bomolochus: this is a very marginal point though.
bomolochus: again, this is an implementation concern, not protocol concern.
asciilifeform: bomolochus: you have a point in that the spec introduces self as 'for protocol', but specifies instead a basic program in in its entirety. it was the latter, however, that was asciilifeform's intent.
asciilifeform: a pure-protocol spec can be baked after one implementation actually exists.
asciilifeform: returning to the irc console -- no fucking way is asciilifeform putting his signature knowingly on a submarine-with-screen-door.
asciilifeform: hence mention of password will be retained.
asciilifeform bbl shortly
bomolochus: hence mention of username being written to disk will be retained?
bomolochus: am i nuts or is it a regression to prefer reference implementations over fully specified protocols?
bomolochus: later asciilifeform
punkman: bomolochus: it does usually goe like this, draft spec -> prototype -> better spec -> reference implementation
asciilifeform: bomolochus: i'm still trying to picture a justification for not having irc console username in nonvolatile storage, and cannot
asciilifeform: bomolochus: is your contention that this is 'obvious' and therefore not worth to write down ? or what, precisely ?
asciilifeform: because imho it aint obvious. and a heathen would 100% permit credentialless logins to console, and think nothing of it.
asciilifeform: whereas asciilifeform wants to explicitly proclaim any such thing, and anything adjacent to such a thing, to be an act of the mentally retarded that he'll have nothing whatsoever voluntarily to do with.
asciilifeform: the console, recall, aint simply for talking. it's essentially a root shell , in so far as the station is concerned.
asciilifeform: can add, delete peers, issue SCRAM and wipe 100% of own storage.
asciilifeform: in fact explicitly strongly recommended that console and client reside in one physical machine. USER/PASS is simply a last-ditch protection against an inadvertently -- even for 5sec -- world-connectable console port.
asciilifeform: exactly, btw, like the rpc 'password' in trb.
asciilifeform: serves precisely same purpose.
asciilifeform: and the fact that i am having to explain it now, imho proves that it aint obvious. and ergo belongs in the spec.
asciilifeform obviously cannot prevent stupid and malicious people from writing implementations nominally conformant to asciilifeform's spec but perverting its intent. but can attempt to make it difficult to do so 'while obviously conforming'
asciilifeform: 'postelism' makes that kind of slimy jesuitry unnecessarily easy. and i have no intention of making it easy.
dulapbot: Logged on 2021-09-07 09:31:31 asciilifeform: NOT eager to incorporate 'all of irc' idjit postelism into this item -- presently it is SIMPLER than irc in fact, considerably, and asciilifeform likes it that way
dulapbot: (trilema) 2018-02-02 asciilifeform: the 'postel's law' nonsense, of silently forgiving people who send liquishit at the dusty disused corners of the protocol, enabling there to even ~be~ such a thing as dusty corners in a protocol!, MUST die.
scoopbot: New post on Blog of Peter Lambert: The Sportsman's Antics
shinohai: $ticker btc usd
busybot: Current BTC price in USD: $47784.26
shinohai: $ticker eth usd
busybot: Current ETH price in USD: $3572.81
bomolochus: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-16#1058458 << oh quit maliciously misrepresenting me. if you're talking about station implementation, write a complete station design and don't leave out the authentication scheme while you're at it. what you have here is "here's the protocol spec, and while i was at it here are some incomplete design notes on how to
dulapbot: Logged on 2021-09-16 16:46:01 asciilifeform: bomolochus: i'm still trying to picture a justification for not having irc console username in nonvolatile storage, and cannot
bomolochus: implement a station in a non-retarded fashion"
bomolochus: i'm not trying to talk you into putting wifi onto a cardano ffs or even that the design element as written isn't necessary; merely that as written it's inconsistent with the other design rules for a station, like the authentication scheme being null. regardless this is a very shallow and low-value point for me to distract you with.
asciilifeform: bomolochus: wasn't trying to troll you at all, i swear
asciilifeform: bomolochus: if your point was this -- imho is perfectly fair. and i'm a++ in favour of baking a smaller, 100% narrowly protocolic spec later.
dulapbot: Logged on 2021-09-16 16:09:34 asciilifeform: bomolochus: you have a point in that the spec introduces self as 'for protocol', but specifies instead a basic program in in its entirety. it was the latter, however, that was asciilifeform's intent.
asciilifeform: (after a proper example proggy exists.)
asciilifeform: bomolochus: i admit i don't see where inconsistent. plz don't hesitate to point out concretely (where for instance is 'the authentication scheme being null' ? or do i misread?)
asciilifeform: bomolochus: fwiw the original target audience for the spec was thimbronion , who in fact took the trouble to write the proggy and seems to have most of it already (even while he was waiting for spec)
asciilifeform: this is why does not read like a classical rfc, but more of a pseudocode description of whole proggy.
asciilifeform will bbl
← 2021-09-15 | 2021-09-17 → ↑
Random(asciilifeform) | Download hourly DB snapshot | Get Source Code