| 00:30:25 | | klea003 is now known as NotKlea |
| 01:44:01 | | tzt (tzt) joins |
| 05:10:31 | | DogsRNice quits [Read error: Connection reset by peer] |
| 07:41:22 | | Doranwen quits [Read error: Connection reset by peer] |
| 07:41:44 | | Doranwen (Doranwen) joins |
| 09:39:05 | | grill quits [Quit: leaving] |
| 09:43:46 | | grill (grill) joins |
| 10:11:58 | | yano quits [Quit: WeeChat, https://weechat.org/] |
| 10:18:10 | | yano (yano) joins |
| 12:58:28 | | ThreeHM quits [Ping timeout: 268 seconds] |
| 13:03:07 | | ThreeHM (ThreeHeadedMonkey) joins |
| 15:48:15 | <justauser> | Anybody else seen https://old.reddit.com/r/internetarchive/comments/1ubt4vl/seriously_dont_trust_ia_to_host_any_data_some_of/ ? Not a single verifiable claim, but doesn't look good. |
| 16:25:05 | <cruller> | https://old.reddit.com/r/internetarchive/comments/1u9dc3h/metadata_error/ similar one (found from their activity) |
| 16:58:34 | | DogsRNice joins |
| 17:53:57 | <IDK> | does anyone have an example of this page? |
| 18:00:00 | <klea> | https://archive.org/editxml/xxx with xxx being a non-existent identifier shows the primary US node message (when logged in) |
| 18:01:02 | <IDK> | klea: isnt there something where one can see which node its being served from even with darked item? |
| 18:01:59 | <IDK> | https://archive.org/metadata/xxx |
| 18:03:02 | <klea> | We do need their item IDs to see the nodes tho. |
| 18:03:26 | <IDK> | klea: are we sure no one is getting into IA's server and manually deleting files? |
| 18:03:53 | <klea> | I'd be scared if that were the case. |
| 18:04:12 | <IDK> | I still have a feeling IA's security is disproportionately lax |
| 18:04:16 | <IDK> | like 2005 lax |
| 18:04:37 | <klea> | I think they may have improved on it somewhat after the 2020 hack, but IDK. |
| 18:05:22 | <IDK> | klea: before that it was basically no security, |
| 18:05:30 | <IDK> | I remember I was still able to change the upload date to 1969 with inspect element back in 2019 |
| 18:05:48 | <klea> | The upload date is part of the item metadata that's not restricted. |
| 18:06:17 | <IDK> | nothing was restricted back in 2019 |
| 18:06:19 | <klea> | And you can set it to whatever via the API, even if their web UI limits the range. |
| 18:07:21 | <klea> | collections were AFAIK? |
| 18:07:50 | <IDK> | klea: I never tried tbh, but I know you could change the uploader to whoever you want |
| 18:08:04 | <IDK> | and then it might get put into collections idk |
| 18:08:19 | <klea> | Wut |
| 18:09:28 | <IDK> | tbh, I managed to remove the uploader on one of my items back then and put one of my garbage items under an admin (all in 2019 ofc) |
| 18:22:39 | <IDK> | but indeed, looks like IA's "metadata fetching" performance is down the drain recently, I have a few "unable to load metadata from item location" moment but they tend to return quickly for me |
| 18:22:44 | <IDK> | example: https://archive.org/details/j8LKNuaygms |
| 18:22:56 | <IDK> | example2: https://archive.org/details/adhd-extra-allt |
| 18:23:17 | <IDK> | going to the metadata page returns {"error":"unable to load metadata from item location"} |
| 18:26:59 | <IDK> | looks the fucked up items all got moved to dn*.us.archive.org, no idea what dn means instead of ia |
| 18:27:52 | <justauser> | DeadNode? |
| 18:28:11 | <justauser> | I think some dn's worked fine for me in the past. |
| 18:28:28 | <IDK> | https://dn801201.us.archive.org/0/items/kar-svt/1.%20Gillar%20du%20honom.mp4 works fine tho |
| 18:28:54 | <IDK> | anyways the one that didnt work pointed to dn800303.us.archive.org instead of the old ia* nodes |
| 18:29:12 | <IDK> | canada node just started throwing 500 instead |
| 18:39:14 | <IDK> | looks like problem is quite widespread actually, always ones that has dn as their primary us node |
| 18:50:55 | <klea> | Denver? |
| 18:51:59 | <IDK> | nah they are still in sfo |
| 19:50:49 | <TheTechRobo> | adhd-extra-allt is loading sporadically for me, seems to be some load problems, yeah |
| 19:51:04 | <TheTechRobo> | Also sometimes seeing metadata retrieval errors on arthur-season-1 |
| 20:31:46 | | tzt quits [Ping timeout: 268 seconds] |