i have to conclude that the biggest barrier to entry to the personal web, aside from obtaining access to hosting, is the expectation that every page on a website has to look the same, be styled the same, have the same navigation menu, and so on.
-
i have to conclude that the biggest barrier to entry to the personal web, aside from obtaining access to hosting, is the expectation that every page on a website has to look the same, be styled the same, have the same navigation menu, and so on. it’s just so much easier to write the html for a page once, and then never update it again. the very instant you introduce an expectation of retroactive consistency, you now require a site generator or a build system. that’s a big ask!
-
i have to conclude that the biggest barrier to entry to the personal web, aside from obtaining access to hosting, is the expectation that every page on a website has to look the same, be styled the same, have the same navigation menu, and so on. it’s just so much easier to write the html for a page once, and then never update it again. the very instant you introduce an expectation of retroactive consistency, you now require a site generator or a build system. that’s a big ask!
the other thing that’s a problem is that that web authority is conceived of in terms of web origins and domain names, not in terms of namespaces or uri prefixes. dns as it is currently used enshrines *organizations* over *people*. if you want long lived links that resist link rot, you need to pick a domain name and stick with it, and this has an upkeep cost. orgs can more easily manage this upkeep cost, people have a harder time with it.
-
i have to conclude that the biggest barrier to entry to the personal web, aside from obtaining access to hosting, is the expectation that every page on a website has to look the same, be styled the same, have the same navigation menu, and so on. it’s just so much easier to write the html for a page once, and then never update it again. the very instant you introduce an expectation of retroactive consistency, you now require a site generator or a build system. that’s a big ask!
@trwnh return to the document web :3
-
i have to conclude that the biggest barrier to entry to the personal web, aside from obtaining access to hosting, is the expectation that every page on a website has to look the same, be styled the same, have the same navigation menu, and so on. it’s just so much easier to write the html for a page once, and then never update it again. the very instant you introduce an expectation of retroactive consistency, you now require a site generator or a build system. that’s a big ask!
@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-(
-
@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
-
the other thing that’s a problem is that that web authority is conceived of in terms of web origins and domain names, not in terms of namespaces or uri prefixes. dns as it is currently used enshrines *organizations* over *people*. if you want long lived links that resist link rot, you need to pick a domain name and stick with it, and this has an upkeep cost. orgs can more easily manage this upkeep cost, people have a harder time with it.
@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”
-
@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 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 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
-
@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.
@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?
-
@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
-
@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 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.)
-
@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 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
current behavior analogy:
GET /foo/bar
Host: example.orgdesired behavior analogy:
GET /foo/bar
Base: https: //example.org/~user -
i have to conclude that the biggest barrier to entry to the personal web, aside from obtaining access to hosting, is the expectation that every page on a website has to look the same, be styled the same, have the same navigation menu, and so on. it’s just so much easier to write the html for a page once, and then never update it again. the very instant you introduce an expectation of retroactive consistency, you now require a site generator or a build system. that’s a big ask!
@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.
-
current behavior analogy:
GET /foo/bar
Host: example.orgdesired behavior analogy:
GET /foo/bar
Base: https: //example.org/~user@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
-
@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.
@nclm shame about the security risks
-
@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.
-
@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
@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?
-
@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