smolweb – Dan Q

Pixel Area

Pixel Area (@pxlarea@mastodon.social) launched a couple of weeks ago, and DanQ.me was selected to be one of the initial “seed” blogs that were there at the outset (I’m at https://pxlarea.com/x38y34).

I’m… honestly not sure what to make of it. Organising personal websites spatially seems like a strange idea (although there’s a list view available too). And ‘pixel’ seems to be a strange name (at my desktop resolution, my ‘pixel’ comprises… 169 pixels). It’s got a little bit of a “million dollar homepage” (remember that) feel to it… though at least it’s not operating commercially. In fact, the best thing about it seems to be that it’s home-grown indie/smolweb content.

I guess it’s a bit like a webring? (Maybe it needs an embeddable component that lets a site show it’s “space” and hop to neighbours?)

So… yeah; I’m undecided on this one. But, as always, I love when people do cool, random and experimental stuff with the Web!

The IndieWeb Is Punk Manifesto

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

In 2025, I wrote:

Writing HTML is punk rock. A “platform” is the tool of the establishment.

And I’ve never seen anybody express what I was trying to say better than… this, stolen in almost its entirety:

Three chords and a domain name.

You don’t need a deal with a label. You don’t need a platform’s blessing. All you need is an out of tune guitar you can barely play, or a free text editor and a hosting bill. That’s it. That’s the whole scene.

I. We Are the DIY Kids

Punk didn’t wait for labels to say yes. It plugged in a blown out amp in someone’s basement and played anyway. Bad singer? Makes no difference. Three chords? You go. Own a drum kit but never had a lesson? You’re the drummer now.

The IndieWeb works the same way. Nobody’s waiting for permission to publish a website. You don’t need a “content strategy.” You don’t need a niche. You need a place that’s yours, and the nerve to hit publish.

Sometimes it’s ugly. It’s the wrong font. It’s a blog post about nothing at all. It works and it’s yours.

II. We Own the Masters Now

In the old days, the music industry owned the masters, the distribution, the airwaves. You made the music; they made the money and decided if anyone got to hear it.

Big platforms run the same racket. You write the posts, build the audience, generate the engagement, and they own the feed, the algorithm, and the right to bury you or boot you whenever it suits the shareholders.

Not here. Own your domain. Own your data. Own your identity. Your words live on infrastructure you control, not on borrowed servers that can evict you without notice.

III. No A&R, No Venture Capital, No Gatekeepers

No punk band was chasing a platinum record. Punk was about making music and getting it into people’s hands – that was the whole transaction.

No indie web builder is chasing Series A. We’re not optimizing for growth. We’re not selling your attention to advertisers. We charge a fair price for a real thing, if we even charge at all, and either way nobody’s pitching us to a boardroom.

Small. Sustainable. Answerable to no one but ourselves.

IV. The Zine Never Died, It Just Got a Domain

Punk had zines – cut, pasted, photocopied, and passed hand to hand because the real press wouldn’t cover it. That’s blogging before anyone even called it blogging.

We still do that. A blog is a zine with better uptime. An RSS feed is a mailing list that never asks for your email. Webmentions are show flyers stapled to telephone poles all over town, pointing back to each other, building the scene a link at a time.

Community over audience. Nobody in this room is just watching.

V. Make What You Need, Not What “Everyone” Needs

Stop designing for some hypothetical user that doesn’t exist. Build the thing that scratches your itch. Use it yourself – eat your own dog food. If you’re not depending on it, why would anyone else?

Do this enough, in the open, sharing your code and your notes and your half-finished ideas posted for all to see, and the rest of the scene will pick it up. That’s how it spreads: not top-down, but kid to kid, site to site.

VI. Weird Is a Feature

GeoCities had hideous backgrounds, animated GIFs, and a MIDI file that played on page load. It was ugly, but it was also alive in a way no template can ever be.

We’re not going for pixel-perfect. We’re not A/B testing a homepage. Have fun, or what’s the point? Keep the web weird. Keep it handmade. Keep the mohawks.

VII. It’s an All-Ages Show

Punk wasn’t always right about this. Each scene had its bouncers at the door and idiots in the pit. Bands worth remembering spent half their set shouting them back out – Rock Against Racism, Riot Grrrl, the Dead Kennedys writing a song to tell the Nazi punks exactly where to go. That wasn’t a side project. It was a full-time job.

So… Everybody gets a seat on the Indieweb. No matter your color, faith, gender, who you love, how your brain is wired, what your body can do, how old you are, where you were born, or which language you write in. Nobody at this door is taking a ticket.

No degree, no job title, no follower count, no years of experience, no permission from others who were on the scene first.

And if you’re already inside, hold the door open for others. Link to the new kids. Answer beginner questions without snark. Write the alt text, caption the video, keep it keyboard-reachable. A site nobody can use is a club with stairs at the doors and no accessibility ramp.

All are welcome on the Indieweb. It’s not a code of conduct bolted on after the fact. It’s the entire reason we’ve built our own places on the Web to begin with.

VIII. This Is the Counterculture Now

In the ’80s and ’90s, blasting Punk Rock was a way of telling the establishment where to stick it. Today, publishing on your own site instead of feeding the algorithm is the same middle finger, just a little quieter.

We opt out of the surveillance feed. We opt out of the engagement farm. We opt into a web made of small, stubborn, independent spaces that are loosely joined, built to last, and owned by those who make them.

We don’t need major platforms.

We have the Web, keyboards, tools, and community.

IndieWeb is Punk. Oi!

Jim Mitchell, in The IndieWeb Is Punk Manifesto (via Announcing the Indieweb is Punk Manifesto)

Is it time yet for me to go a step further and say this?

Stop fucking feeding the algorithms.
The Web belongs to humans. 🤘

Yeah, I think it’s time.

You don’t have to blog like me

You don’t have to blog like me.

You don’t have to differentiate by post kind.
You don’t have to put full contents in your feed.
You don’t have to keep a library of “maybe-some-day”
drafts so long that you’ll never reach the bottom.

You don’t have to have a comments form.
Or reactions. Or webmentions.
Or a guestbook. Or drawings?
(But give me some way to say “hi, you’re cool!”)

You don’t have to have a feature image.
You don’t have to keep posts up forever.
You don’t have to have tags.
You don’t have to syndicate to the socials.

You don’t have to stick to one topic.
Or three. Or seventeen.
Or be able to answer “what’s your blog about?”
It’s yours, and that’s enough.

You don’t have to post on a schedule.
You don’t have to use your real name.
You don’t have to have a podcast.
You don’t have to tell everybody.

You don’t have to use any particular tool.
Bloggers who spend their time arguing
About vs vs ʕ•ᴥ•ʔ vs
Could be reading and writing instead.

You don’t have to have a plan to “monetize”.
You don’t have to write your own theme.
You don’t have to be run your own server.
You don’t have to make every post your best.

You just have to blog.

The Internet is ours.
It belongs to the humans.

Not to the companies and the robots.
To us.

And every human voice.
Every single human voice.
Makes the world a little richer.

You don’t have to blog like me.
(You don’t have to use “blog” as a verb.)

You just have to blog.

And if you mention your blog in the comments, below, I promise I’ll go read it.

A Selfhosted Static Site Editor

My 12-year-old was interested in learning some HTML and CSS and making her own website. If she were anybody else I’d point her at something like Nekoweb as a starter host because their web-based (VSCode-based) “Nekode” text editor makes writing your first static site simple.

But I’ve got a NAS sitting at home on a fibre connection, so I figured: I might as well just host something similar here.

Here’s how I did it:

1. DNS

I pointed her domain at my static IP, plus a subdomain for the “backend” interface. Suppose her site would be at example.net (and www.example.net) with the admin interface at admin.example.net: my DNS configuration might look like this:

@     10800 IN     A 172.66.147.243
www   10800 IN CNAME example.net.
admin 10800 IN CNAME example.net.

2. Caddy

I’ve got a Caddy webserver acting as a static server and a reverse proxy already, so I just added a new static site with a configuration like this:

example.net, www.example.net {
  root /volumes/example.net/public
  encode gzip
  templates
  file_server
}

The templates directive means that, if/when she wants to, she could use Caddy’s built-in SSI-like features. Or if she decides someday she’d prefer a static site generator then I can sort her out with shell access or something.

It probably wouldn’t be much harder to set up something like this from scratch on e.g. a Raspberry Pi: Caddy’s fast and easy to get set up.

3. Editor

I used the OpenVSCode Server Docker image to provide a browser-based VSCode interface in which she could edit HTML, CSS and JavaScript and drag-drop files from her local machine. I’m using Unraid on my NAS so I didn’t have to think much about running a new Docker container, but I guess that if I did then I’d have typed something like:

docker run -d \
  # 7890 is the port on my NAS that I'll proxy Caddy to:
  -p 7890:3000
  # /mnt/user/example.net is the path on my NAS;
  # /example.net is where it'll appear within VSCode:
  -v "/mnt/user/example.net:/example.net" \
  # this tells OpenVSCode-Server to mount the directory to begin with:
  -e OPENVSCODE_SERVER_ROOT=/example.net \
  gitpod/openvscode-server

Now all I needed to do was point Caddy at it. For the time being I simply restricted access to only “computers on my local LAN”, but it’d be easy enough to add authentication using basic auth and/or client certificates if she wanted to be able to work on her site from elsewhere:

admin.example.net {
  # Restrict access to 192.168.* LAN:
  @allowed {
    remote_ip 192.168.0.0/16
  }
  # Proxy permitted folks to the container:
  handle @allowed {
    reverse_proxy http://nas:7890
  }
  # Block everybody else:
  handle {
    abort
  }
}

That’s literally all it took to put together a web-based editing environment that publishes directly to a static website. And because it’s on my own infrastructure, it’d be trivially easy to modify it in the future if she decided to go in a different direction, e.g. a PHP site, or continuous deployment from a repo, or static site generation from a shell.

That’s all!

Here’s a test site I threw together using exactly this stack, demonstrating the entirely browser-based editing workflow (not shown is drag-and-drop to upload, but I promise that works too!):

The internet’s hidden creative renaissance (and how to find it)

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Have you ever wished there were more to the internet than the same handful of apps and sites you toggle between every day? Then you’re in for a treat.

Welcome to the indie web, a vibrant and underrated part of the internet, aesthetically evocative of the late 1990s and early 2000s. Here, the focus is on personal websites, authentic self-expression, and slow, intentional exploration driven by curiosity and interest.

These kinds of sites took a backseat to the mainstream web around the advent of big social media platforms, but recently the indie web has been experiencing a revival, as more netizens look for connection outside the walled gardens created by tech giants. And with renewed interest comes a new generation of website owner-operators, intent on reclaiming their online experience from mainstream social media imperatives of growth and profit.

…

BlogTherapy and Josh Kramer, in The internet’s hidden creative renaissance (and how to find it)

I want to like this article. It draws attention to the indieweb, smolweb, independent modern personal web, or whatever you want to call it. It does so in a way that inspires interest. And by way of example, it features several of my favourite retronauts. Awesome.

But it feels painfully ironic to read this article… on Substack!

Substack goes… let’s say half-way… to representing the opposite of what the indieweb movement is about! Sure, Substack isn’t Facebook or Twitter… but it’s still very much in the same place as, say, Medium, in that it’s a place where you go if you want other people to be in total control of your Web presence.

The very things that the author praises of the indieweb – its individuality and personality, its freedom control by opaque corporate policies, its separation from the “same handful of apps and sites you toggle between every day” – are exactly the kinds of things that Substack fails to provide.

It’s hardly the biggest thing to hate about Substack, mind – that’d probably be their continued platforming of Covid conspriacy theorists and white nationalist hate groups. But it’s still a pretty big irony to hear the indieweb praised there!

Soo… nice article, shame about the platform it’s published on, I guess?

WebDX: Does More Mean Better?

Enumerating Web features

The W3C‘s WebDX Community Group this week announced that they’ve reached a milestone with their web-features project. The project is an effort to catalogue browser support for Web features, to establish an understanding of the baseline feature set that developers can rely on.

That’s great, and I’m in favour of the initiative. But I wonder about graphs like this one:

The graph shows the increase in time of the number of features available on the Web, broken down by how widespread they are implemented across the browser corpus.

The shape of that graph sort-of implies that… more features is better. And I’m not entirely convinced that’s true.

Does “more” imply “better”?

Don’t get me wrong, there are lots of Web features that are excellent. The kinds of things where it’s hard to remember how I did without them. CSS grids are for many purposes an improvement on flexboxes; flexboxes were massively better than floats; and floats were an enormous leap forwards compared to using tables for layout! The “new” HTML5 input types are wonderful, as are the revolutionary native elements for video, audio, etc. I’ll even sing the praises of some of the new JavaScript APIs (geolocation, web share, and push are particular highlights).

But it’s not some kind of universal truth that “more features means better developer experience”. It’s already the case, for example, that getting started as a Web developer is harder than it once was, and I’d argue harder than it ought to be. There exist complexities nowadays that are barriers to entry. Like the places where the promise of a progressively-enhanced Web has failed (they’re rare, but they exist). Or the sheer plethora of features that come with caveats to their use that simply must be learned (yes, you need a <meta name="viewport">; no, you can’t rely on JS to produce content).

Meanwhile, there are technologies that were standardised, and that we did need, but that never took off. The <keygen> element never got implemented into the then-dominant Internet Explorer (there were other implementation problems too, but this one’s the killer). This made it functionally useless, which meant that its standard never evolved and grew. As a result, its implementation in other browsers stagnated and it was eventually deprecated. Had it been implemented properly and iterated on, we’d could’ve had something like WebAuthn over a decade earlier.

Which I guess goes to show that “more features is better” is only true if they’re the right features. Perhaps there’s some way of tracking the changing landscape of developer experience on the Web that doesn’t simply count enumerate a baseline of widely-available features? I don’t know what it is, though!

A simple web

Mostly, the Web worked fine when it was simpler. And while some of the enhancements we’ve seen over the decades are indisputably an advancement, there are also plenty of places where we’ve let new technologies lead us astray. Third-party cookies appeared as a naive consequence of first-party ones, but came to be used to undermine everybody’s privacy. Dynamic DOM manipulation started out as a clever idea to help with things like form validation and now a significant number of websites can’t even show their images – or sometimes their text – unless their JavaScript code gets downloaded and interpreted successfully.

A blog post, news article, or even an eCommerce site or social networking platform doesn’t need the vast majority of the Web’s “new” features. Those features are important for some Web applications, but most of the time, we don’t need them. But somehow they end up being used anyway.

Whether or not the use of unnecessary new Web features is a net positive to developer experience is debatable. But it’s certainly not often to the benefit of user experience. And that’s what I care about.

This blog post, of course, can be accessed with minimal features: it’s even available over ultra-lightweight Gemini at gemini://danq.me/posts/webdx-does-more-mean-better/, and I’ve also written it as plain text on my plain text blog (did you know about that?).

Nex in CapsulePress

I’ve added Nex support to CapsulePress!

What does that mean?

Nex is a lightweight Internet protocol reminiscent to me of Spartan (which CapsulePress also supports), but even more lightweight. Without even affordances like host identification, MIME types, response codes, or the expectation that Gemtext might be supported by the client, it’s perhaps more like Gopher than it is like Gemini.

It comes from the ever-entertaining smolweb hub of Nightfall City, whose Web interface clearly states at the top of every page the command you could have run to see that content over the Nex protocol. Lagrange added support for Nex almost a year ago and it’s such a lightweight protocol that I was quickly able to adapt CapsulePress’s implementation of Spartan to support Nex, too.

require 'gserver'
require 'word_wrap'
require 'word_wrap/core_ext'

class NexServer < GServer
  def initialize
    super(
      (ENV['NEX_PORT'] ? ENV['NEX_PORT'].to_i                           : 1900),
      (ENV['NEX_HOST']                                                 || '0.0.0.0'),
      (ENV['NEX_MAX_CONNECTIONS'] ? ENV['NEX_MAX_CONNECTIONS'].to_i : 4)
    )
  end

  def handle(io, req)
    puts "Nex: handling"
    io.print "\r\n"
    req = '/' if req == ''
    if response = CapsulePress.handle(req, 'nex')
      io.print response[:body].wrap(79)
    else
      io.print "Document not found\r\n"
    end
  end

  def serve(io)
    puts "Nex: client connected"
    req = io.gets.strip
    handle(io, req)
  end
end

This is genuinely the entirety of my implementation of my Nex server, atop CapsulePress. And it’s mostly boilerplate.

Why, you might ask? Well, the reasons are the same as all the other standards supported by CapsulePress:

The smolweb is awesome.
Making WordPress into a CMS things it was never meant to do is sorta my jam.
It was a quick win while I waited for the pharmacist to shoot me up with ~~5G microchips~~ my ‘flu and Covid boosters.

If you want to add Nex onto your CapsulePress, just git pull the latest version, ensure TCP port 1900 isn’t firewalled, and don’t add USE_NEX=false to your environment. That’s all!

How to Monetize a Blog

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Maintaining a blog can be a lot of work. A single article can take weeks of research, drafting and editing, collecting and producing included materials, etc. It’s not unusual to seek some form of compensation for it, and those rewards require initiative. With a good monetization strategy, it can become a fairly lucrative venture.

So let’s talk about monetizing a blog, starting with the most obvious and perhaps easiest avenue: display advertising.

A content creator with an established audience can leverage that audience and sell ad space on their blog. Here’s an example:

…

Tyler

I’m not sure I have words for how awesome this blog post is. If you’ve ever wanted to monetise your blog and are considering an ad-driven model, this should absolutely be the first (and perhaps last) thing you read on the subject.

If you’re not convinced that Tyler is an appropriate authority to speak on this subject, I highly suggest you visit their other site that’s got a wealth of useful tips, PutAToothpickInTheChargingPortDoctorsHateThatShit.christmas. Yes, really.

Home Page, 50% Off!

In August, I celebrated my blog – with its homepage weighing-in at a total of just 481kb – being admitted to Kev Quirk‘s 512kb club. 512kb club celebrates websites (often personal sites) whose homepage are neither “ultra minimal” or “link pages” but have a total size, including all assets, of under half a megabyte. It’s about making a commitment to a leaner, more-efficient Web.

My relatively-heavyweight homepage only just slipped in under the line. But, feeling inspired perhaps by some performance enhancements I’ve been planning this week at work, I decided to try to shave a little more off:

Now, at ~234kb, danq.me just beats the excellent gomakethings.com (it’s all those heavyweight fonts, Chris!).

Here’s what I changed:

The “recent article” tiles are dynamically sized based on their number, type, and the visitor’s screen resolution. But apart from the top one they’re almost never very large. Using thumbnail images for the non-first tile shaved off almost 160kb.

Not space-saving, but while I was in there I ensured that the first tile’s image – which almost-certainly comprises part of the Largest Contentful Paint – is never delivered with loading="lazy".
I was providing a shortcut icon in .ico format (<link rel="shortcut icon" href="https://bcdn.danq.me/_q23t/icons/favicon-16-32-48-64-128.ico" />), which is pretty redundant nowadays because all modern browsers (and even IE11) support .png icons. I was already providing .png and .svg versions, but it turns out that some browsers favour the one with the (harmful?) rel="shortcut icon" over rel="icon" if both are present, and .ico files are – being based on Windows Bitmaps – horrendously inefficient.

By getting under the 250kb threshold, I’ve jumped up a league from Blue Team to Orange Team, so that’s nice too. I can’t see a meaningful path from where I’m at to Green Team (under 100kb) though, so this level might have to suffice.

Last-minute additions:

Here’s the PR updating my site’s record in the club
If you like the animation, here’s the JavaScript code I used to generate it (plus a quick crossfade made in Kdenlive)

CapsulePress – Gemini / Spartan / Gopher to WordPress bridge

For a while now, this site has been partially mirrored via the Gemini¹ and Gopher protocols.² Earlier this year I presented hacky versions of the tools I’d used to acieve this (and made people feel nostalgic).

Now I’ve added support for Spartan³ too and, seeing as the implementations shared functionality, I’ve combined all three – Gemini, Spartan, and Gopher – into a single package: CapsulePress.

CapsulePress is a Gemini/Spartan/Gopher to WordPress bridge. It lets you use WordPress as a CMS for any or all of those three non-Web protocols in addition to the Web.

For example, that means that this post is available on all of:

my weblog, at https://danq.me/2023/09/10/capsulepress‎,
my gemlog, at gemini://danq.me/posts/capsulepress,
my spartanlog, at spartan://danq.me/posts/capsulepress, and
my goperhole, at gopher://danq.me/1/posts/capsulepress

It’s also possible to write posts that selectively appear via different media: if I want to put something exclusively on my gemlog, I can, by assigning metadata that tells WordPress to suppress a post but still expose it to CapsulePress. Neat!

90s-style web banners in the style of Netscape ads, saying "Gemini now!", "Spartan now!", and "Gopher now!". Beneath then a wider banner ad promotes CapsulePress v0.1. — Using Gemini and friends in the 2020s make me feel like the dream of the Internet of the nineties and early-naughties is still alive. But with fewer banner ads.

I’ve open-sourced the whole thing under a super-permissive license, so if you want your own WordPress blog to “feed” your Gemlog… now you can. With a few caveats:

It’s hard to use. While not as hacky as the disparate piles of code it replaced, it’s still not the cleanest. To modify it you’ll need a basic comprehension of all three protocols, plus Ruby, SQL, and sysadmin skills.
It’s super opinionated. It’s very much geared towards my use case. It’s improved by the use of templates. but it’s still probably only suitable for this site for the time being, until you make changes.
It’s very-much unfinished. I’ve got a growing to-do list, which should be a good clue that it’s Not Finished. Maybe it never will but. But there’ll be changes yet to come.

Whether or not your WordPress blog makes the jump to Geminispace⁴, I hope you’ll came take a look at mine at one of the URLs linked above, and then continue to explore.

If you’re nostalgic for the interpersonal Internet – or just the idea of it, if you’re too young to remember it… you’ll find it there. (That Internet never actually went away, but it’s harder to find on today’s big Web than it is on lighter protocols.)

Footnotes

¹ Also available via Gemini.

² Also via Finger (but that’s another story).

³ Also available via Spartan.

⁴ Need a browser? I suggest Lagrange.