Show Idle (>14 d.) Chans
← 2022-12-27 | 2022-12-29 → ↓
phf[asciilifeform]: so as far as i understand luby is p2p, and exists essentially on same level as dm. what about something like broadcast inline stuff? like e.g. if you waant to send funny picture of cat, and have it appear inline in logs?
phf[asciilifeform]: on telegram instead of linking to youtube videos, i usually download video with youtubedown or similar, and then send video inline. this way there's no traffic sent to goog, videos stay uncancelable, and it's generally a better experience for everyone involved.
asciilifeform: phf: simplest thing may be to do what the heathens do and base64 the cat into a multipart (+ some marker magick to show wtf it is, so it not gets printed as text )
asciilifeform: for that matter, a la ye olde alt.binaries.*
asciilifeform: per current draft spec you can stuff up to 18,874,080 byte in there.
asciilifeform still ambivalent re: whether this was a good idea; theoretically could make for rapid log db bloat. most folx wouldn't send 18MB of text spamola, but 1 cat can easily do same
asciilifeform: and it'll sit 4evah on disk
asciilifeform: imho would be much better to do the clever thing re luby fileshares instead, i.e. where they can propagate somehow
phf[asciilifeform]: why not custom message type, that is equivalent to multipart broadcast, but lets you pack arbitrary binary, with perhaps filename/filetype in the first packet? seems kind of silly to uuencode, when you have control over the underlying packing mechanism
phf[asciilifeform]: can also not store messages of that type in database, by e.g. unpacking them to fs and just keeping the meta, or discarding them in the long term entirely
phf[asciilifeform]: i guess you're trying to make whatever's in log part of a coherent netchain/selfchain, so main question with inline binary: does it appear inline with other messages. so if i have a chain A B* C* D* E, a and e are text messages, but b c d are binary-multipart
phf[asciilifeform]: but can also have something like a marker packet A F** E, where marker packet caries meta for file and also hash for its own subthread F->D->C->B
asciilifeform: phf: the reason wainot 'binary chained msgs' is this -- still not sure whether parking binariolade in the chain is good idea at all
bitbot[asciilifeform]: Logged on 2022-12-28 11:02:00 asciilifeform[jonsykkel|awt|deedbot]: still ambivalent re: whether this was a good idea; theoretically could make for rapid log db bloat. most folx wouldn't send 18MB of text spamola, but 1 cat can easily do same
asciilifeform: it's expensive, in the 'blockchain' sense. send a lolcat? nao erry new station has to sit for whoknows how long fetching rest of chain + that lolcat
asciilifeform: and store it on disk for the next fella, etc
asciilifeform: for that matter, the max multipart counter prolly oughta be e.g. 255, rather than 65535
asciilifeform: lolcats really oughta travel e.g. a-lubystream->b-lubystream->c etc. after c->gimmebinwithhash->b-gimmebinwithhash->a
asciilifeform: that way folx aint stuck storing'em 4evah, new stations forced to load whole cat simply to get at what sat before it in the chain, and so on
asciilifeform: phf: picture what the #t logs would weigh if all of mp's 'lolcats' ~had~ to live inside it as bins
asciilifeform: (or couldn't load it at all)
asciilifeform: this was why, in draft spec, asciilifeform defined 'binary msgs are always direct'
asciilifeform aint certain precisely how to 'solve lolcat problem' but is quite sure of 'how not to'
phf[asciilifeform]: i dunno, sounds like asciilifeformism :> `can't solve this problem in elegant way, therefore will punt on it entirely
asciilifeform: phf: imho propagating request for bin-with-$hash to peers, and if 1 of'em has the thing in cache, you get a lubystream -- is the rough solution
asciilifeform: 'devil in details' tho.
asciilifeform: * 1 or moar
asciilifeform: iirc signpost had the beginnings of an algo , in 'napkin stage'.
asciilifeform: ftr here's anuther, entirely different, 'inelegant solution' -- binary multipart msgs, but erry single one has to carry nethash/selfhash of the immed. preceding text msg., so that stations are able to 'skip' it when walking back the chain.
phf[asciilifeform]: sidestreams and ephemera, can e.g. put meta in the log, here should be elephant.png image/png 1234bytes f13d… hash, and then separate mechanism for `can has file with hash f13d…` or even spam along with meta packet `oh by the way here's all the data you need for the meta i just sent`
asciilifeform: phf: right, as asciilifeform understands this was general idea in signpost's algo
shinohai[busybot]: R.I.P. Ted Kaczynski I'm hearing ?
asciilifeform: shinohai: source ?
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-28#1019530 << this is precisely what i picture, and it's highly disappointing that a signifcant portion of log is useless, on account of binary blobs and pastes expiring
bitbot[asciilifeform]: Logged on 2022-12-28 12:09:23 asciilifeform[jonsykkel|deedbot|awt]: phf: picture what the #t logs would weigh if all of mp's 'lolcats' ~had~ to live inside it as bins
asciilifeform: phf: imho the clean solution is still 'file share' with cache, and a handy way to link to items in same from text msgs; rather than parking the cats in the chain proper
phf[asciilifeform]: the situation was understandable when it was irc, and still we were trying to make mechanisms around it. now own protocol, but the attitude is `eh, it'll be solved somehow`
shinohai[asciilifeform]: nah appears to be 'nother chan-hoax
asciilifeform: shinohai: lolk
asciilifeform: phf: there are several possib. solutions, i expect we'll pick 1 (and not necessarily of the above). simply imho oughta think before baking it in and potentially 'oh hey n00b? go and request, 1 packet at a time, log that weights 10TB, then come back'
asciilifeform: i.e. 'the trb situation'
signpost[asciilifeform] put some cycles into the python version of the fountain code impl over the past few days, will post a new vpatch
signpost[asciilifeform]: added demonstrator commands "squirt" and "slurp", and lib's going to be called squirt.
signpost[asciilifeform]: going to see about going ahead today and doing the multiprocessing port I disavowed in my last blog post
signpost[asciilifeform]: http://logs.bitdash.io/pest/2022-12-28#1019544 << two questions which should be answered independently. one's whether media blocks are part of the chain. two's how to efficiently, fault-tolerantly, etc., create broad availability of big binwads.
signpost[asciilifeform] has been focused for some time on the problem of latter.
bitbot[asciilifeform]: Logged on 2022-12-28 12:17:31 phf[awt]: http://logs.bitdash.io/pest/2022-12-28#1019530 << this is precisely what i picture, and it's highly disappointing that a signifcant portion of log is useless, on account of binary blobs and pastes expiring
signpost[asciilifeform]: http://logs.bitdash.io/pest/2022-12-28#1019523 << I agree that it's not clear why non-text content types are special and outside the chain. not that it's obvious they should be part of the chain, but there's not a hard principle here atm.
bitbot[asciilifeform]: Logged on 2022-12-28 12:04:45 asciilifeform[5]: phf: the reason wainot 'binary chained msgs' is this -- still not sure whether parking binariolade in the chain is good idea at all
asciilifeform: signpost: simply on acct of their mass. 'quantity has a quality of its own'(tm)
asciilifeform: would like to avoid trb-style 'buy a new hdd and come back in 3 months' ugh
signpost[asciilifeform]: 100% agree. there are a few alternatives there. one would be that a reference message type be born (also useful for linking to text logs) with a content type of the referenced material.
signpost[asciilifeform]: perhaps binary media is a "subthread" chain, and my lightweight client with only 2gb of flash can ignore all non-text links.
asciilifeform: signpost: for chained msgs, asciilifeform intended 'netchain' for 'link to log line being replied to'
signpost[asciilifeform]: the threading mechanism gives ya "episodes of series" etc
asciilifeform: ( the current paste-link-to-logotron thing is 'not from a good life', from the forced linearity of irc )
signpost[asciilifeform]: right, so the first alternative is that binary media is part of the chain, but it's part of netchains which are marked such that you can choose to ignore them
signpost[asciilifeform]: or retrieve on demand
signpost[asciilifeform]: the m-of-n mechanism is already there, so this might be plenty. just ignore all m-of-n chains longer than $foo, for $foo set in station knobs.
asciilifeform: signpost: as currently specified, the multiparts still end up extending speaker's selfchain tho
signpost[asciilifeform]: second option looks like was already discussed. there's a media reference message type born, and we operate caches with expiry rules (or infinite) as we choose
signpost[asciilifeform]: asciilifeform: ah right. I have the spec up alongside, refilling brain-cache
asciilifeform: ( skipping anyffin on the chain is nontrivial -- for 1 thing, broadcasts go to erryone; for anuther -- there are no forward links, only backward )
signpost[asciilifeform]: http://logs.bitdash.io/pest/2022-12-28#1019512 << thing is there's an oligarch's fat sack of cash (if not a government) operating "infinite" free storage for telegram eh?
bitbot[asciilifeform]: Logged on 2022-12-28 10:47:42 phf[awt]: on telegram instead of linking to youtube videos, i usually download video with youtubedown or similar, and then send video inline. this way there's no traffic sent to goog, videos stay uncancelable, and it's generally a better experience for everyone involved.
signpost[asciilifeform]: but I agree the experience is doing what you want here. somebody needs to be able to livestream a j6 on it.
signpost[asciilifeform] fwiw favors the binwad cache with operator set TTL and to keep the pest chain tidy and human sized, but am by no means certain that's right.
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-28#1019564 << i get a feeling ascilifeform is not quite liking this approach without necessarily coming out in opposition of it explicitly
bitbot[asciilifeform]: Logged on 2022-12-28 12:54:56 signpost: perhaps binary media is a "subthread" chain, and my lightweight client with only 2gb of flash can ignore all non-text links.
asciilifeform: phf: not liking because not obvious how possible to skip nominally-optional sections of chain when getdata'ing backwards (as links only point backwards)
asciilifeform: that, and the fact that broadcasts hit erryone, consuming bw, whether the recipient 'wants' that msg or not
asciilifeform: it is very similar to trb block push problem, where a node is bombarded constantly by purposed 'latest' blocks, whether has a use for'em yet or not
asciilifeform: *proposed
signpost[asciilifeform] can also see how something which points the other way invites one's peers to hunt endlessly for the referenced item, potentially to no avail, with nothing hard to end the search.
signpost[asciilifeform]: will think moar with caches fuller
asciilifeform: pest is a 'push protocol', and if we want heavy things carried in it, oughta exempt'em from 'always push' 1 way or anuther
asciilifeform: otherwise bw nightmare.
phf[asciilifeform]: valid points
phf[asciilifeform]: i guess there's a question of useful distinction between an inline nudes, and a 600mb `filthy moms volume 11`
phf[asciilifeform]: because an inline lolcat you'll probably set to some kind of `always download` mode, instead of `click to download` mode, and then everyone starts paying the tradeoff overheads
phf: ftr this issue is solved by reich-technology, telegram specifically is imho state of the art when it comes to personal messenger usability
phf[busybot]: the utility of little-known feature on btcbase is significantly reduced because linkrot, http://btcbase.org/log-search?q=from%3Atrinque+jpg&inline=true
awt[asciilifeform]: The problem was annoying enough for me personally to put some effort into an archiving indexer.
signpost[asciilifeform]: phf: damn, this is nice aside the bitrot.
signpost[asciilifeform]: awt: how much of the log did you end up getting archived?
signpost[asciilifeform]: would be great to at some point reassemble what can be.
signpost[asciilifeform]: and I married and knocked her up. life is better lived with logs.
awt[asciilifeform]: signpost: I recall that eventually I was able to index the entire log up to sometime in 2020. Obvs by that point there were many broken links.
awt[asciilifeform]: Caveat - archives were text only and stored in a pg table.
phf[asciilifeform]: so what was in archives? contents of page links?
asciilifeform: http://logs.bitdash.io/pest/2022-12-28#1019592 << by 'reich tech' simply meant 'errything on central server' (trivially over9000x easier to write an aol messenger than p2p, noshit) or something moar specific ?
bitbot[asciilifeform]: Logged on 2022-12-28 14:51:01 phf[4]: ftr this issue is solved by reich-technology, telegram specifically is imho state of the art when it comes to personal messenger usability
asciilifeform not used telegram, but used e.g. slack, which in this sense is 'an aol messenger'. or does telegram include elements of p2pism, as e.g. skype once did ?
phf[asciilifeform]: asciilifeform slays windmills he himself erects, news at 11! the comment was re specifically this issue http://logs.bitdash.io/pest/2022-12-28#1019591
bitbot[asciilifeform]: Logged on 2022-12-28 14:35:20 phf[awt]: because an inline lolcat you'll probably set to some kind of `always download` mode, instead of `click to download` mode, and then everyone starts paying the tradeoff overheads
phf[asciilifeform]: that is to say that you don't have one kind of downloadable material. inline lolcat is different from inline funny picture is different from inline paste is different from 4GB criterion collection copy of Aguirre, the wrath of god.
phf[asciilifeform]: if i for example paste a png of a graph of pest network behavior and then there's a lively conversation about the contents of the graph, that graph is inherently part of log.
asciilifeform: what asciilifeform meant was , presumably telegram aint trying to store all material in a singly-linked list of chunks are flood-routed when emitted 1 at a time, and then sit on erry user's hdd 4evah
asciilifeform: and yes imho phf is right, 'that graph oughta be part of the log'. the q is whether there's a moar efficient way to do this than actually storing it in the chain as if were text
asciilifeform: ( as in e.g. signpost's idea, where in-chain it's a lolcat-hash, and there's some parallel mechanism for retrieving it )
asciilifeform: or, to rephrase: a) signpost oughta be able to throw a linux iso on pestnet b) this should not make the log db suddenly += 3GB, and new stations having to suck in that 3GB before they can even see the immed.preceding text msgs
phf[asciilifeform]: maybe then that should be an operator choice?
asciilifeform: fwiw 'include a pointer to preceding, so skippable' doesn't actually solve; suppose all yer peers skipped it. how do you propagate a request for it to l2+ (incl. originator) who have it?
phf[asciilifeform]: because 3gb iso is self-evidently an attachment, but a graph that's driving a conversation is self-evidently part of log. you're either optimizing for size of log, or for arbitrary holes
asciilifeform with phf in re 'should be able to put graph in the log', hence wai defined 18MB multipartism. but suspects that it will make for serious pain if actually used this way regularly
phf[asciilifeform]: i guess there's two types of attachments in general, those that are inline with conversations, and those that are download links into some secondary mechanism
phf[asciilifeform]: we have a self-evident solution for the later, a special message type that gives you a hash, that you can use to query into a download mechanism. give me all parts of `a3f3dd356…` file
asciilifeform: asciilifeform's notion is that if the secondary mechanism is well-conceived, then anyffin bigger than a hand-typed chat msg oughta ride on it
asciilifeform: the tricky bit , as asciilifeform understands it, re 'request hash, maybe someone on net has the bin that it was hash(bin) of' is that it inescapably introduces an element of 'onionism' --
asciilifeform: ... you can't directly talk to an l2+ peer
asciilifeform: peer^H^H^H^Hstation that is
asciilifeform: the request would have to be broadcast, and the response (a possibly heavy bin) would have to travel somehow other than via flood (or there's no point in the hack, may as well sit it down in the chain for all the bw it'd save)
asciilifeform: ( as #1 axiom of pestronics is that 'station only directly talks to operator-defined peers' )
asciilifeform: imho an acceptable solution is 'if no one in l1 has bin with $hash, you suck yer thumb'
asciilifeform: i.e. no bin auto-propagation beyond 1 level.
asciilifeform: possibly, operators could optionally enable 'propagate warez request' if they have disk/bw to spare. then : this.
bitbot[asciilifeform]: Logged on 2022-12-28 12:07:44 asciilifeform[jonsykkel|deedbot|awt]: lolcats really oughta travel e.g. a-lubystream->b-lubystream->c etc. after c->gimmebinwithhash->b-gimmebinwithhash->a
phf: right, this notion of yours is the core of the dispute. we're on the same page that gb isos and movies and such should be attachments, but i believe there needs to be a mechanism to inline a resource at the discretion of the operator
phf: bump
phf[asciilifeform]: hmm, my packets are being lost in the aether :/
asciilifeform[busybot] must bbl for a spell
phf: 􏿽http://logs.bitdash.io/pest/2022-12-28#1019629 << that basically means that for things like inline graphs, or lolcats one is disincentivized from using pest. if i posted a funny, and everyone laughed, i want to be able to come back 3 years later and reminisce, rather than discover
bitbot[busybot]: Logged on 2022-12-28 16:33:20 asciilifeform[5]: imho an acceptable solution is 'if no one in l1 has bin with $hash, you suck yer thumb'
phf: 􏿽that there's a hole, because everyone's warez knobs are set to 2 years.
asciilifeform: wb unpx
asciilifeform: phf: is entirely valid point, difficult to disagree. q is 'wat do'
asciilifeform fwiw 'solves' above with 'jpgs sit down on his www /pub, and sit for arbitrary yrs'. but this aint a general solution.
bitbot[asciilifeform]: Logged on 2022-12-28 16:45:37 phf[awt]: 􏿽that there's a hole, because everyone's warez knobs are set to 2 years.
signpost[asciilifeform]: I would store just about anything indefinitely from l1. much less inclined to as one proceeds outward.
signpost[asciilifeform]: seems well-mapped to the social expectations too. your friends remember you best.
signpost[asciilifeform]: and they're the best folks to ask "do you remember so-and-so" when you're gone
signpost[asciilifeform]: perfectly good answer to ^ is "who the fuck are you, again?" too, depending on who asks.
phf[asciilifeform]: i think that's only an acceptable solution for warez, but not for essential elements of log
phf[asciilifeform]: hey, i'm not in your wot, but i'm reading log from 2014 and somebody posted a funny image, and everybody's laughing. you still have a copy of that image? said nobody ever
signpost[asciilifeform]: how are you reading it?
signpost[asciilifeform]: if you are not in my wot, or somebody else's.
phf[asciilifeform]: log is broadcast, doesn't need to be in l1
signpost[asciilifeform]: maybe with a better definition of this "essential" it's clearer.
signpost[asciilifeform]: absent that my inclination is to let subjective matters like what's essential be a matter of operator control
signpost[asciilifeform]: pics are at least bounded items. videos might not be
bitbot[asciilifeform]: Logged on 2022-12-28 16:18:51 phf[awt]: maybe then that should be an operator choice?
phf[asciilifeform]: the thinking here is that leaning towards operator choice makes sense, because the network is so wot heavy
signpost[asciilifeform] has no problem with there being "inline" items of some reasonable titpic size
signpost[asciilifeform]: and yeah, what I'd allow inline I'd potentially adjust upward for more trusted parties.
asciilifeform: signpost: problem is that ~anyone~ on a pestnet (of arbitrary depth) can stuff inline up to whatever the max multipart is (per draft 0xfa -- ~18MB)
asciilifeform: ( this, obv., per the 'stuff jpg in chained msgs' scheme )
asciilifeform: and then, if getdataing to get the history, gotta walk through that 18MB
phf[asciilifeform]: but isn't it the same kind of problem as, anyone in pestnet can spam viagra ads, or talk in all caps about random nonsense?
asciilifeform: phf: entirely similar. except that most folx wouldn't send 18MB of txt spamola, whereas typically people think nuffin of throwing in a 18MB cat
signpost[asciilifeform]: there's no damnatio memoriae currently specified is there?
signpost[asciilifeform]: data from some dork would still be there as part of the chain after his unpeering
signpost[asciilifeform|phf]: if one wanted a fully walkable chain, have to have this
asciilifeform[phf]: signpost: nope. chain is the archaetypical 'spittoon in 1 strand'
asciilifeform: sorta like trb is stuck storing erry piece o'shit tx 4evah.
signpost[asciilifeform]: squinting they're the same problem. you either have ways of gc'ing parts of the log-chain you don't care about, or you stick the parts you may not care about in a side-storage where you same.
asciilifeform: imho the essence of the 'how to lolcat on pest' q can be restated as 'how to send ~optional~ wad of msgs'
phf: http://logs.bitdash.io/pest/2022-12-28#1019675<<you keep bringing this up as an example, but trb is quintessential `all comers`. why have wot, if you're then not going to rely on itts communal properties?
bitbot[phf]: Logged on 2022-12-28 18:22:42 asciilifeform[5]: sorta like trb is stuck storing erry piece o'shit tx 4evah.
signpost[phf]: of these I'd be inclined to speculate in the direction of not having to pull down every single link of all possible chain walks
signpost[busybot]: asciilifeform: yep exactly
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-28#1019677 << bui don't agree with restatement, i'm explicitly arguing that there are binary blobs that are essential parts of log
bitbot[asciilifeform]: Logged on 2022-12-28 18:23:41 asciilifeform[6]: imho the essence of the 'how to lolcat on pest' q can be restated as 'how to send ~optional~ wad of msgs'
asciilifeform: phf: i'm inclined to agree, i.e. 'let's have jpgs in chain, but Use Moderately' but plagued by suspicion that even very light use of it will be very painfully heavy for even a small pestnet with well-behaved inhabitants
signpost[asciilifeform]: not a bad thing to have this problem and then do something smarter.
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-28#1019684 << that's a fair point. just how expensive is this Use Moderately end up in practice
bitbot[asciilifeform]: Logged on 2022-12-28 18:25:46 asciilifeform[6]: phf: i'm inclined to agree, i.e. 'let's have jpgs in chain, but Use Moderately' but plagued by suspicion that even very light use of it will be very painfully heavy for even a small pestnet with well-behaved inhabitants
asciilifeform: atm blatta db on asciilifeform's station weights ~10MB (and that's with sqlite overhead.) nao picture that it weighs coupla GB. and erry new station has to fetch it 1 getdata at a time.
signpost[asciilifeform]: once I shit down pentacle vpatches I'll take up a few gigs of everyone's chain just with that.
signpost[asciilifeform]: asciilifeform: rapid chain sync is something the fountain code can help with. I just haven't proposed pulling it into that layer yet because too soon.
asciilifeform: signpost: they're chained tho, you can't get'em in parallel
asciilifeform: think about it
asciilifeform: need msg N to get hash of msg N-1 to getdata
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-28#1019689 << vpatches should not be inline, but an attachment. we're discussing two different mechanisms of attaching content to log. inline and an info packet with hash.
signpost[asciilifeform]: one approach there is a command that gives me a list of hashes back at various offsets in your chain.
bitbot[asciilifeform]: Logged on 2022-12-28 18:27:14 signpost: once I shit down pentacle vpatches I'll take up a few gigs of everyone's chain just with that.
signpost[asciilifeform]: so that I can retrieve from all those points in parallel.
asciilifeform: signpost: see sect. 5.4.8 ('inv') in draft
signpost[asciilifeform]: phf: you're overusing should which doesn't convey how you get there.
asciilifeform: ( but is rather half-baked, only gives 13 hashes max )
asciilifeform: err, 5.4.9
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-28#1019698 << what's the core of the discussion we were having with ascii, which starts roughly here http://logs.bitdash.io/pest/2022-12-28#1019618. a `should` in this case is aligned with the substance of the conversation.
bitbot[asciilifeform]: Logged on 2022-12-28 18:29:46 signpost: phf: you're overusing should which doesn't convey how you get there.
bitbot[phf]: Logged on 2022-12-28 16:19:25 phf[awt]: because 3gb iso is self-evidently an attachment, but a graph that's driving a conversation is self-evidently part of log. you're either optimizing for size of log, or for arbitrary holes
signpost[phf]: so one rapid sync mechanism would be to select a given message identified by hash, and establish a fountain code block generation scope of "preceding 10000 messages from HASH" and have however many peers spray these at the recipient
asciilifeform[phf]: ( permitting a 'forward' variant of getdata is tricky, because nao you have tree of potentially unbounded branchness, rather than linear sequence in walk )
signpost[phf]: phf: if it were self-evident whether non-text ought to be represented as log-chain blocks or as some second representation the thread would've resolved already, lol
signpost[busybot]: well, under Ideal Circumstances.
phf[asciilifeform]: you're missing the point and being irreverant about it, which usually ends with me getting progressively madder and you getting progressively more irreverant. therefore i will excuse myself
asciilifeform abstractly agrees 'oughta be able to throw a jpg diagram in the broadcast chat' but would like to find a cheaper way of doing it than stuffing however many MB into chain, and throwing'em in the flood , if at all possible
asciilifeform: ... but at same time allowing the jpg to behave ~as if~ were parked in the chain, i.e. anyone who can spare the disk stores a copy by default
signpost[asciilifeform]: phf: please attempt at least a few other head-voicings of the text before getting galled.
signpost[busybot]: what's "obviously inline" needs a definition. the thread here has been going in circles around that.
signpost[asciilifeform]: http://logs.bitdash.io/pest/2022-12-28#1019618 << video can also be "driving the conversation"
signpost[asciilifeform]: can't cleave the two apart by this definition
asciilifeform: imho phf is correct in re 'nuffin stops participants of text-only pestnet from throwing in 18MB of text'. but atm this'd be a serious public defecation into a shared sofa and would prolly lead to unpeering. but 18MB of cat , would want to use routinely
bitbot[asciilifeform]: Logged on 2022-12-28 16:19:25 phf[awt]: because 3gb iso is self-evidently an attachment, but a graph that's driving a conversation is self-evidently part of log. you're either optimizing for size of log, or for arbitrary holes
signpost[asciilifeform]: which is why I brought up wot-tronics, which can, or at least provides useful input to decide.
signpost[asciilifeform] is disinclined to introduce a second-representation for anything. would be nice if the core data structure can express bolth.
asciilifeform: signpost: right, except that the only possible wot cut you can make re a broadcast msg is to not accept a hearsay at all in given case
asciilifeform: hearsays are unauthenticable
asciilifeform: ( and, note, they're still eating yer bw even if you don't print or rebroadcast'em )
asciilifeform: btw (and iirc phf noted this , in the early days, even before pest per se , when discussed 'gossip') : you can have a walkable chain XOR folx dropping hearsays selectively
asciilifeform: ( you can killfile, or 'gag', given speaker, but if you ignore a hearsay that 1 or more of yer peers did not ignore, your netchains will diverge)
signpost[asciilifeform]: well, I might upset phf by agreeing with him, given I'm somehow irreverently, deliberately ignoring his arguments, but I don't know whether one wants to mechanically prevent all possible friend misbehaviors.
signpost[asciilifeform]: solution might be in the direction of "be able to clean couch, replace couch, shove friend out airlock"
asciilifeform: signpost: can't seem to locate the ancient thread atm sadly
asciilifeform: iirc there was a similar 1 ~2y ago where punkman briefly returned and made same observation (was skeptical of whole concept of chained msgs for this reason)
phf[asciilifeform]: 􏿽signpost, the thread between me and asciilifeform was about two methods of attachment, where one, on a side channel, is obviously required, and second, an inline one, is potentially good to have. the question was resolved to `yes, that second one is good to have, but the cost, even
phf[asciilifeform]: 􏿽 with a community policy might be too high`. the operator in the scenario we were discussing has to decide `am i going to inline this file or am i going to make it an attachment`. the policy of which way that decision goes, that is implicitly forming out of discussion is `an image
phf[asciilifeform]: 􏿽or a short video of significantly small size that you want everyone to see now and in perpetuity so as to drive the conversation forward`
asciilifeform: phf's summary correct imho
asciilifeform: hmm phf's msgs reordered on billymg's logotron but in correct order on asciilifeform's desk, go figure
phf[asciilifeform]: also correct on nosuchlabs. the mysteries of netchain reassembly!
signpost[asciilifeform]: yes, and I said it's also worth considering that a side-mechanism implies a missing element of the original design.
signpost[asciilifeform]: such that for example there are things in this tree of knowledge that one doesn't necessarily immediately broadcast all-to-all
asciilifeform: signpost: from 1 pov, there's an obvious missing element (forward links) but its implementation sadly physically impossible
asciilifeform: ( even if you had a time machine, lol )
asciilifeform: two strings can't contain hashes of 1 anuther (unless yer hash algo is a joke, and even then not easy)
signpost[asciilifeform]: one solution to forward reference is being able to issue a gensym which I can later bind to a concrete value.
asciilifeform: signpost: that's the 'here's a http://localhost:13337/pest/asciilifeform/cat.jpg ' solution, neh
asciilifeform: ( or whatever moar compact variant of same )
asciilifeform: hypothetically, if asciilifeform is in yer l1, you end up with a complete .../you/asciilifeform/*
asciilifeform: and can offer it up to others in yer l1, who can.. recurse
asciilifeform: this was asciilifeform's orig. picture of 'pestronic hosting'
asciilifeform: i.e. bury http and dns in favour of ^ , notionally
signpost[asciilifeform]: a proposed overarching representation would allow me to define side walks of the log and point to their various heads from main chain.
signpost[asciilifeform]: then we don't end up nipple twisting about what's obviously inline.
signpost[asciilifeform]: all the data's there; not all of it was broadcast all-to-all
asciilifeform: signpost: asciilifeform suspects this is isomorphic to ^ . and not knows whether moar or less expensive than same
signpost[asciilifeform]: any client can then start walking from HEAD of sidechaining containing linux.iso or tits.jpg if it chooses
signpost[asciilifeform]: and if it chooses, will then have with what to answer other requests for same
signpost[asciilifeform]: I can then say things like "I care about sidechains from phf and not dickbutt"
bitbot[asciilifeform]: Logged on 2022-12-28 12:16:18 asciilifeform[jonsykkel|awt|deedbot]: ftr here's anuther, entirely different, 'inelegant solution' -- binary multipart msgs, but erry single one has to carry nethash/selfhash of the immed. preceding text msg., so that stations are able to 'skip' it when walking back the chain.
asciilifeform: signpost: you'd prolly end up with 'only care about sidechains from l1' tho, given as only l1 peers are distinguishable
asciilifeform: and then may as well pass files in direct streams of luby
asciilifeform: recall that all hearsays 'can be from anyone'
asciilifeform: ( folx , even who have tuned in from the beginning of the pest threads, tend to forget the implications of this )
asciilifeform: the q re 'inline' is specifically re 'should people be in the habit of ~broadcasting~ lolcat.jpg'.
asciilifeform: there are no bw-guzzling or hdd-filling issues re ~direct~ transfer of a chained (or lubyized for that matter) cat.jpg
asciilifeform: i.e. you know who is sending it, he's 1 of yer peers, and if you dun want it, can throw it out and ask him to stop
signpost[asciilifeform]: my l1 attesting to the HEAD message hash of a >l1 sidechain still tells me something, if less than I'd know if I were peered with him directly
signpost[asciilifeform]: say you know linus, and linus just emitted a sidechain containing latest kernel. and you decide to republish the reference message to this such that I see your attestation of the hash.
asciilifeform: rright, today would simply be e.g. sha2 of the tar, in ordinary text
signpost[asciilifeform]: yup, just a more formalized mechanism of chaining trust as already done.
signpost[asciilifeform]: A can introduce C to B
asciilifeform: per asciilifeform's lights, the way to get the tar itself oughta be to ask one's l1 for the hash, as broadcast; someone will have it, or at least have permitted his station to receive it from a peer who ... recurses
asciilifeform: who doesn't want the thing, simply refrains from triggering this process on his station
asciilifeform: if sumthing is genuinely integral-to-the-thread, imho it will end up available
asciilifeform: even without being stuffed in the chain wholesale
phf[asciilifeform]: the primary and exclusive characterstic of an `obviously inline` binary blob is that you always get it with your logs in real time at the rate of the network or from log storage. it is in all other ways equivalent to a log.
phf[asciilifeform]: but /most/ binary blobs you want to make decisions about. do i want to download linux.iso or knuth.pdf?
asciilifeform: can always set yer station to auto-request cat.jpg which has advertised size <= N bytes
asciilifeform: while for all larger, manual
asciilifeform: then will behave precisely as if in chain, more or less
asciilifeform: without foisting the cat.jpg on ~erry~ future station that wants to grab the chain to t==0
signpost[asciilifeform]: phf: so give me the benefit of the doubt that I'm not trying to pour acid on your ulcer here. why is an image obviously inline if one might have a device that can't even display this?
asciilifeform: ( i.e. just about errybody gets what he wants )
signpost[asciilifeform]: perhaps the answer there's that it's still good citizenry of a pest station to forward what's realtime chain data
asciilifeform: 'the wolves are fed and the sheep are whole'(tm)(ru)
asciilifeform wants precisely this -- cat.jpg remains available, on acct of being massively mirrored, and propagated on request; while base chain is kept compact and fetchable without 'go buy hdd and wait 3months'
asciilifeform must bbl
phf[asciilifeform]: signpost, that's a rendering issue, rather than essential property of the log experience. the question with essential inline is how does best case rendering of the log looks and behaves.
phf[asciilifeform]: if i were for example using some kind of shared and distributed Word system, i would have an option to add an image to text, and expect that image to be an essential element of the document reading experience. `<graph of behavior> as you can see from graph, blah blah`
phf[asciilifeform]: if you were to pick up that word document 20 years later, or if i were to just grab it before i get on a train, i would have identical reading experience. at the same time any external references that i make might or might not be there.
phf[asciilifeform]: and the flip side of this external references property is that while the document might be talking about linux.iso, it might include screenshots and illustrations from linux.iso experience, it doesn't include linux.iso itself
signpost[asciilifeform] has no problem with defining the log as an infinite scroll of illustrated text
signpost[asciilifeform]: and if so defined, would be unreasonable for one to consider his chain complete without that content
signpost[asciilifeform]: (and just looking over the images feature of btcbase log, it's *sad* they aren't there)
signpost[asciilifeform]: isn't at all clear to me that it's not useful to use pest concepts to publish albums, say, though.
phf: in this case delivering mechanism mirrors human experience. i get enough information about linux.iso to understand the narrative, but having understood the narrative i can then make decisions about linux.iso (e.g. try and find it, or decide that i don't need it and remove from station)
phf:
signpost[busybot]: actually that makes it a bit clearer.
phf[asciilifeform]: this is probably somehow complementary to the whole rich text thread from some time ago
signpost[asciilifeform]: yes. text formatting questions come in too, if going with the illustrated text definition of log.
signpost[asciilifeform]: or they don't, but they at least peek in through the opening.
signpost[asciilifeform]: "getting enough information to decide" is a decent rule of thumb in the direction of which might be a clearer definition of log though.
dulapbot: (trilema) 2017-01-07 mircea_popescu: phf illuminated schematics with tits seems like a winning strat.
← 2022-12-27 | 2022-12-29 → ↑
Random(pest) | Download hourly DB snapshot | Get Source Code