bomolochus: thimbronion: stock character from greek plays, "buffoon" aha

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.

bomolochus: implement a station in a non-retarded fashion"

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

bomolochus: later asciilifeform

bomolochus: am i nuts or is it a regression to prefer reference implementations over fully specified protocols?

bomolochus: hence mention of username being written to disk will be retained?

bomolochus: again, this is an implementation concern, not protocol concern.

bomolochus: this is a very marginal point though.

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.

bomolochus: moreover what if the drive shits the bed, nsa steals server etc. specify both mechanisms or neither imho.

bomolochus: in the case of pass, your objection maps to "why the fuck would you want an authentication routine that accepts any password?!"

bomolochus: would be coherent with `pass' if simply described as "the exact storage mechanism is unspecified"

bomolochus: but this is not your concern at the spec level; that's the station implementer's concern.

bomolochus: whence this nonvolatile requirement?

bomolochus: is username that pest stations understand being on disk a requirement for a functional xchat connection to it as an irc server?

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

bomolochus: is there some sophisticated meaning to the proper noun usage there shinohai?

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.

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: looks like an implementation detail from here, derivable from spec.

bomolochus: shinohai: hola

bomolochus: epic title work.

bomolochus: here's my favorite: archive.is/bxhNi "large new jersey family"

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?

bomolochus: hola asciilifeform !

bomolochus: i've read the spec, but it deserves a second pass. haven't read all of the logs threads yet, but some.

bomolochus blows dust off finger-macros

bomolochus: will do

bomolochus: fancy, glad to see the continuity

bomolochus: historically ben_vulpes

bomolochus: ah, only grepped spec.