@trwnh return to the document web :3

@trwnh much of this could be solved with server-side includes and/or XML+XSLT (since HTML was never “afforded” an include of its own) without whipping out a full-fledged site generator. I've been thinking about doing it on my site, but I can never find the time to work on it 8-(

@oblomov for the purposes of this argument i consider a script to be a dynamic site generator -- akin to a static site generator but dynamic instead

@trwnh in many ways, this is a fundamental design issue of the Internet, that it conflates two very different concepts, “what is this” with “where can it be found”

@oblomov i used to think this but i disagree now. a location is just a name that can be resolved. the abstraction needs to be reworked though -- instead of having the authority be a domain name, it needs to be able to be a prefix. "this is y according to x" can be expressed as http://x/y but the limiting factor is that we expect x to be a fully qualified domain name, always. if we allow prefixes, we can make relative references against a variable base, decoupling people from sites.

@oblomov basically the bad assumption is "x must be example.org" and the good assumption would be "x can be example.org/~user"

another way to look at it is that every slash in the uri path is in fact a delegation, and you can delegate or federate your identifier to another arbitrary resource. you'd do this with redirects and rewrite rules right now, but it could be made more streamlined and easier to manage and use?

say trwnh.com/mastodon is an alias for mastodon.social/@trwnh etc etc

@oblomov in other words http is in fact not location-based but name-based, it's the dns/ip system that ties it to location

@trwnh that's what I mean by conflation: http://x/y means both “y according to x” and “you can find this by contacting x and asking it for y”, with DNS telling you how to contact x. The x part doesn't need to be a FQDN, but it does need to be a resolvable (even if only locally) host name. I'm not sure what you mean by the prefix part, don't relative URLs already work that way?

@oblomov i mean if i ask for /foo/bar then i don't want to be limited to asking example.org for that. i want to be able to ask example.org/~user directly

the absolute expanded form is example.org/~user/foo/bar and NOT example.org/foo/bar

@trwnh oh I see what you mean here: we could keep using HTTP URLs, but we would have to allow them to be interpreted in a different way (not relying on DNS but having some other mechanism to tell “where can x can be found”). I think that's kind of what the nomadic identity proposals that have been made for the Fediverse try to resolve?

(Can't remember the FEP off the top of my head but you're probably already familiar with it.)

@oblomov nah, nothing to do with FEPs or nomadic identity. i mean "prefix" in the literal most direct sense: a completely opaque string with which a URI begins

basically the HTTP server at example.org has to recognize that for all paths starting with /~user that they might redirect or proxy to somewhere other than a local filesystem

every HTTP server is then a name resolver, because the actual final location is irrelevant

@oblomov

current behavior analogy:

GET /foo/bar
Host: example.org

desired behavior analogy:

GET /foo/bar
Base: https: //example.org/~user

@trwnh In a way that part was solved decades ago with iframes: have the header/navigation persistent in one file, and load the different pages, however different they look, in a frame.

@oblomov this is basically ark:// instead of http:// or https:// but you could do the same thing with a petname system: dns -> example.org -> https -> /~user -> /foo/bar

@nclm shame about the security risks

@trwnh Yea, I'm no engineer but I wonder if we could have kept iframes for authoring but have browser makers fixing stuff so that they are more secure / more accessible / whatever were the issues.

@trwnh OK I'm starting to see what you mean, but that still ties user to example.org, and can (and in fact often is) already achieved with subdomains (user.example.org). But this is still tied to example.org so it still delegate to organization before people. I think this might be what I found confusing. If the intent is prioritizing people, wouldn't make the authority part be the user id directly?

@oblomov the authority of example.org/~user depends on the authority of example.org but that's covered by delegation. as far as the top-level resolution you could use something like ark or otherwise retool http(s) to allow user@host.example as an authority component (basically redefining the user component from http basic auth to instead being something else) but that's not the point really. you have a resolver and you have a set of mappings and map prefixes to whatever. just like rdf or n2t

@oblomov wikipedia:James_Joyce might redirect to https://en.wikipedia.org/wiki/James_Joyce and in this case the prefix `wikipedia:` maps to `https://en.wikipedia.org/wiki/`

for a personal web what you'd need to maintain is a mapping of some sort, from people in your address book to some uri prefix they currently own

say i want to resolve (me) -> wikipedia -> James_Joyce, this is an equivalent path to (dns) -> en.wikipedia.org -> https -> /wiki -> James_Joyce

@trwnh@mastodon.social What's become of frames? ​​