ec changed the topic of #elliottcable to: a 𝕯𝖊𝖓 𝖔𝖋 𝕯𝖊𝖙𝖊𝖗𝖒𝖎𝖓𝖊𝖉 𝕯𝖆𝖒𝖘𝖊𝖑𝖘 slash s͔̞u͕͙p͙͓e̜̺r̼̦i̼̜o̖̬r̙̙ c̝͉ụ̧͘ḷ̡͙ţ͓̀ || #ELLIOTTCABLE is not about ELLIOTTCABLE
<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