it is approaching end of year (3 days left) and my website is not ready yet like i wanted. i am kind of in a bit of a rut and seeking inspiration or enlightenment on how to make the publishing and resource management workflow as easy and low-friction as possible. sort of wondering if it makes more sense to be web-native (html documents with https uris) or instead treat the web purely like an interface or gateway into some other datastore (filesystem, rdf graph, etc)

there's some fundamental questions i don't really have a satisfying concrete answer to, namely around things like "what is a resource really" and "how do you identify things independently of protocol and scheme"

i am vaguely trending toward something like this:

- the basis should be Content, and it should be Content-Addressed
- on top of this is Metadata, which describes Content. a set of Metadata is a Description.
- you can bundle some Content and Metadata by using a "body" and "header"...

- if you want to make something mutable, then you need to give it another identity other than the content-addressed one, and this identity functions like a pointer or reference. let's call the identity a Name, and the mutable referent a Thing
- because of the inherent nature of mutability, you *need* to do maintenance on your identity resolver. basically you have a Name to Thing service which acts as a lookup table, and you need to check for stale references and fix them...

so basically the web-native approach is akin to a Name to Thing resolver where all names are https uris and all things are more or less html documents. this is the Hypertext Web, which is commonly known as just "the" Web

but we can go beyond that by using redirects, virtual resources, and so on. in this approach, the Web is not strictly a web of hypertext *documents*, but instead a web of hypertext *views* which serve as a presentation layer on top of some abstracted data source...

the View in this case is the understanding that the document returned over HTTP is actually always "virtual", and is being generated by the server application, even if the underlying mechanism is as simple as "read this text file and dump its contents over the network connection".

in other words, you are not linking directly to documents. you are necessarily passing through a translation layer of Name to Thing. and this is accomplished by the View. all resolution is mediated by some application

but this is as far as i've gotten right now. i am less sure where to go from here.

i am aware of ARK and n2t, but i'm not sure how to best handle assigning Names to Authorities, who can then assign sub-Names to Things. the way ARK does it is to have you fill out a form requesting a NAAN (name assigning authority number), and the way DNS works is you pay a registrar to rent a domain name. the specifics of managing Authority is something i want to think about. both ARK and DNS have problems...

really this is due to what i am going to refer to here as the "root of identity", which is the idea that at some basic level you can refer to anything by either some intrinsic quality or some extrinsic label, and ideally it would be something stable and unchanging; invariant. of course it matters who you ask to resolve the identifier. this is typically the Authority. the Authority stems from some trusted registry, or otherwise from some cryptographic assertion. you have to trust at least one...

if you trust a registry then that's the easier of the two options. if you trust cryptography then you need to assert links between identities. and PKI, CA, etc stuff is its own entire world of issues.

---

the other thread i haven't fully traced out is the idea that you can not only bundle Content and Metadata in a body+header struct, but you can then nest this struct as the body of a new struct, with its own header.

and in reverse, you can unwrap each layer until you have only Content.

@trwnh@mastodon.social perhaps you need to consider whether you are overcomplicating matters when you post about making content management "easy and low-friction" and then the ensuing thread ends up here

in this hour you could have decided on a storage structure and began writing the server

so now it's time to come full circle.

the structure of an HTML document is inherently binding Content (inside the body) with Metadata (inside the head). and the structure of an HTTP message further binds this document as the Content (request/response body) of some 2nd-order Metadata (the HTTP Headers).

this is exactly what makes me wonder if it isn't more natural to just treat all "websites" as a kind of "webapp" that basically just wraps Content with a presentation layer (layout, etc).

@natalie well i'm using hugo as a static site generator but i am running into issues at the worldview-and-metaphysical-reality level while trying to grapple with issues like link rot and permalink structure (which is not a problem i am going to solve in one hour)

@trwnh@mastodon.social doing literally anything is better than bikeshedding with no end in sight

@natalie the question is more "what do i want to do" because on one hand i could simplify my whole workflow to "rsync this folder of static html files" and it still wouldn't be as simple as i'd like it. going any further than that would require more complexity upfront which i am trying to reason through, within the confines of http and html. it's a matter of philosophical approach -- i need a data model and metamodel that accounts for both hypertext as well as linked data (and presentation too).

@natalie yeah i built most of a website already. i could just push it live. but it wouldn't be any less fragile than anything i've built before up to this point and abandoned eventually. i want to figure out why that is, and what i can do to make it better