Conversation

Replying to and
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
2
4
Replying to and
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
Replying to and
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
Replying to and
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
Replying to and
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
Replying to and
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
Replying to and
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
Replying to and
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.
Replying to and
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