Blogging / personal websites will continue to increase as more people get online. The spectrum of blogging software is quite diverse from fully-static webistes generated with Jekyll and friends to point and click Wordpress , to nice travel blogging software.
This blogging engine aims to focus on reduced resource usage – low energy requirements to run the server, low energy requirements to process on the client, and minimal data sent over the wire to make it as sustainable as possible.
- Fewer moving parts -> smaller servers ok
- Themes only use system fonts -> save a few megabytes and improve rendering speed
- Optimize / resize / crush all images -> save data transfer / energy used to transmit data wirelessly
- Lazy load all images -> only load images that you're about to view, reduces energy used to transfer / render undisplayed images
- Hosted on renewables
The architecture isn't entirely decided at this point, but I am thinking about what if each blog had its own database, and what if that database was sqlite and not Postgres. The immediate benefits are: no mixing of customer data, easy to export (just download the sqlite file, more or less), no server required running in the background.
There's 3 different parts to the system: the blog editor part, the blog rendering part, and a service management part.
This will be the most resource intensive part of the application. Users will use this area to write / manage blog posts, upload photos and the like.It will also be the most dynamic / "web appy".
- Goal is not a SPA fat-client
- Either full server-side rendering or server-side rendering + svelte for dynamic bits
- Edit posts in markdown + a small toolbar for helping write it (ala Nomiso)
- MUST: Smoothly insert / upload images
- Strip all identifying information automatically (mostly geo cords)
- Upload images from clipboard / drag drop
- rendering images are automatically
![Alt text](img:455~"image title"]
<img src=".../photos/bob.jpg" alt="Alt text" title="image title" loading="lazy">
- MUST: Linking to other posts
- Extended markdown.
[post:123](Custom link text here)
- Autocomplete after detecting [post: / [page:
- Extended markdown.
- MUST: Would like to support webmentions
- Maybe some simple POSSE features
- SOMEDAY: Basic mapping
- Associate a blog post with a point on a map?
- Map view to show all posts on a map?
- Something like Justin's Travellog?
This will be what most users will see. Dynamically render pages from the sqlite database.
- Automatically cache full rendered pages to html on disk?
- Rendering text in Python is slow - should this be written in Rust?
- RSS first class citizen
- No theming to start as it'll be my theme
- Ideally uses django-style templates
- Custom themes - someday? Would need to figure out how to make it easy to develop.
- A small service used for managing the fleet of sites / billing and so forth. Also needs to be as resource friendly as possible.
- Websites on a sub-domain at first
- Eventually facilitate transfer/purchasing of custom domains?
I had the observation that what I really want is less of a single blog per se and more I want multiple blogs.
- I want a blog for my thoughts.
- I want a blog for my runs.
- I want a blog for my checkins.
- I want a blog for my statuses
- I want a blog for my photos
- I want a blog for my travels (which could combine all the above?)
Each content type wants data tables and a schema that's optimized for it, both for storage and rendering. If you're to make a service that is going to host all of this personal data - the core of it must be open source.
Multi-blog would consist of a micropub (and maybe a media endpoint?) for posting / updating / creating posts (admin) and a separate service that would then consume the database and turn it into multiple-blogs. All blogs could then be curated into a single roll-up blog.
- Each blog can be powered by the same micropub endpoint / form/
- The form must first identify that it authenticated (has an auth_token ) and an h-* entry.
- From there, each blog is simply a list powered by a microformat
- checkins.jamesvandyne.com -> h-checkin
- running.jamesvandyne.com -> h-entry + p-distance ? etc
- HealthKit data (run routes) seem like they're only available from HealthKit
- Use existing / standard microformats where possible - create and document where not / needs to be extended