8 ms·

Two under-utilized properties of URLs are also that: - there's a near-infinite supply of them - they support forward declaration Together the practical upsho

by cxr 2y ago

Two under-utilized properties of URLs are also that: - there's a near-infinite supply of them - they support forward declaration Together the practical upshot is that if you're having a conversation with someone or responding during the Q&A of a talk or whatever and you want to be able to say, "Yeah, we thought about that, and we have some information about it on our site—just visit acmeinitiative.example.com/skub," except that you haven't already written the /skub article yet, that doesn't preclude you from being able to say in the moment (i.e. live) that /skub is effective immediately now the designated handle for such an article, it's where the article will appear once you do write it, and it's how any interested party should retrieve it once it does appear—whenever that is. (The same goes for articles published by other people/organizations and other third-party resources that you want to reference—just mint a URL from your namespace on-the-fly and then whenever you get a chance, set up a redirect to whatever it is you wanted to link to.) There are so many recordings (podcasts episodes, etc.) that I've listened to involving smart, technical people who definitely control their own domains but don't think to take advantage of this. Usually they sort of mumble some description that you might be able to use to find whatever they're talking about, or they manage to only get half the words in the title wrong when they're trying to recall it for the host, and then you and every other interested listener has to individually squander time and attention if you want to track it down. It results in a huge waste of collective energy.

DelightOne 2y ago
The UX is not good enough yet. We would have to 1) show that it is reserved to people going on the link and 2) offer good/enough ways to be notified once the link becomes online and 3) need to know the likelihood of the link to actually work in the future based on prior commitment. AND I probably forgot a couple of issues.
- kevindamm 2y ago
  ...and URLs being forever cuts both ways. Want to reorganize your domain's structure? Better set up 301s to forward the old address, forever, and hope (or avoid) any overlap between the old schema and the new. Transfer of ownership? Well, all those hyperlinks from other sites don't know.
- csh0 2y ago
  I think the idea is that if you were recording a podcast it wouldn’t be live (I know the parent used the word live but I think they meant “live” during recording or in conversation while the episode is being created), so you are free to make references to soon to be declared URLs. You just have to make sure you have populated the content at the location you are referencing before you upload or publish your episode for your listeners.
  - cxr 2y ago
    > You just have to make sure you have populated the content at the location you are referencing before you upload You don't even have to do that, though. It suffices to say, "I'll wire these things up on Monday."
__MatrixMan__ 2y ago
This is not a criticism of URLs per se, but I find it troubling that the mere act of visiting one is something that we have to warn people away from. It's like: > Don't eat moldy food, else you'll get sick (unless it's bleu cheese, yum) Ok, that sounds like good advice, and easy do follow. > Don't look in the direction of modly food, else you'll get sick That's unreasonable. What kind of madman wrote the rules for this universe?! When I try to imagine a better way, it usually disallows the referents of a URL-equivalent from changing after they're created--that way trust bestowed once can be reused without prompting the user a second time for the "same" thing. For that reason, I'm not a fan of placeholder URL's like you're describing. The instability of URLs to me feels like more bug than feature.
- deleted 2y ago
  [deleted]
- cxr 2y ago
  I don't know what you're talking about at the end, but you're definitely applying an inconsistent (double) standard at at least one point in your comment. The status quo is one where the reference is either completely unresolvable, or the referent accessible only after some effort that would have been better avoided. Forward-declared identifiers don't exacerbate any of these issues. Meanwhile, the set of things ameliorated by them is non-empty.
  - __MatrixMan__ 2y ago
    Basically I'd rather be using cryptographic hashes of the page instead of URLs so that if I trust the hash then I have an obvious mechanism for determining if I should trust the payload that the hash refers to. Stability like that would severely limit the places that a malicious payload could hide, and it would enable users to compare notes about what is or is not trustworthy. If the identifier can exist before its referent, then any such verify-the-payload-given-the-id activity becomes much more complicated because we now have to wonder if we're getting different versions of the page for the same identifier (e.g. like when airlines present different prices based on which browser you've used even though you used the same link in each. I'm trying to dream up a web where that's not possible).
swyx 2y ago
as a podcaster i feel this, but 1) its hard to look up precise references without interrupting conversation flow (im optimistic llms will help here) and 2) some people would want to tell u to search their name more because that helps The Algorithm
- cxr 2y ago
  It's like you didn't understand anything that I wrote.

by cxr 2y ago

DelightOne 2y ago

The UX is not good enough yet. We would have to 1) show that it is reserved to people going on the link and 2) offer good/enough ways to be notified once the link becomes online and 3) need to know the likelihood of the link to actually work in the future based on prior commitment. AND I probably forgot a couple of issues.

kevindamm 2y ago
...and URLs being forever cuts both ways. Want to reorganize your domain's structure? Better set up 301s to forward the old address, forever, and hope (or avoid) any overlap between the old schema and the new. Transfer of ownership? Well, all those hyperlinks from other sites don't know.
csh0 2y ago
I think the idea is that if you were recording a podcast it wouldn’t be live (I know the parent used the word live but I think they meant “live” during recording or in conversation while the episode is being created), so you are free to make references to soon to be declared URLs. You just have to make sure you have populated the content at the location you are referencing before you upload or publish your episode for your listeners.
- cxr 2y ago
  > You just have to make sure you have populated the content at the location you are referencing before you upload You don't even have to do that, though. It suffices to say, "I'll wire these things up on Monday."

__MatrixMan__ 2y ago

This is not a criticism of URLs per se, but I find it troubling that the mere act of visiting one is something that we have to warn people away from. It's like: > Don't eat moldy food, else you'll get sick (unless it's bleu cheese, yum) Ok, that sounds like good advice, and easy do follow. > Don't look in the direction of modly food, else you'll get sick That's unreasonable. What kind of madman wrote the rules for this universe?! When I try to imagine a better way, it usually disallows the referents of a URL-equivalent from changing after they're created--that way trust bestowed once can be reused without prompting the user a second time for the "same" thing. For that reason, I'm not a fan of placeholder URL's like you're describing. The instability of URLs to me feels like more bug than feature.

deleted 2y ago
[deleted]
cxr 2y ago
I don't know what you're talking about at the end, but you're definitely applying an inconsistent (double) standard at at least one point in your comment. The status quo is one where the reference is either completely unresolvable, or the referent accessible only after some effort that would have been better avoided. Forward-declared identifiers don't exacerbate any of these issues. Meanwhile, the set of things ameliorated by them is non-empty.
- __MatrixMan__ 2y ago
  Basically I'd rather be using cryptographic hashes of the page instead of URLs so that if I trust the hash then I have an obvious mechanism for determining if I should trust the payload that the hash refers to. Stability like that would severely limit the places that a malicious payload could hide, and it would enable users to compare notes about what is or is not trustworthy. If the identifier can exist before its referent, then any such verify-the-payload-given-the-id activity becomes much more complicated because we now have to wonder if we're getting different versions of the page for the same identifier (e.g. like when airlines present different prices based on which browser you've used even though you used the same link in each. I'm trying to dream up a web where that's not possible).

swyx 2y ago

as a podcaster i feel this, but 1) its hard to look up precise references without interrupting conversation flow (im optimistic llms will help here) and 2) some people would want to tell u to search their name more because that helps The Algorithm

cxr 2y ago
It's like you didn't understand anything that I wrote.