Show Idle (>14 d.) Chans
← 2022-12-27 | 2022-12-29 → ↓
10:43 phf 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?
10:47 phf 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.
↖
10:56 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 )
10:56 asciilifeform for that matter, a la ye olde alt.binaries.*
10:59 asciilifeform per current draft spec you can stuff up to 18,874,080 byte in there.
11:02 * 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
↖
11:02 asciilifeform and it'll sit 4evah on disk
11:04 asciilifeform imho would be much better to do the clever thing re luby fileshares instead, i.e. where they can propagate somehow
11:09 phf 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
11:11 phf 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
11:21 phf 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
11:24 phf 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
~ 40 minutes ~
12:04 asciilifeform phf: the reason wainot 'binary chained msgs' is this -- still not sure whether parking binariolade in the chain is good idea at all
↖
12:04 bitbot 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
12:05 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
↖
12:05 asciilifeform and store it on disk for the next fella, etc
12:06 asciilifeform for that matter, the max multipart counter prolly oughta be e.g. 255, rather than 65535
12:07 asciilifeform lolcats really oughta travel e.g. a-lubystream->b-lubystream->c etc. after c->gimmebinwithhash->b-gimmebinwithhash->a
↖
12:08 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
12:09 asciilifeform phf: picture what the #t logs would weigh if all of mp's 'lolcats' ~had~ to live inside it as bins
↖
12:09 asciilifeform (or couldn't load it at all)
12:12 asciilifeform this was why, in draft spec, asciilifeform defined 'binary msgs are always direct'
12:12 * asciilifeform aint certain precisely how to 'solve lolcat problem' but is quite sure of 'how not to'
12:12 phf i dunno, sounds like asciilifeformism :> `can't solve this problem in elegant way, therefore will punt on it entirely
12:13 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
12:13 asciilifeform 'devil in details' tho.
12:13 asciilifeform * 1 or moar
12:14 asciilifeform iirc signpost had the beginnings of an algo , in 'napkin stage'.
12:16 phf 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`
12:16 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.
↖
12:16 asciilifeform phf: right, as asciilifeform understands this was general idea in signpost's algo
12:17 shinohai R.I.P. Ted Kaczynski I'm hearing ?
12:17 asciilifeform shinohai: source ?
12:17 phf 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
↖
12:17 bitbot 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
12:18 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
12:18 phf 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`
12:18 shinohai nah appears to be 'nother chan-hoax
12:18 asciilifeform shinohai: lolk
12:20 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'
12:20 asciilifeform i.e. 'the trb situation'
12:21 phf word
12:34 * signpost put some cycles into the python version of the fountain code impl over the past few days, will post a new vpatch
12:35 signpost added demonstrator commands "squirt" and "slurp", and lib's going to be called squirt.
12:36 signpost going to see about going ahead today and doing the multiprocessing port I disavowed in my last blog post
12:39 signpost 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.
12:39 bitbot 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
12:39 * signpost has been focused for some time on the problem of latter.
12:51 signpost 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.
12:51 bitbot 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
12:52 asciilifeform signpost: simply on acct of their mass. 'quantity has a quality of its own'(tm)
12:52 asciilifeform would like to avoid trb-style 'buy a new hdd and come back in 3 months' ugh
12:54 signpost 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.
12:54 signpost perhaps binary media is a "subthread" chain, and my lightweight client with only 2gb of flash can ignore all non-text links.
↖
12:55 asciilifeform signpost: for chained msgs, asciilifeform intended 'netchain' for 'link to log line being replied to'
12:55 signpost the threading mechanism gives ya "episodes of series" etc
12:55 asciilifeform ( the current paste-link-to-logotron thing is 'not from a good life', from the forced linearity of irc )
12:58 signpost 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
12:58 signpost or retrieve on demand
12:59 signpost 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.
13:00 asciilifeform signpost: as currently specified, the multiparts still end up extending speaker's selfchain tho
13:00 signpost 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
13:01 signpost asciilifeform: ah right. I have the spec up alongside, refilling brain-cache
13:01 asciilifeform ( skipping anyffin on the chain is nontrivial -- for 1 thing, broadcasts go to erryone; for anuther -- there are no forward links, only backward )
13:04 signpost 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?
13:04 bitbot 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.
13:07 signpost but I agree the experience is doing what you want here. somebody needs to be able to livestream a j6 on it.
13:08 * signpost 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.
13:17 phf 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
13:17 bitbot 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.
13:19 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)
13:19 asciilifeform that, and the fact that broadcasts hit erryone, consuming bw, whether the recipient 'wants' that msg or not
13:20 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
13:20 asciilifeform *proposed
13:20 * signpost 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.
13:21 signpost will think moar with caches fuller
13:21 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
13:21 asciilifeform otherwise bw nightmare.
~ 1 hours 11 minutes ~
14:32 phf valid points
14:34 phf i guess there's a question of useful distinction between an inline nudes, and a 600mb `filthy moms volume 11`
14:35 phf 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
↖
~ 15 minutes ~
14:51 phf ftr this issue is solved by reich-technology, telegram specifically is imho state of the art when it comes to personal messenger usability
↖
14:51 phf the utility of little-known feature on btcbase is significantly reduced because linkrot, http://btcbase.org/log-search?q=from%3Atrinque+jpg&inline=true
14:57 awt The problem was annoying enough for me personally to put some effort into an archiving indexer.
14:58 signpost phf: damn, this is nice aside the bitrot.
14:58 signpost awt: how much of the log did you end up getting archived?
14:59 signpost would be great to at some point reassemble what can be.
14:59 * signpost bbl
14:59 signpost http://btcbase.org/log/2016-03-31#1442638 << what a delight. I still have that.
14:59 signpost and I married and knocked her up. life is better lived with logs.
15:01 awt 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.
15:02 awt Caveat - archives were text only and stored in a pg table.
15:03 phf so what was in archives? contents of page links?
15:03 awt phf: yes.
~ 58 minutes ~
16:02 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 ?
16:02 bitbot 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
16:04 * 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 ?
16:06 phf 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
16:06 bitbot 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
16:09 phf 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.
16:11 phf 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.
16:13 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
16:14 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
16:15 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 )
16:18 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
16:18 phf maybe then that should be an operator choice?
↖
16:19 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?
16:19 phf 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
↖ ↖
16:20 * 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
16:21 phf 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
16:21 phf 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
16:22 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
16:22 asciilifeform aha
16:29 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' --
16:29 asciilifeform ... you can't directly talk to an l2+ peer
16:30 asciilifeform peer^H^H^H^Hstation that is
16:31 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)
16:32 asciilifeform ( as #1 axiom of pestronics is that 'station only directly talks to operator-defined peers' )
16:33 asciilifeform imho an acceptable solution is 'if no one in l1 has bin with $hash, you suck yer thumb'
↖
16:33 asciilifeform i.e. no bin auto-propagation beyond 1 level.
16:34 asciilifeform possibly, operators could optionally enable 'propagate warez request' if they have disk/bw to spare. then : this.
16:34 bitbot 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
16:36 phf hmm, my packets are being lost in the aether :/
16:36 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
16:36 phf bump
16:38 * asciilifeform must bbl for a spell
16:45 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
16:45 bitbot 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'
16:45 phf the use case i'm talking about is http://btcbase.org/log-search?q=from%3Aphf+%22glyf.org%22+%22png%22&inline=true
16:45 phf 􏿽that there's a hole, because everyone's warez knobs are set to 2 years.
↖
16:52 unpx 5wot
~ 40 minutes ~
17:32 asciilifeform wb unpx
17:33 asciilifeform phf: is entirely valid point, difficult to disagree. q is 'wat do'
17:34 * asciilifeform fwiw 'solves' above with 'jpgs sit down on his www /pub, and sit for arbitrary yrs'. but this aint a general solution.
~ 29 minutes ~
18:03 signpost http://logs.bitdash.io/pest/2022-12-28#1019640 << wot helps solve this imho.
18:03 bitbot 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.
18:03 signpost I would store just about anything indefinitely from l1. much less inclined to as one proceeds outward.
18:05 signpost seems well-mapped to the social expectations too. your friends remember you best.
18:06 signpost and they're the best folks to ask "do you remember so-and-so" when you're gone
18:08 signpost perfectly good answer to ^ is "who the fuck are you, again?" too, depending on who asks.
18:09 phf i think that's only an acceptable solution for warez, but not for essential elements of log
18:10 phf 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
18:10 signpost how are you reading it?
18:10 signpost if you are not in my wot, or somebody else's.
18:11 phf log is broadcast, doesn't need to be in l1
18:11 signpost maybe with a better definition of this "essential" it's clearer.
18:12 signpost absent that my inclination is to let subjective matters like what's essential be a matter of operator control
18:13 signpost pics are at least bounded items. videos might not be
18:14 phf http://logs.bitdash.io/pest/2022-12-28#1019616
18:14 bitbot Logged on 2022-12-28 16:18:51 phf[awt]: maybe then that should be an operator choice?
18:16 phf the thinking here is that leaning towards operator choice makes sense, because the network is so wot heavy
18:16 signpost yup yup
18:17 * signpost has no problem with there being "inline" items of some reasonable titpic size
18:18 signpost and yeah, what I'd allow inline I'd potentially adjust upward for more trusted parties.
18:19 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)
18:19 asciilifeform ( this, obv., per the 'stuff jpg in chained msgs' scheme )
18:20 phf 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?
18:21 asciilifeform and then, if getdataing to get the history, gotta walk through that 18MB
18:21 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
↖
18:21 signpost there's no damnatio memoriae currently specified is there?
18:21 signpost data from some dork would still be there as part of the chain after his unpeering
18:21 signpost if one wanted a fully walkable chain, have to have this
18:21 asciilifeform signpost: nope. chain is the archaetypical 'spittoon in 1 strand'
18:22 signpost yeah.
18:22 asciilifeform sorta like trb is stuck storing erry piece o'shit tx 4evah.
↖
18:23 signpost 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.
18:23 asciilifeform imho the essence of the 'how to lolcat on pest' q can be restated as 'how to send ~optional~ wad of msgs'
↖
18:23 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?
18:23 bitbot Logged on 2022-12-28 18:22:42 asciilifeform[5]: sorta like trb is stuck storing erry piece o'shit tx 4evah.
18:23 signpost 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
18:24 signpost asciilifeform: yep exactly
18:25 phf 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
18:25 bitbot 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'
18:25 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
↖ ↖
18:26 signpost not a bad thing to have this problem and then do something smarter.
18:26 phf 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
18:26 bitbot 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
18:27 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.
18:27 signpost once I shit down pentacle vpatches I'll take up a few gigs of everyone's chain just with that.
↖
18:27 signpost 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.
18:28 asciilifeform signpost: they're chained tho, you can't get'em in parallel
18:28 asciilifeform think about it
18:28 asciilifeform need msg N to get hash of msg N-1 to getdata
18:29 phf 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.
18:29 bitbot 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.
18:29 signpost one approach there is a command that gives me a list of hashes back at various offsets in your chain.
18:29 signpost so that I can retrieve from all those points in parallel.
18:29 signpost phf: you're overusing should which doesn't convey how you get there.
↖
18:30 asciilifeform signpost: see sect. 5.4.8 ('inv') in draft
18:30 asciilifeform ( but is rather half-baked, only gives 13 hashes max )
18:30 asciilifeform err, 5.4.9
18:31 signpost right
18:32 phf 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.
18:32 bitbot Logged on 2022-12-28 18:29:46 signpost: phf: you're overusing should which doesn't convey how you get there.
18:32 bitbot 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
18:32 signpost 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
18:33 asciilifeform ( permitting a 'forward' variant of getdata is tricky, because nao you have tree of potentially unbounded branchness, rather than linear sequence in walk )
18:33 signpost 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
18:33 signpost well, under Ideal Circumstances.
18:35 phf 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
18:36 signpost oh baw
18:37 * 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
18:38 signpost phf: please attempt at least a few other head-voicings of the text before getting galled.
18:38 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
18:38 signpost what's "obviously inline" needs a definition. the thread here has been going in circles around that.
18:40 signpost http://logs.bitdash.io/pest/2022-12-28#1019618 << video can also be "driving the conversation"
18:40 bitbot 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
18:40 signpost can't cleave the two apart by this definition
18:41 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
18:41 signpost which is why I brought up wot-tronics, which can, or at least provides useful input to decide.
18:42 * signpost is disinclined to introduce a second-representation for anything. would be nice if the core data structure can express bolth.
18:42 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
18:42 asciilifeform hearsays are unauthenticable
18:43 asciilifeform ( and, note, they're still eating yer bw even if you don't print or rebroadcast'em )
18:46 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
18:47 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)
18:47 signpost 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.
18:47 signpost solution might be in the direction of "be able to clean couch, replace couch, shove friend out airlock"
18:48 asciilifeform signpost: can't seem to locate the ancient thread atm sadly
18:49 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)
18:49 phf 􏿽 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
18:49 phf 􏿽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
18:49 phf 􏿽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`
18:49 asciilifeform phf's summary correct imho
18:50 asciilifeform hmm phf's msgs reordered on billymg's logotron but in correct order on asciilifeform's desk, go figure
18:52 phf also correct on nosuchlabs. the mysteries of netchain reassembly!
18:53 signpost yes, and I said it's also worth considering that a side-mechanism implies a missing element of the original design.
18:53 signpost such that for example there are things in this tree of knowledge that one doesn't necessarily immediately broadcast all-to-all
18:54 asciilifeform signpost: from 1 pov, there's an obvious missing element (forward links) but its implementation sadly physically impossible
18:55 asciilifeform ( even if you had a time machine, lol )
18:55 asciilifeform two strings can't contain hashes of 1 anuther (unless yer hash algo is a joke, and even then not easy)
18:56 signpost one solution to forward reference is being able to issue a gensym which I can later bind to a concrete value.
18:56 signpost but anyway.
18:57 asciilifeform signpost: that's the 'here's a http://localhost:13337/pest/asciilifeform/cat.jpg ' solution, neh
18:57 asciilifeform ( or whatever moar compact variant of same )
18:58 asciilifeform hypothetically, if asciilifeform is in yer l1, you end up with a complete .../you/asciilifeform/*
↖
18:58 asciilifeform and can offer it up to others in yer l1, who can.. recurse
18:59 asciilifeform this was asciilifeform's orig. picture of 'pestronic hosting'
18:59 asciilifeform i.e. bury http and dns in favour of ^ , notionally
18:59 signpost a proposed overarching representation would allow me to define side walks of the log and point to their various heads from main chain.
18:59 signpost then we don't end up nipple twisting about what's obviously inline.
18:59 signpost all the data's there; not all of it was broadcast all-to-all
19:00 signpost any client can then start walking from HEAD of sidechaining containing linux.iso or tits.jpg if it chooses
19:00 asciilifeform signpost: asciilifeform suspects this is isomorphic to ^ . and not knows whether moar or less expensive than same
19:00 signpost and if it chooses, will then have with what to answer other requests for same
19:01 asciilifeform signpost: see also earlier.
19:01 bitbot 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.
19:01 signpost I can then say things like "I care about sidechains from phf and not dickbutt"
19:01 asciilifeform signpost: you'd prolly end up with 'only care about sidechains from l1' tho, given as only l1 peers are distinguishable
19:01 asciilifeform and then may as well pass files in direct streams of luby
19:02 asciilifeform recall that all hearsays 'can be from anyone'
19:02 asciilifeform ( folx , even who have tuned in from the beginning of the pest threads, tend to forget the implications of this )
19:04 asciilifeform the q re 'inline' is specifically re 'should people be in the habit of ~broadcasting~ lolcat.jpg'.
19:06 asciilifeform there are no bw-guzzling or hdd-filling issues re ~direct~ transfer of a chained (or lubyized for that matter) cat.jpg
19:06 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
19:07 signpost 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
19:08 signpost 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.
19:08 asciilifeform rright, today would simply be e.g. sha2 of the tar, in ordinary text
19:08 signpost yup, just a more formalized mechanism of chaining trust as already done.
19:09 signpost A can introduce C to B
19:09 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
↖
19:10 asciilifeform who doesn't want the thing, simply refrains from triggering this process on his station
19:10 asciilifeform if sumthing is genuinely integral-to-the-thread, imho it will end up available
19:11 asciilifeform even without being stuffed in the chain wholesale
19:11 phf 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.
19:11 phf but /most/ binary blobs you want to make decisions about. do i want to download linux.iso or knuth.pdf?
19:12 asciilifeform can always set yer station to auto-request cat.jpg which has advertised size <= N bytes
19:12 asciilifeform while for all larger, manual
19:12 asciilifeform then will behave precisely as if in chain, more or less
19:13 asciilifeform without foisting the cat.jpg on ~erry~ future station that wants to grab the chain to t==0
19:13 signpost 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?
19:13 asciilifeform ( i.e. just about errybody gets what he wants )
19:13 signpost perhaps the answer there's that it's still good citizenry of a pest station to forward what's realtime chain data
19:13 asciilifeform 'the wolves are fed and the sheep are whole'(tm)(ru)
19:15 * 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'
19:16 * asciilifeform must bbl
19:25 phf 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.
19:25 phf 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`
19:27 phf 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.
19:30 phf 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
19:40 * signpost has no problem with defining the log as an infinite scroll of illustrated text
19:41 signpost and if so defined, would be unreasonable for one to consider his chain complete without that content
19:41 signpost (and just looking over the images feature of btcbase log, it's *sad* they aren't there)
19:45 signpost isn't at all clear to me that it's not useful to use pest concepts to publish albums, say, though.
19:45 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)
19:45 phf
19:45 phf this is probably somehow complementary to the whole rich text thread from some time ago
19:46 signpost actually that makes it a bit clearer.
~ 18 minutes ~
20:04 signpost yes. text formatting questions come in too, if going with the illustrated text definition of log.
20:04 signpost or they don't, but they at least peek in through the opening.
20:05 signpost "getting enough information to decide" is a decent rule of thumb in the direction of which might be a clearer definition of log though.
20:18 phf http://logs.nosuchlabs.com/log/trilema/2017-01-07#1598563
20:18 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

Theme: Light | Dark | System Default