It's weird — we, the builders of HTTP-based APIs, very well understand the concept of "REpresentational State Transfer" ...but I've never seen a web-app server that actually accepts PUT or PATCH or POST of HTML Content-Type against the baked-out server-rendered HTML views, such that if you were to push a modified version of said representational state (the post-edit HTML), it would get "decompiled" on the backend into a delta of the internal state (e.g. Markdown in a CMS), and that change to the internal state would get persisted, reflecting back as a change in the representational state when the page is fetched.
If anyone would just actually implement that on a web-app backend, then you'd be able to "annotate, edit, and extend" HTML-presented content using freakin' NSCA Mosaic from 1993. Or the "edit in Frontpage" feature of IE4.
(No modern equivalents, though — the features that would generate a "native" browser PUT or PATCH against an HTML page have since shrivelled up and died, after it became clear that no server would ever bother to allow them.)
To dodge the chicken-and-egg problem of browser support, you could do this today, with a Javscript SPA serving the browser role: the frontend app would ensure that it's reflecting all internal state changes in its in-memory client-side internal state into changes to the HTML (even if those changes don't cause any presentation changes on the client side); and then, where a regular SPA would push those changes by calling an API endpoint that accepts a version of its in-memory client-side internal state, this SPA would just push the updated HTML, as a PUT or PATCH to the very same URL that was loaded to deliver the SPA.
I'm not sure about others but I'd prefer my extended brain not live on other people's servers. The Memex always seemed to me to be a personal archive and notebook. You would pull in material from outside and store it locally along with your links and annotations and then only publish the work that you wanted to make public.
It's weird — we, the builders of HTTP-based APIs, very well understand the concept of "REpresentational State Transfer" ...but I've never seen a web-app server that actually accepts PUT or PATCH or POST of HTML Content-Type against the baked-out server-rendered HTML views, such that if you were to push a modified version of said representational state (the post-edit HTML), it would get "decompiled" on the backend into a delta of the internal state (e.g. Markdown in a CMS), and that change to the internal state would get persisted, reflecting back as a change in the representational state when the page is fetched.
If anyone would just actually implement that on a web-app backend, then you'd be able to "annotate, edit, and extend" HTML-presented content using freakin' NSCA Mosaic from 1993. Or the "edit in Frontpage" feature of IE4.
(No modern equivalents, though — the features that would generate a "native" browser PUT or PATCH against an HTML page have since shrivelled up and died, after it became clear that no server would ever bother to allow them.)
To dodge the chicken-and-egg problem of browser support, you could do this today, with a Javscript SPA serving the browser role: the frontend app would ensure that it's reflecting all internal state changes in its in-memory client-side internal state into changes to the HTML (even if those changes don't cause any presentation changes on the client side); and then, where a regular SPA would push those changes by calling an API endpoint that accepts a version of its in-memory client-side internal state, this SPA would just push the updated HTML, as a PUT or PATCH to the very same URL that was loaded to deliver the SPA.