Half of Platypub's purpose has been to provide an open-source Biff app for people to study and hack on, but it would be a little hollow without the other half of actually being a useful piece of software. (I mean, it is useful already; I use it all the time--but it's not as useful as I want it to be.) And realistically: I think I'll never run out of code/docs to write for Biff itself; perhaps better I focus on that anyway and leave Platypub to the community, for anyone who wants to build it. As I get my own publishing system figured out, I can at least provide some guidance for how I'd go about developing Platypub if I had the time. If there are people who'd like to collaborate on a community-driven Biff project, that might be more fun anyway!

(I should probably stick a notice about this on the platypub readme)

I've been thinking about this a lot; cataloging some of my thoughts here. some of this, @joerter and I have been discussing. overall, I'm thinking no need to abandon the current platypub app actually. but I think we should at least do a proof-of-concept for the theme system before diving into doing much coding on platypub repo. schema I'm pretty sure fixed posts-and-pages schema will be fine. I've been thinking through what I'll want my own site to look like once I redo it, and I don't think I'll have any needs that necessitate custom schema. may want to do some tweaks from the current schema, but it can probably all be stuff that would be generally applicable. I was wondering if maybe we should have fixed schema for posts and pages but still support custom schema for sites, which is actually how platypub used to do it. then themes can still have some custom settings without needing to make users go all the way to custom-cms-and-import-plugins. that might be the way to go, but I'd also like to see if even fixed schema for sites could be likely good enough for most themes. off the top of my head, some things we might want to have in the site schema: - primary color - accent color - profile image - cover image - logo (perhaps in a few different form factors) that (and various other mundane bits of metadata, like the site title etc) I think would be enough for my own needs. import plugins support plugins that can sync external data. this has two benefits: (1) if you really need custom schema, you can set up an external cms and sync the data to platypub with an import plugin, (2) you can publish data that comes from anywhere else on the internet. e.g. I'd like to have an import plugin that pulls all the forum posts from this server, so they can be rendered on my site somewhere/in various places (more on this later perhaps). (continued)

no need to try to let import plugins put data in some kind of standardized schema. each import plugin will have its own namespace in the database, and the import plugin owns its own schema. to use data from an import plugin, you'll have to use a theme that is written to support that specific plugin.

theme plugins basically what I've been thinking for a while: theme plugins are defined as docker containers which spin up a web service. that web service implements a standard protocol for rendering a site--platypub POSTs the data, the web service returns a zip file or whatever of the site. probably want to support rendering individual pages one at a time as well. platypub uses Fly Machines to deploy the docker containers. in the site settings, you can type in the name/location of a docker image/docker file (maybe we assume the image is on docker hub?). for development, you can alternately put in an https url, in which case platypub uses that as the base url for the site rendering api. so you can run your theme plugin locally, expose it via ngrok, and paste the ngrok url into platypub.

rich text editor I'm not sure what's best. tinymce is alright, but I have had a few annoyances where I paste in something but then it turns out it's a instead of a , or it has classes on it, etc. maybe markdown wouldn't be so bad after all, as long as we use an editor that renders the markdown immediately (inline or side by side). I'd like to see if there's anything that could be done with tinymce or another wysiwyg editor--maybe it can be set to strip formatting from/normalize pasted input, which might be good enough to solve all my problems. 🤷 On the other hand I also like the idea of supporting custom markdown shortcodes. e.g. let themes define their own shortcodes maybe. then themes could let you make fancier pages, still without needing custom schema. and without having some complex block editor thing. another thing to experiment with.

overhaul the ui it'd be nice to make it look nicer and have better structure and stuff. this'll be easier without the need to support custom schema.

api keys realistically I think letting users send email from a shared mailgun account will be infeasible unless someone wants to run a platypub instance as a business. I certainly don't want to spend my free time dealing with spammers. I think we should plan on telling people that they'll need to set up their own mailgun account. maybe even support other ESPs, like SES. have an account settings page where people can paste in their api key. that goes against my desire to have platypub be suitable for a wide audience, but... maybe that isn't really that important of a goal. e.g. https://postcard.page actually makes a great default recommendation for anyone who wants to set up their own site/newsletter for the first time. the benefit of platypub is that it gives you as much control as you'd have if you coded the whole site up from scratch, while making it a lot more convenient than actually doing that. and people who care about having total control over the site probably wouldn't mind the idea of owning their sending domain etc anyway 🤷. in the same vein, maybe we should even tell people to bring their own netlify key? something to think about. (eh--providing hosting via a single netlify account will be a lot easier that doing the same with mailgun)

(the reasoning above also makes me think that perhaps markdown is the way to go)

I think that's everything. so the TODO list would probably be this: 1. do a proof of concept for the theme system. get something working with fly machines at the very least. 2. figure out what to do for the rich text editor. try different things out. 3. decide on schema for posts + pages + sites. update schema.clj accordingly. write a migration fn in repl.clj that'll take posts and pages from the current default theme's schema and move them to the new fixed schema. update platypub's cms ui to use the new fixed schema (and rich text editor if we do anything different there). 4. finish the theme system and write a default theme plugin. 5. release! start using platypub 2.0 6. add the import plugin system. 7. add an account settings page where you can put in your mailgun key/settings. 8. overhaul the ui. 9. release again--now we (as in I, probably) can provide a public instance of platypub that anyone can use (🎉🎉🎉

)

stuff I'd want import plugins for: - discord, as discussed - slack, so #biff on clojurians slack can be published on the biff site. there's already a slack plugin that syndicates the content somewhere, so maybe just copy from there. I'd rather do that then ask the admins to install another plugin. - git: take the markdown docs + docstrings from the biff repo I think that's it

I think experimenting with a headless cms etc would also still be helpful for experimenting with stuff before coding it all up into platypub.

well it's been another 6 hours so I'm changing my mind again. I went as far as setting up a ghost instance for use as a headless cms, but after playing around with it I decided it really doesn't have any meaningful improvements for me over platypub's current editor. I think I like Platypub's slightly more actually. I am going to do a quick makeover of platypub's theme system--I'll turn it into regular clojure code, where each theme is a separate project that's included in platypub's deps.edn as a local dependency. and stuff. That'll take away some pain points associated with the current babashka-based theme system, enough for me to go merrily on my way making some updates to my themes. I'll only need like maybe one schema update, if that. So anyway, after that, whenever I get around to working on platypub more, I'll probably still go with the above TODO list (as for rich text editor, I think tinymce will be fine. There is an option for adding custom paste filters, so I might write one of those)

(in the course of this, I basically concluded that getting away from the current theme system was really the underlying thing that was motivating me to ditch platypub temporarily--so it works well enough to just replace that and keep the cms as it is for now)

hmmm though maybe it'd be better for now to stick with running-platypub-locally as the intended/assumed most common use-case and not even worry about sandboxing the plugins or anything. especially if one of the goals is to help get people into biff/Clojure, it might be just as well for the setup instructions to be "clone the platypub repo, then copy the ./themes/default folder to make your own custom plugin"

and then the fly machines stuff can be more of a far-off goal, after everything else is more polished

So I guess the TODO list I have in mind now looks more like this: 1. update the theme system to use regular clj projects + not worry about making it easy to sandbox. I'll also start using a custom theme for the TFOS site and then have a simpler default theme, perhaps intended sort of as a somewhat blank canvas. i.e. the recommendation would be for most people to ~immediately copy the default theme into a new custom theme folder and hack away. (Maybe I should just make a

create-new-theme

command, like Biff's new project script...) 2. schema updates. Fixed schema for posts + pages, but still support some custom schema for sites (I noticed that Ghost does that too actually). This will include both updates to schema.clj and updates to the UI. 3. ship it--I'll probably go ahead and take it to this point over the next day or two, since I'm already in the groove... but after this I'll probably just try to document the roadmap and such and let it be a community-driven project, until if/when I have more time to work on it. i.e. I'll work actively on documentation, just not code. 4. improve/overhaul/polish the UI--lots of room for improvement here. Maybe I'll make some wireframes or something. 5. import plugins. 6. sandboxing via fly machines, for both theme plugins and import plugins. there should be plenty of work to do on #4, and then anyone who wants to take on a bigger (and more fun!) task can try out 5 or 6