> If we stored the edges (links) and nodes (pages) separately, rather than requiring you to blindly run a node's code just to discover what its edges might be, then you could skip the prediction and instead pre-cache the next hop for all edges just in case you follow one. You could even do this to two or three hops.

Welcome to Next.js

Can next.js give me a page's links without requiring that I execute any code that I didn't have prior to visiting that page?

The .js part makes me think not.

Speculative Rules API

  <script type="speculationrules">
  {
    "prefetch": [
      {
        "source": "list",
        "urls": ["/checkout.html", "/thank-you.html"]
      }
    ] 
  }
  </script>

Right, but my browser doesn't interpret that. The site tells me to run some code which interprets it.

I should be able to get the lay of the land without trusting the site enough to blindly execute whatever code it points me at. It's needless attack surface.

Also it's not really pointing me at data, its pointing me a certain kinds of requests which I have to trust will be responded to consistently. I'd much rather have a hash so if I have that data lying around I can just forgo the request entirely and use what's present locally.

That is a browser API, there is no other code or script needed.

>but if the web were content addressed instead of server addressed you could then be serving that cache to your municipality even after it became disconnected from the rest of the internet.

This is already possible without content addressing with CDNs. They can serve content from a local cache even when the host is disconnected from the internet.

And the first thing webdevs did once this became widely available, is change their apps to cache-bust their code; between that, and the short release periods in webshit ecosystem in general, and security and privacy considerations messing up things as usual, the promise of users mostly hitting just local cache with any marginal request, never materialized.

Without content addressing how do I know that whoever holds the cache hasn't tampered with the content?

The integrity attribute of the <link> element lets you provide a hash to ensure the content has not been tampered with.

Interesting. Is this common? Like, is there some way to enable it on my LAN so that when I become disconnected from the internet I can still browse pages which were cached by other devices on that LAN?

It's part of the HTML on the page. It has nothing to do with your LAN.

We have that, it's called an <a> tag.

Its not stored separately, so:

1. You need write access to the server if you want to add one

2. The server could change its behavior at any time and there's no way to know that caches now need to be invalidated

3. If something goes wrong with connectivity or name resolution, there's no fallback since the authoritative thing was not something durable like a trusted human via a public key but rather an ephemeral thing: a named server which has pinkey promised to stay online.

It asks the user to treat a server like a trustworthy source of perisisant data.

But there's no reason to couple these kinds of trust. The skills necessary to persist and traffick data are orthogonal to being trustworthy about content. Coupling them creates needless load on single sources of failure which are simultaneously single points for corruption to target.

Trust people, not servers. Use digital signatures to validate that what you're seeing came from those people.

<a> tags are the opposite of this. They encourage us to trust servers by name, which isn't really working out.

You want people without write access to a website to be able to change how browsers access that website?