There isn't much prior art on blogging products for Ethereum. Most Ethereum products are narrowly financial; DAOs, for example, have been typically intended to be venture funds, or funding campaigns — not publishing entities.
When I consider what a publication might look like in the world of Ethereum, I imagine a deployed contract such as MirrorPublication that holds state such as contributors and admins. But this costs a lot of gas and would make onboarding Mirror expensive. What should onboarding cost? Well, it depends on the publication...
If the publication is for a single contributor — like a personal blog — then maybe it doesn't need a publication contract. The writer could lose out on a some other interesting features that also come with a publication contract, but it should be okay for a lightweight hobby account.
A fully deployed publication could be something that someone upgrades into. I ran through the logic for this and it seems feasible (I'll spare you the details). When a user upgrades to a deploy Publication, it's more of a company structure with a number of different writers, a treasury, etc. And this could be very cool, and also not something we do this week.
Realizing this means that we don't need to polish and audit a large repo contracts in order to launch our first version of Mirror on mainnet. Version 1 can be for individual publishers ("multi-contributor blogs coming soon!").
I see the way forward towards a more sophisticated protocol with multi-contributor publications. In the meantime, we can deploy the simple version to mainnet and focus on making that experience great. This will make Jon-Kyle happy, who has argued in favor of focusing on building a good writing experience for our first users.
I was doing some research on frontend editors, and stumbled upon a blogging platform that I had made seven years ago. It's in PHP, so I bet it still works perfectly on any Linux system. It didn't need a database (it used a "flat file" system), so it let you set up a blog in under a minute with no dependencies.
Obviously heavily inspired by Wordpress. How crazy is that? Mirror is my fourth CMS platform that I've worked on — the first one ever with a team though!
We spent a while discussing present vs future features, and where our focus should be. This included Denis talking about Signal vs Keybase (Elon Musk tweeted about Signal today, taking down their service due to sudden popularity).
It seemed like the consensus was that Keybase didn't focus on one thing, which made it difficult to use and mediocre relative to Signal, which did one thing really well. Denis' point was that the thing Signal focused on was the protocol, which turned out to be more important than any other features. It's a messy example and doesn't help us, I think.