Agreed. Substack is a point solution for harvesting the end-of-life blog market into the email ecosystem, which seems more robust/long-lived. It is less a successor to blogging than a sort of upmarket retreat for blogging being disrupted by threaded open media
Conversation
Really, that's what you're talking about Tom. My elderblogging personal phase just happens to synchronize with the elder stage of the medium itself. Of the 2 dynamics (me getting old, blogging getting disrupted by threading), the latter is the more important one obviously.
1
1
For sure - but you're "crashing" first as the canary in the coal mine for the rest of us. A useful point of study.
2
3
I think what I'd *like* to do is port ribbonfarm to a site where pre-blogchain stuff is rendered as a bunch of legacy static pages forming a sort of background, blogchains are rendered as native threads weaving through it, and there's support for a new roam-like thing
1
4
What we're running into here is a need for a multi-architecture publishing: books, blogs, wikis, threads, and my latest obsession, short glossary-like log-level entries. Kinda like Intel's OneAPI is trying to make a single interface for many architectures. software.intel.com/en-us/oneapi
1
4
Yeah - aligns with the "headless CMS" idea except that world is deficient in imagination. It's not headless CMS so that you can reskin the front end it's headless cms so you can merge blogs, books, wikis, threads, roam etc
1
2
unfortunately, all this is technically way beyond me to set up on an experimental basis so I'd need someone to invent a scheme basically. Until then, I'm sitting around in wordpress.
1
1
The one thing I'd add to this vision is a politics... I'm old fashioned enough to think that the successor to blogging should be an open standard that multiple products could meet rather than a single product (no matter how well executed)
1
2
Technically, we seem to be poised at a sort of "big data" moment for content. 10 years ago, if I had posed the problem above, people would have said "drupal with a lot of custom node models". Now that seems like far too heavyweight approach and exactly the wrong direction.
2
2
A sort of nosql approach... platform independent content-centric networking. Content nuggets that can live in a big data lake (=domain) and sustain a consumption "ship" sailing around on it. A better client, not a better server. Browser 2.0 that's aware of content architecture.
static page paradigm already unbundles the backend and JIT compiles it to browser front-end. What we need is a way to intercept that process with domain-level information architecture cc
ribbonfarm should be a set of pipe logic rules, not a server db and a skin
3
3
Yeah agreed there's some nontrival tech to unbundle and re-build here to make all this work (and unfortunately the first version will likely be a closed system rather than being open...)


