Post AkdaoL4e6IAO6VoBwe by colby@kosmos.social
(DIR) More posts by colby@kosmos.social
(DIR) Post #Akdao94uhTFatrqEhE by colby@kosmos.social
2024-08-04T21:43:14Z
0 likes, 0 repeats
A fork of HTTP and the Web, but every URL is permanent.
(DIR) Post #AkdaoA60urj03ZMd3A by strypey@mastodon.nzoss.nz
2024-08-04T22:45:22Z
0 likes, 0 repeats
@colby> A fork of HTTP and the Web, but every URL is permanentIPFS?
(DIR) Post #AkdaoBGKZzZVfrCNlo by colby@kosmos.social
2024-08-04T21:45:38Z
0 likes, 0 repeats
If you operate a server and you return HTTP 200 on Monday for /foo/bar and content with signature f4b49585a78f then you must provide the same response on Tuesday.
(DIR) Post #AkdaoDquww1fhuKd4i by colby@kosmos.social
2024-08-04T21:47:41Z
0 likes, 0 repeats
(Only exceptions: changing an HTTP 200 to 3xx.)
(DIR) Post #AkdaoGYwsCR272woz2 by colby@kosmos.social
2024-08-04T21:51:41Z
0 likes, 0 repeats
Everyone is allowed to cache any response permanently, gossip with other requestors about content they've fetched, and set up mirrors. That's how it's enforced—If you return content with signature f4b49585a78f on Monday but return something with a signature a233023ab1d5 on Tuesday, you're out of whack with the rest of the world which is still serving up f4b49585a78f. Clients treat your server as defective and keep trying other servers until they get the original.
(DIR) Post #AkdaoIytsgNlc76ZiC by colby@kosmos.social
2024-08-04T21:57:43Z
0 likes, 0 repeats
This is a radical departure from the way the Web works in practice—although NOT, it's important to note, in contradiction to anything about its actual design. Indeed, if you look at the original proposals for the Web, what I'm describing is a lot closer to what it was supposed to be for than what we got.And what I'm describing is completely in line with how pre-Web publishing worked. K&R 2nd edition is always K&R 2nd edition. There is no "change". There are only new editions.
(DIR) Post #AkdaoL4e6IAO6VoBwe by colby@kosmos.social
2024-08-04T22:03:05Z
0 likes, 0 repeats
If you inherit some infrastructure from a previous administration, you are required to maintain the identifier-to-content map for all extant identifiers.Your re-org doesn't matter. Your stack migration doesn't matter. Your résumé and professional ego don't matter.The only thing that matters is that when people refer to /foo/bar, they know what they're referring to, and they can continue referring to it that way, indefinitely.
(DIR) Post #AkdaoMzkxRRa3vXJbM by colby@kosmos.social
2024-08-04T22:23:22Z
0 likes, 0 repeats
The single most important contribution that the Web made to humanity was its use of "uniform" (machine-readable) identifiers. That's more important than anything else—more important than HTML and more important than the particulars of HTTP's request-and-response transactions and more important than the decision that these should be plain text. More important than _anything_ else.
(DIR) Post #AkdaoPGUWC1D6PNhxo by colby@kosmos.social
2024-08-04T22:25:02Z
0 likes, 0 repeats
And its single biggest flaw was allowing them to be variant (read: ambiguous), i.e., so that /foo/bar can refer to <this> on one day and then <that> on another day. It really works against the greatest potential for a system that is based around uniform identifiers.(See also another future rant of mine: "allowing response bodies for POST requests was a mistake".)
(DIR) Post #Akde2hXBgpvrgEhO2S by colby@kosmos.social
2024-08-04T23:21:42Z
0 likes, 0 repeats
@strypey no, see my other response to other people who said the same thing.
(DIR) Post #Aklw2sHh4eMnScMavo by strypey@mastodon.nzoss.nz
2024-08-08T23:21:05Z
0 likes, 0 repeats
@colby> no, see my other response to other people who said the same thingI had a look. Still don't really understand the problem you're trying to solve.
(DIR) Post #AknbbJQqw78emZ9CG8 by colby@kosmos.social
2024-08-09T18:41:13Z
0 likes, 0 repeats
@strypey the problem where I access example.com/foo one day and then I try to access it again tomorrow or in a week or a month or a year except it's gone (or has changed), or I try to give someone else the link, but when they visit, the server shows them something different.
(DIR) Post #AkqC266QaWk7vVaKTw by strypey@mastodon.nzoss.nz
2024-08-11T00:39:07Z
0 likes, 0 repeats
(1/?)@colby > the problem where I access example.com/foo one day and then I try to access it again tomorrow or in a week or a month or a year except it's gone (or has changed)This is only indirectly related to HTTP. It's fundamental to the nature of DNS.The correct page to find at example.com/foo is whichever one the people in control of the example.com domain say it is. Their ability to alter that page, or redirect to a different one, is a feature not a bug.
(DIR) Post #AkqCSFUwHMWGawWIEq by colby@kosmos.social
2024-08-11T00:43:50Z
0 likes, 0 repeats
@strypey not sure why you're fingering DNS here. If org A controls example.com in 2023 and publishes something at example.com/foo, then in 2024 they publish something else at example.com/foo, nothing about DNS is in play. The original org A just started returning a different work from the one they originally published there.(And that's definitely not a feature.)
(DIR) Post #AkqCveMSutw66ZZlcu by strypey@mastodon.nzoss.nz
2024-08-11T00:49:11Z
0 likes, 0 repeats
(2/2)It seems like you want the web equivalent of a library that never cancels a book, even if nobody ever reads it. Every web page ever created preserved in situ forever. Does the utility really justify the cost of maintaining this?Especially when we have ways to see what those people were pointing at with example.com/foo at a particular time. This is why people have developed tools like the WayBack Machine, archive.is, DOI (and its forerunner webcitation.org), the ArchiveTeam toolset, etc.
(DIR) Post #AkyDaMj4wYMEY1FO3E by strypey@mastodon.nzoss.nz
2024-08-14T21:34:12Z
0 likes, 0 repeats
@colby> not sure why you're fingering DNS hereDid you read both posts?
(DIR) Post #AkyIMztF2H65jGRghc by colby@kosmos.social
2024-08-11T00:49:37Z
0 likes, 0 repeats
@strypey imagine if you wrote a paper and cited example.com/research and then the folks who control example.com decided they weren't very much a fan of you and your work so they decided to "replace" /research and install something there that was less favorable to your interpretation of the results than the original (i.e. came up up with something else and started calling it the same thing, i.e., lied about the identities of both the original work and its "replacement").
(DIR) Post #AkyIN0pNY7bMdZe7Jw by colby@kosmos.social
2024-08-11T00:52:46Z
0 likes, 0 repeats
@strypey that's on par with what people regard as normal for the Web. It shouldn't be.There's an effectively limitless supply of URLs. There's no *good* reason to recycle them.
(DIR) Post #AkyIN1pPpTE1jyff16 by colby@kosmos.social
2024-08-11T00:55:54Z
0 likes, 0 repeats
(@strypey remember that the underlying cause for the loss of what we now know are lost films is because studios, etc. decided to recycle their tapes by recording over them because they deemed what was originally on there to be of not much importance. Compared to what webdevs do, those folks actually had good reasons for their actions. Media was expensive.)
(DIR) Post #AkyIN2auyrDs7Itb3g by strypey@mastodon.nzoss.nz
2024-08-14T22:27:40Z
0 likes, 0 repeats
(1/?)I've got an idea. How about we build archiving into CMS? So publishing a web page with links automatically triggers a fresh archive snapshot of the linked page(s).The CMS periodically does a diff of the current page at the URL and the archived version, to see if anything's changed. If it has, the author of the page linking to it gets a notification, showing them the changes. They can then redirect the link to the archived version with a single click if they want to.
(DIR) Post #AkyIN3IWMk6KIXIQ1Q by strypey@mastodon.nzoss.nz
2024-08-14T22:27:40Z
0 likes, 0 repeats
(2/?)@colby> Compared to what webdevs do, those folks actually had good reasons for their actions. Media was expensiveHave you ever hosted a website?Storage on servers costs money. Even if you own the server, you've got to swap out drives every few years as they start failing. Then there's the cost of making sure every URL under a domain name is preserved, every time you move from one CMS to another. Domain names cost money too, every year, which is fine if you're still using it, but...
(DIR) Post #AkyINBB14WqqjZqXR2 by strypey@mastodon.nzoss.nz
2024-08-14T22:27:41Z
0 likes, 0 repeats
(3/3)Making URLs permanent and unchanging would massively increase the cost and hassle of hosting a website. Which let's remember is a *free service* to the website visitor. Creating a situation where, for example, typos can't be fixed, and misinformation can't be corrected in the light of new information.All so people can avoid the minor hassle of using an archive system (also free of charge) to preserve a copy of a page on the day they referenced it.Yeah, nah. Not going to happen.
(DIR) Post #AkyJjzbkLoRdT6n85o by colby@kosmos.social
2024-08-14T22:43:10Z
0 likes, 0 repeats
"hAvE yOu EvEr hOsTeD A wEbSiTe?"
(DIR) Post #Al4bSIbbwW9jIfCTei by strypey@mastodon.nzoss.nz
2024-08-17T23:29:58Z
0 likes, 0 repeats
@colby> "hAvE yOu EvEr hOsTeD A wEbSiTe?"That is uncalled for sonny jim. I'll wager you were in nappies when I got involved in hosting websites.I've tried to engage seriously with a suggestion that, on the face of it, seemed profoundly ignorant of how internet protocols work. I thought maybe I was missing something. Seems I was right the first time and I've been casting pearls before swine.
(DIR) Post #Al5tnnr8wSd0dUpRuS by colby@kosmos.social
2024-08-18T14:30:04Z
0 likes, 0 repeats
@strypey k