Hey Jacob I would definitely be interested in working more on platypub! I’ve learned a lot with the few PRs I’ve done and would love to take it over

that would be wonderful :) I did some more thinking last night and I think a good initial featureset for "platypub 2.0" (or more like 0.2) would be: • support "import plugins" for syncing external content into XT + object store (s3 or file system, depending on user configuration). platypub doesn't need to have any official plugins necessarily; for now users can write their own. these could be plain biff plugins that define scheduled tasks for syncing content. or in some cases it may be good enough to just let the user trigger syncing via the repl. • no built in cms--users can pick whatever headless cms they want and write an import plugin for it. (I guess it may not be a bad idea to provide a built-in plugin for at least one cms, since that's essential functionality) • "theme plugins", like import plugins, can be regular Clojure code. no need to use babashka or worry about sandboxing. theme plugins take data from xt + object store and write it to a directory. maybe want to have this happen automatically whenever a sync plugin runs + whenever you save a source file in the theme plugin. no need to provide a default theme, except maybe an extremely rudimentary one, just an at implementation guide. • previewing and deploying: just use the netlify cli tool. • newsletters: make some functions for interacting with mailgun etc via the repl. at minimum, need to (1) render the email and display in the browser, (2) send a test email to a given address, (3) send email to the whole list. also might as well add support for scheduled sending. mailgun handles that; you just need to give it an extra parameter when sending to the list. it would be kinda nice to have some other doodads too, like printing out # of recent subscribers, and fetching a list of subscribers that keep bouncing so they can be removed from the list. nonessential though. I have some code in the sample for the latter. • running platypub: users create a starter app that depends on platypub, maybe from a template. kind of like the starter app template for biff. but a big difference is that the entry point/main namespace would be in the platypub lib rather than in the user's project. the user can put custom sync/theme plugins in their app project. if they want to share any plugins, those can be moved into separate libs. • config, e.g. what plugins to use, and site config: maybe just put it in config.edn. idk • schema: for now no need to have platypub impose any schema. I guess that's how it works now. but currently there is some complexity in that theme plugins have to define the schema explicitly and communicate it to platypub, so platypub can use it for generating the CMS ui. also having themes define explicit schema theoretically means you can switch between different themes easily as long as they share the same schema. for now, we can leave schema to the CMS. no need to worry about sharing themes--assume that users define their own schema in their CMS and write their own theme plugin which understands that schema. that's what I've got in my head so far at least! there will be plenty of blanks to fill in I'm sure. also take all of these as suggestions--you can do whatever you want. I would start by picking a cms. three I want to try out are sanity, statamic (I always read that as "satanic") and craftcms. each of those would be good for allowing people to define whatever schema they want. for people who are fine with a standard posts + pages schema, WordPress or ghost would be fine and perhaps ideal. I'm not sure which camp I'm in yet. After that you can start a new biff project and start working on proof-of-concept stuff for the features above. I wouldn't worry too much about architecture yet; just get the functionality there and then think about how to structure it afterward. probably can copy some code from existing platypub, at least for newsletter stuff. you can make your own repo for this if you like, and when it's ready I'll put a note on the current platypub repo to use that instead. I'll probably send you PRs occasionally :). I might actually be able to spend some time on at least getting to the proof-of-concept stage, since I really would like to use this for my own sites soon. also after all that stuff is in place, we can gradually start thinking about what a more finalized version of platypub might look like--e.g. how to make it easy to provide a hosted version that anyway can use without needing to self host or write code, and also how to facilitate a plugin ecosystem where themes can be reused and stuff

for me, main thing for cms is it needs to be easy to add media--for that reason I don't like using a text editor + plain markdown files as is common with many static site generators

Nice! Maybe we can zoom sometime to talk through in more detail? I’ve heard of those CMS you mentioned but I’m not very familiar with their features

Sure, I'll DM you. I'm also not terribly familiar; other than wordpress and ghost I haven't actually used them. I'm basically just assuming that they're kinda like airtable, where you set up your own structure and then you can enter in data/content...

I used Statamic and CraftCMS when they came out 10 years ago! They both spawned out of ExpressionEngine CMS community, which had more progressive open-ended schema and ui control than Wordpress or Movable Type at the time; but was stalling out due to technical debt and mismanagement i guess. I cant speak to their status now. I got so frustrated with those PHP monoliths that I sought out and went directly into Clojure (without a CMS to back me up :) I’m sure they are very polished and api friendly now. (Comparable to airtable) I still inherently distrust any CMS software though, from those experiences. All the insane complexity that was wrought for just trying to have some wysiwyg ui! And also the gravity of many of these systems centering on post/picture/headline as the default supported schema… Give me a repl, ui framework, and transparent data! I think many domains are so specific we must think in terms of apps instead of monolithic CMS for progressive content flows. Im currently working on a wordpress site, and was initially seduced by the newer Gutenberg block editing system. Its pretty slick and powerful, but then i find myself paying the price of all these micro-abstactions when i need to customize them, and debugging the verbose code they generate. Of course separating the content managemebt from the front end stack can aleviate a lot of this. Ps. Statamic was named so because it was trying to put more of the state into “static” files (yaml, etc) and step back from all of the forms+db-query wrangling)

I am particularly interested in getting back to content production, and maybe using biff/platy/xtdv as a CMS im not boxed in by. Also the dream of multichannel publishing. I encourage all your work in this direction

Ah very informative! I'm definitely interested to play around with a few CMSes and see how they feel. Maybe in the end Platypub's current minimalist CMS will be the best way to go anyway.

> Also the dream of multichannel publishing. Can you elaborate more on that? Like, publishing to website + newsletter + social media automatically? I've mainly/only done publishing in the personal blogging sense; if you're coming at it more from the business side, I'd be curious to hear more about the difficulties there etc

I just mean broadly.. A CMS separates content from presentation structure. One goal is to enable formal backend workflows like multiple users, permissions, versions, validations, etc. The other is to re-use the content in different presentation structures. The dream of DRY. This is goal often falls down on 2 levels: 1) the default CMS schema (and consequently, UI) is to basic or rigid to account for demands of alternative channel presentation structures (blog, rss, twitter, video, “moment”, for-sale listing, etc) . 2)The channel structures supported by the the cms are too limited, expensive, or complex (overloaded plugins with paywalled features, messy DIY integrations) to take as a direct first class publishing experience in the CMS. I think for me the dream is that the CMS is that it is your home base UI, where you can see and touch your stuff; and also that it is adaptive enough for any content model and progressive UI workflow you might need, but simple and flexible enough that you’re not beholden to someone else’s notion of a domain schema, or just careless arbitrary technical limitations of someone else’s implementation of a plugin or baked in integration. So I guess this is some kind of expression of the lisp curse. And also the appeal of total DRY that functional programming teases at. Building on Clojure and having a repl satisfies a lot of this. In fact, having a local repl environment all tooled out with accessory UI like Portal, Clerk, etc; and also easy scripting stuff like Babashka, NBB, + enough cool libs and web services… is one vision of this. It might even be one of the most progressive visions, because through local tooling there is more access to “direct manipulation” of data through UI. This mode is so powerful and necessary for content editing. And it’s hard to get it in place without 1) having dynamic runtime (like a repl) or 2) building a monolithic “App” (like a video game) Conventional WYSIWYG UI widgets are working attempts at allowing direct manipulation. They are just traditionally implemented very poorly on the web because of complexities of web stack and distributed systems (latency, etc); Example: TinyMCE html editor + reload view in another window (with other css). I haven’t used it, but I imagine systems like WebFlow are challenging this (my experience with Wordpress Block editing has been underwhelming, but better than it was before). Whatever the creative environment, ultimately having it hosted on a server is usually necessary, as it enables network effects. (look at Figma vs Photoshop) And either way, the beginners in the the community feel the need for a framework to hold our hand to get an architectural footing. ….So I commend your efforts to gel some of this stuff, from an open developer-centric perspective, on the server.

Thanks, that's helpful. This actually makes me lean back towards keeping support for fully-customizable schema within platypub's native cms--I've been thinking lately about switching to a mostly fixed schema, with support for letting people "eject" to an external headless CMS if they need more customization. But maybe it wouldn't hurt to leave the customizable in... something to think about at least.