ec changed the topic of #elliottcable to: a 𝕯𝖊𝖓 𝖔𝖋 𝕯𝖊𝖙𝖊𝖗𝖒𝖎𝖓𝖊𝖉 𝕯𝖆𝖒𝖘𝖊𝖑𝖘 slash s͔̞u͕͙p͙͓e̜̺r̼̦i̼̜o̖̬r̙̙ c̝͉ụ̧͘ḷ̡͙ţ͓̀ || #ELLIOTTCABLE is not about ELLIOTTCABLE
<ec> and gx maybe? idk I have hope, a little bit
<ljharb> what's gx
ohhmaar has quit [Ping timeout: 248 seconds]
ohhmaar has joined #elliottcable
<yorick> did they fix ipns yet?
<yorick> (lookups not taking 10s of seconds, you can have more than 1)
<jfhbrook> I should try writing a simple package manager for openscad
<jfhbrook> again
<jfhbrook> I tried writing one when I was like
<jfhbrook> 23? I guess?
<jfhbrook> it was bad
<jfhbrook> I don't actually use openscad but pay for the droplet that hosts its file downloads
<jfhbrook> and am on its mailing list
<jfhbrook> y'know, by historical accident mostly
kaftoot has joined #elliottcable
<ec> yorick: I doubt it )'=
<ec> kaftoot: how was the first day? 😁
<kaftoot> ec it was goood but tiring
kaftoot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kaftoot has joined #elliottcable
<ec> kaftoot: yeah good lord, no kidding
<ec> sleep tight!
<joepie91> ec: yorick: ljharb: I'm automatically suspicious of any sort of package management that's built on IPFS and that *doesn't* explicitly state where its persistence guarantees come from (because usually "built on IPFS" translates to "the data will be gone in 2 years because nobody seeded it and we didn't realize that IPFS isn't a magic persistent data bucket")
<joepie91> like, /theoretically/ a block exchange protocol like that of IPFS can be greatly beneficial but I have yet to see an actual sane implementation in the context of package management, or anything else really
<joepie91> well, other than bittorrent, where the non-persistence-guarantees are very clear :P
kaftoot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mylesborins has quit [Quit: farewell for now]
mylesborins has joined #elliottcable
ljharb has quit [Read error: Connection reset by peer]
ljharb has joined #elliottcable
kaftoot has joined #elliottcable
kaftoot has quit [Client Quit]
kaftoot has joined #elliottcable
kaftoot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kaftoot has joined #elliottcable
kaftoot has quit [Client Quit]
kaftoot has joined #elliottcable
kaftoot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
meowrobot is now known as \meowrobot
\meowrobot is now known as meowrobotr
meowrobotr is now known as meowrobot
kaftoot has joined #elliottcable
kaftoot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
meowrobot has quit [Quit: let us connect our intestines and mutually digest]
meowrobot has joined #elliottcable
muelleme_ has joined #elliottcable
kier has quit [Ping timeout: 248 seconds]
kier has joined #elliottcable
muelleme_ has quit [Ping timeout: 264 seconds]
<ec> joepie91: idk how it works directly, but isn't that sort of the point?
<ec> “if someone's code depends on it, they have a copy” ∴ “if anyone's code depends on it, someone is seeding a copy”
<ec> if that's not how it works — i.e. anybody using it is automatically / has to be a seed,
<ec> then I guess I agree it's broken
<joepie91> [21:53] <ec> “if someone's code depends on it, they have a copy” ∴ “if anyone's code depends on it, someone is seeding a copy”
<joepie91> if anyone's code depends on it, *and* that party is still online, *and* that party is still seeding it
<joepie91> this means inevitable rot of unpopular things just like what happens with torrents
<joepie91> especially since pretty much nobody is going to be okay with seeding from prod systems
<ec> hmmmmmmmmmmm
<ec> thing is, I'm not personally concerned about “is available right now”
<ec> b/cuz if you're using it for production stuff, you need ur own damn cache
<ec> whereas for anything else, the primary concern is “is gone forever”, which seems proof against
<ec> I agree though, doesn't sound ideal overall.
<joepie91> there is absolutely nothing in IPFS preventing 'gone forever' :)
<ec> what's your thought / improvement? because the *benefits* of gx's system, well, damn.
<joepie91> just like there isn't in bittorrent
<ec> there is, though
<joepie91> take all properties of bittorrent and you can apply them pretty much verbatim against ipfs
<ec> it's not bittorrent because a movie you watch, is gone after you watch it
<ec> or a music file you download is moved out of Bittorrent's universe and into, idk, iTunes
<joepie91> not necessarily?
<ec> but if you can find a *reference* to weird_obselete_library in some code, somewhere,
<ec> then *that code exists*
<ec> which implies vendor/weird_obselete_library exists
<ec> and as long as the system doesn't allow for selfish users to stop seeding tiny bits of text just 'cuz they don't damn feel like it — that's nearly proof positive against “I found this reference to obscure_thing, but obscure_thing doesn't exist anymore”
<ec> because it's code, it has to exist *alongside* the reference.
<joepie91> ec: but... it does allow for that
<ec> at least, in a npm-like system.
<joepie91> that's the point
<joepie91> it works *exactly* like bittorrent
<joepie91> nothing is seeded unless something tells the client to do so
<ec> you download a library and then move it somewhere else? 'cuz that's dumb.
<joepie91> there's no magic
<joepie91> it's not about moving it
<joepie91> it's about whether you seed it or not
<joepie91> again: it works exactly like bittorrent
<ec> are you talking specifically about gx, or are you talking about using IPFS as a package store
<joepie91> if you seed a thing then you seed a thing, if you don't then you don't
<joepie91> if nobody seeds a thing it's gone
<joepie91> ec: I'm talking about IPFS full stop
<joepie91> anything on IPFS
<ec> b/cuz I'm talking about the later — I don't much care what terrible decisions gx may or may not have made.
<ec> well this isn't “drag a folder full of code to my IPFS client”
<ec> it's “let's design a package-management system that uses IPFS as a store”
<joepie91> you're missing the point
<ec> and in that case — yes, unless the user goes to absurd effort to block or stop it, I'd definitely design the system to always seed anything that there's a local copy of? duh?
<joepie91> it doesn't matter what you're designing if the underlying data store inherently doesn't provide any availability guarantees
<ec> it's a couple kilobytes of text, not a gigabyte movie.
<ec> it absolutely does!
<ec> this isn't Haskell.
<ec> I don't care about *guarantees*.
<ec> I care about a reasonable system, and a realistic chance of success.
<joepie91> which you don't have, because bitrot is a thing, and it is guaranteed to happen if your system does not have availability guarantees
<ec> Show me why it's *likely* — not just possible — that a package will disappear forever from the system
* ec sighs
<joepie91> ec: I don't know why you're asking me to show you something that has been a known phenomenon for two decades
<joepie91> at least
<ec> I'm not concerned about betroth.
<ec> bitrot*
<ec> you're conflating two unrelated things.
<ec> linkrot et al, are when there's references to *an external system*.
<joepie91> a package registry that doesn't guarantee that the code that's there today will still be there in a year, is effectively useless
<ec> Here, you have 1. a file with a reference to unknown_thing, and 2. unknown_thing
<joepie91> so no, I'm not conflating unrelated things at all
<ec> and the *nature of code*, at least in a dynamic system where you don't have this dislocated concept of “source code” that may not be associated with the actual product,
<ec> is that 2 is adjacent to 1 in any system where 1 could possibly exist
<joepie91> ec: 1) it doesn't matter whether something exists if it's not being made available (which is what bitrot is *about*), and 2) something that exists now may not exist in a year when somebody else wants it
<ec> you're literally not listening to me
<joepie91> and you seem to be ignoring the primary purpose of a package registry?
<ec> re 2), as I just said, as far as I can tell, *that's not a problem for code*, like it is with, say, a web article, or a movie
<joepie91> why wouldn't it be?
<ec> and 1) that's *mostly* solvable — to a point of usefulness, beyond which discussion is pedantic and masturbatory — by the layer on top of IPFS *not allowing for* “not making something available”
<ec> ugh I literally just said all that
<ec> it's code, anywhere you have a reference, you have an adjacent copy
<joepie91> good luck selling "your prod server is required to seed libraries to other people" to actual developers...
<ec> that isn't the case with Death Bed: The Bed That Eats — it's entirely possible for Joe Blogger to reference the movie, and not keep a copy around
<joepie91> I don't know why you keep assuming that there's some sort of thing that references it *at all* in the long term
<ec> exactly my point!
<ec> if it's never referenced, I *want* it to rot away.
<joepie91> okay, great, totally useless for a package registry
<ec> like I feel like we're not even talking to eachother, just past eachother.
<joepie91> no, the problem is that you're ignoring the actual real-world requirements that a package registry has
<joepie91> and getting stuck in "well *I* would not consider that a problem"
<ec> This is a *package manager*. Something that is not referenced or utilised, does not need to be available: at that point, it's basically squatting on a name, or the equivalent.
<joepie91> it's pointless for me to argue the uselessness of an IPFS-based package manager purely on the basis of whether *you* consider certain properties to be a problem; this is irrelevant and not a useful use of my time... what I'm interested in is whether it can work *as an actual package manager for the wider developer community*, which it cannot, because it is missing basic guarantees that a package registry needs to provide to be useful to the
<joepie91> wider developer community
<ec> fair ¯\_(ツ)_/¯
<ec> I'm not advocating “let's replace npm with IPFS”
<ec> gx may be, but idk gx things — i just thought it looked cool.
<joepie91> I mean, it looks cool in the 'huh, interesting experiment' sense
<ec> however *I* am building a programming language, and platform; and you don't at all seem to be convincing me that IPFS is a bad idea for a package repository.
<joepie91> but it just has no real-world longevity in it, conceptually
<ec> and of course it's totally a waste of your time — waste of mine, too
<joepie91> ec: well, like I said: you're not going to sell a package registry to people where things just magically disappear over time with no warning nor chance of recovery
<ec> you're neither listening to me (which is fine, but a waste of my time), nor interested in the actual problem I'm trying to discuss (again: that's A. okay), so I'm gonna go back to tryna patch this Merlin bug
<joepie91> that's why IPFS is a bad idea for a package repository, there's really not much more to it
muelleme_ has joined #elliottcable
muelleme_ has quit [Ping timeout: 252 seconds]