Blogging Engine

From James Van Dyne
Jump to navigation Jump to search

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.

Sustainability

  • 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
  • Minimal / zero Javascript -> works great on old and new devices alike.
  • Hosted on renewables

Architecture

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.

Blog Editor

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 loading="lazy"
    • ![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:
  • 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?

Blog Rendering

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
Theming
  • 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.

Service Management

  • 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?

Multiblog

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.

Multiblog/micropub

  • 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
    • Use existing / standard microformats where possible - create and document where not / needs to be extended