Salta al contenuto

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone
  • # The Blog Option in littleFedi

    Fediverso bssg ssg ownyourdata blogging littlefedi netbsd fediverse
    1
    0 Votazioni
    1 Post
    7 Visualizzazioni
    stefano@rpi0w.stefanomarinelli.it
    The Blog Option in littleFedi littleFedi, like many social platforms, had both a strength and a limit. Posts, by their nature, are ephemeral. They get published, federated (unless local-only, which littleFedi handles) and then, over time, lost. Partly through self-deletion, partly through their normal blending in with the thousands of other posts that pile up over time. Sometimes, though, we want something to stay. And not just stay as a social post, but as an actual blog. A bit like with BSSG, I had thought it would be convenient to have a minimal system. Not to compete with WordPress or other solutions, but to have a small blog, integrated into littleFedi, that would produce and serve a blog updated every now and then, whenever the person writing felt like doing it. And that's why the blog option was born. The idea is simple: when you write a post, from the web UI or from the CLI, there's a checkbox, "blog post". If you check it, that post stops being just a status that will scroll past and disappear. littleFedi renders it into a real static site. No JavaScript, just HTML and CSS, an Atom feed, tag pages, a chronological archive. Nothing exotic, nothing that needs maintenance five years from now. The blog isn't a parallel system you have to feed separately. It's not an export, not an import, not a bridge to some other CMS. The post you wrote is the blog post. Same database, same act of writing, still boostable, still repliable, still part of the conversation on the fediverse side. The blog is just a second representation of the same content, generated automatically. Every time you create, edit, or delete a blog post, the whole static site for your account gets rebuilt from scratch, and the new version replaces the old one atomically, so nobody ever lands on a half-built page. If the build fails, the previous version stays in place. Simple, but it has to work reliably, or the whole idea is pointless. That's the core of it: two representations of the same post. As a status, it lives in the fediverse, interactive, part of the conversation, subject to replies and boosts like anything else. As a static page, it lives on the web, durable, indexable, with a permalink, something an RSS reader can hold onto. You don't have to decide in advance which posts deserve to last. You write normally, and if something turns out to be worth keeping, you flag it, and it gets its own page. One detail I cared about while thinking this through: the generated site has to be self-contained. When littleFedi builds it, media gets copied or hard-linked into the generated directory - images, audio, video. If it's stored on S3, it keeps its public URL directly. Either way, the point is that the site on disk doesn't depend on the instance staying up. If the server goes down tomorrow, the blog files are still a complete, working website. That wasn't an afterthought, it was one of the requirements from the start. Not every account gets a blog, and that's intentional. The instance admin has to enable the feature globally ([blog] enabled = true), and then grant it per account. It's not meant to be a CMS, and I didn't want it to become one. Blog posts can't be replies, can't be boosts, have to be public and top-level. These are constraints, not missing features: the blog is for your own writing, not for threads or reshared content. There's no JavaScript anywhere in the generated site. That was deliberate too. It loads fast, it works offline if you cache it, and it will still render correctly in ten years without anyone having to update a dependency. In the end, the blog option doesn't ask you to choose between writing socially and writing something permanent. You keep writing the way you always do, on littleFedi, and if a post is worth keeping, you check a box. No separate platform, no migration, no vendor lock-in. Just your own posts, some of them rendered into a small static site you can host anywhere, built out of something that already existed on the open web. Remember: all this is being currently served by a Raspberry PI Zero W powered by NetBSD Here's the result: https://rpi0w.stefanomarinelli.it/@stefano/blog/691cb62e-e7a1-434b-ba65-d059ee58ac41/ #littleFedi #SSG #BSSG #OwnYourData #Blogging #Fediverse #NetBSD
  • 0 Votazioni
    4 Post
    0 Visualizzazioni
    matuzalem@mastodon.bsd.cafe
    @stefano this is insanely great!
  • 0 Votazioni
    1 Post
    0 Visualizzazioni
    stefano@mastodon.bsd.cafe
    Announcing BSSG 0.40.0: RAM-First Build Mode, Fediverse Integration, and Semantic HTML OverhaulBSSG 0.40.0 is here, delivering a lightning-fast RAM build mode, native Fediverse integration, expanded CLI overrides, and new themes.https://blog.bssg.dragas.net/2026/03/27/announcing-bssg-0-40-0-ram-mode-fediverse/#BSSG #SSG #Bash #StaticSite #StaticSiteGenerator
  • 0 Votazioni
    2 Post
    26 Visualizzazioni
    stefano@mastodon.bsd.cafe
    Big update pushed for #BSSG - my Bash-based static site generatorThis is a major pre-release update, not the official release yet, and I would really love some testing and feedback before cutting it.Highlights:* New build mode: BUILD_MODE="ram" / --build-mode ram* This is a memory-first build mode designed to drastically reduce disk I/O during the build.* On real projects, this results in a ~2× speedup, and in some cases well over 3× faster builds, depending on:* site size* number of generators involved* storage speed* parallelism availableIn RAM mode you also get a stage timing summary, so you can see exactly where build time is spent. This makes performance tuning much more transparent and data-driven.Under the hood:The core build system was heavily refactored:* Clear separation between orchestration, generators, and indexing* Cleaner and more predictable generation flow for posts, pages, tags, authors, archives, and feeds* Asset and theme handling moved into a dedicated build module* Static file copying and theme CSS processing are no longer scattered around the codebasePerformance and robustness:* Smarter rebuild and caching logic* Improved parallel execution paths* Uses parallel when available* Shell-based worker fallback when it isn’t* Parallel behavior is now more robust and easier to reason aboutStability and polish:* Fixed an edge case with locale-specific timing parsing* Configuration and documentation updated to match new options and tuning knobs* Overall codebase is simpler, clearer, and easier to extendBefore tagging the official release, I need help testing this.* Please test from the main branch or commit and report issues *Links:Repo: https://brew.bsd.cafe/stefano/BSSGHuge thanks to everyone who tests, reports issues, or pokes at it.This release comes from a lot of refactoring and profiling, and fresh eyes really help#IT #SSG #Bash #OwnYourData
  • 0 Votazioni
    1 Post
    3 Visualizzazioni
    robyn@yeg.bike
    > "Many personal website ownersdeliberately choose inefficient methodsfor updating their sites. They writeHTML by hand, upload files directlyvia FTP, or maintain static sites thatrequire manual intervention for evensimple changes. These choices wouldbe considered backwards in aprofessional context, but they serveimportant psychological and creativefunctions"by @vale, in the current #GoodInternet issue.me and my #hugo #ssg site deployed via #ftp feel very seen#smallWeb #indieWeb
  • I'm testing the new BSSG test build.

    Mondo bssg ssg bash staticsitegenerator
    2
    0 Votazioni
    2 Post
    18 Visualizzazioni
    fcalva@cyberplace.social
    @stefano How are you doing that in Bash ? Pipes ? Ramdisks ?