asciilifeform: http://logs.bitdash.io/pest/2022-07-30#1010880 << sadly asciilifeform tried & failed to locate this thrd
bitbot[asciilifeform]: Logged on 2022-07-30 14:58:31 phf[awt]: now that i'm asking a quesiton, i feel like i remember you elaborating on it, possibly as a result of my prompt in the past
asciilifeform: http://logs.bitdash.io/pest/2022-07-30#1010876 << notion wasn't that one could somehow get away with ~no~ structure whatsoever, but that e.g. www page oughta be sumthing like a sexpr representing a cl proggy (for a revived lispm naturally), running inside a restricted evaluation envir, rather than a gnarly ball of ???
bitbot[asciilifeform]: Logged on 2022-07-30 14:56:35 phf[awt]: http://logs.nosuchlabs.com/log/asciilifeform/2022-07-30#1112646 << i could never quite grasp the point you're making here. lisp machine will have some kind of datastructure to represent e.g. image, usually involving an nxn array, which then can be dumped onto filesystem as a fasl wit
asciilifeform: i.e. 'no format' is an exaggeration, there's of course a format. but not a bizarre restrictive noose of a format.
asciilifeform tried to illustrate this in e.g. 'peh', attempt to bake a usefully general but just short of turing-complete (i.e. with apriori fixed cpu/memory cost) mechanism
asciilifeform: ( apriori in the sense where sumbody giving you a pubkey and a signature or ciphertext immediately tells you how much cpu/ram will be required to evaluate'em together )
asciilifeform: can have branches; even loops; but if the tape squares run out, or the eval ticks, eggog.
asciilifeform: can't think of any reason wai a www ('replacement') page couldn't have similar mechanics.
bitbot[asciilifeform]: (asciilifeform) 2022-07-26 asciilifeform: signpost: 1 way to think about it, is that when you process a packet, yer 'extending credit' to the sender, giving him a certain # of cpu cycles (and occupying a certain amt of storage while it happens)
asciilifeform is somehow certain that there is a conventional name for this technique; but does not know it (and for that matter not presently aware of any public examples of it other than the linked)
asciilifeform: e.g. bitcoin's 'vm' simply prohibits loops, rather than 'here's max # of ticks you may need for this script'
asciilifeform: http://logs.bitdash.io/pest/2022-07-30#1010881 << this is precisely what yer guaranteed to end up with if the 'solution' is anyffin other than a final solution.
bitbot[asciilifeform]: Logged on 2022-07-30 15:00:33 phf[awt]: and if it's the later, would you not be moving the “format” question from one bucket to another, no long have a png, now have a “webassembly” vs “jvm” or whatever
asciilifeform: 'final solution' is when 'www page' which wants to display a bitmap on the screen, can e.g. (include "072a3ce8c00bb2a5867727ce4d788d5634fdd11a4a01e82239b75bb844dbb081") and fetch png decoder, if not already cached, from pestnet, and compute the req. # of eval ticks from it, + whatever other includes, and the data payload,
asciilifeform: and when this operation is hard-guaranteed to behave precisely as specced (not only 'not overflow and give root to script kid on yer box', but in fact carry out precisely the desired # of cycles and display ~sumthing~)
asciilifeform: http://logs.bitdash.io/pest/2022-07-30#1010879 << 'can' travel in container, if not already known to the local system (see above), was the idea.
bitbot[asciilifeform]: Logged on 2022-07-30 14:57:57 phf[awt]: or is the idea that encoding algorithm should travel in the container?
asciilifeform thinks this is a fairly exhaustive description (if 'easier said than done') but if not , will answer qs.
shinohai[asciilifeform]: $ticker btc usd
busybot[asciilifeform]: Current BTC price in USD: $23707.37
asciilifeform 's station will be down for maintenance later today: moving irons