I've added a redirect rule since I've already mentioned the full address in a previous post. So now, /shreds will redirect to https://thombruce.com/posts... which is exactly where I started. Oh well! 🤷‍♂️

All that back-and-forth deliberation and do you know what? I'm just going to revert the section to /posts. I think it best communicates the intent, and having seen the word choices alongside 'Blog' on the homepage, I think it actually is clearest.

That's done! The canonical source of these short posts is now https://thombruce.com/shreds. I like that!

The short-short-list is /shreds, /snippets, /messages. Were I to drop one, it would probably be /snippets (seeming to indicate code to me), so... /shreds or /messages? I think I'm gonna go with /shreds. It's less clear, yeah, but it's more fun and more personal. It has character.

Nice! 😎

I think my current shortlist is this: /posts, /shorts, /snippets, /shreds, /messages. /posts and /shorts feel unclear; /snippets may also be unclear, I might be reserving it for code; I like /shreds a lot, it's fun; /messages does feel the clearest and fittest for purpose.

We could also call the section /updates, /notices, /alerts, /messages or... even just /social. It is, after all, modelled after social media platforms and their limitations.

That leaves /shorts which... just doesn't feel descriptive enough. Yes, it does the job. Yes, these are shorts (short posts), but the name might also suggest that it's a section of short videos.

/burps feels like an appropriate name but too silly and quite unclear. /snippets sounds exactly like what these are, I just wonder if I'm reserving the name for code snippets. And /shreds sounds rad - reminds me of skating - but it doesn't clearly indicate the section's contents.

To that end, I'm considering renaming this section. Not /posts but instead... /burps? /snippets? /shreds? /shorts?

I want to add a section to my site for longer form articles. A traditional "blog", if you will (why wouldn't you?). The issue is one of semantics. If I have a /blog section and leave this section named /posts, I feel like there's some confusion about what this section is.

"If it ain't broke, don't fix it", right? I'm just annoyed that I don't know... why this works. Why it DIDN'T work without that setting. It's just a little custom module with a custom transformer... but whatever. It works now, let's not complain.

Nothing else worked. And I really thought if I set that option that OG Images would stop working but... they haven't! So we're building for static (like I used to) and benefiting from the features I thought that excluded us from.

Okay, after A LOT of banging my head against the specific problem of Vercel seemingly not including my custom Nuxt module and not generating my screenplay pages, it looks like I've got it working by setting nitro.target = static.

I could convert these posts to Markdown docs... but I don't care as much if these are omitted from the sitemap. I care if my Fountain documents (screenplays, maybe prose) are... and those aren't as easily converted. We'll see if I can modify this sitemap module. Low priority.

I've imported the screenplays section from the old version of my site, so... those are here now. It does expose an issue with the Sitemap module: neither these posts nor my screenplays are listed - only markdown files. I'll have to look into whether or not I can tweak that...

Sure, the OG images don't look great right now... not for these posts anyway. And the numeric ordering is a bit wonky, and the numbered posts are having said number appear as a title... Easily fixed. Let me just import my old page templates...

My site is now hosted on Vercel and it has working automatic OG Image support. So each of these posts gets an OG image without me having to add one explicitly. Huge for dynamic, frequently changing or frequently added content!

I'm now adding these posts to the new version of thombruce.com, forked from that new template repo. A few things that used to be on the site will remain missing for now - I'll re-add them with time - but the issues I was having are now gone!

The issue with my GetTNT GitHub org was that I still wasn't allowed to fork multiple times to my user namespace. So I moved the template repo back and I'm mirroring it at https://gitlab.com/thombruce/tnt. From there, I can fork as many times as I like to my GitLab namespace.

Actually, it's amazing how quickly I retired that URL. Correct link is now https://github.com/thombruce/tnt, same as the old version. It's also on GitLab (same path).

Said repository now exists at https://github.com/GetTNT/tnt. Again, not the place I think I'll typically be linking people to. I think I'll create a fork at thombruce/tnt when I've renamed and archived the old version, but for my own purposes I'll be forking from there.

I'm gonna create a new namespace for it called 'GetTNT'. The core repository will live at 'GetTNT/tnt' and... I might, but only might, fork it over to 'thombruce/tnt' to have that be its sort of canonical URL (the GetTNT org would exist purely for my own forking purposes).

I guess wanting my repos under my 'thombruce' GitHub name is a vanity consideration; it shouldn't be my priority here. Easiest solution is to host the TNT template repo under a different organisation. I can always fork it unchanged under my own namespace too.

So either I'm going to have to house TNT itself or my forked projects under a different namespace... or I'm going to have to do without forking for myself, instead cloning from upstream and managing updates locally instead.

Annoyingly, GitHub still doesn't allow you to fork a repository under the same owner (even though they've supported renaming at the time of forking since 2022). This complicates my repository-based template plan. Forking would be the ideal mechanism for keeping a repo updated.

Approach is simple: Redevelop TNT from scratch as a repository-based template with intent to fork and fast-forward changes. Have my Nuxt-based sites be forks of that repository. It's going to be tedious adopting this approach, but it's going to be easier to manage long-term.

Basically... Why use Nuxt to solve something that Git already does? I mean I know Nuxt Layers does more than what I'm describing here, but this is one major use-case I've been using Nuxt Layers for that... I just don't need to. TNT should be a repository template, not a module.

That approach would... yeah... It would genuinely be smarter. Could I still work with Nuxt Layers? Maybe, but they would be less critical to the operations of child projects. Issues would be easier to identify and resolve and... there are way fewer drawbacks than positives.

For managing many projects... that means more work getting them to match the same template. But it also means greater clarity when trying to identify issues. I suppose what I need isn't a module, it's a template repository I can fork and merge downstream when changes are made.

The problem with TNT is... I've obfuscated the issues that get in the way of development. It's still a good idea, it just may be the wrong approach... or is trying to do too much. I need to simplify, consolidate - bring dependencies into this project, where I can monitor them.

So, this site has one major dependency called @thombruce/tnt-content, a child module of @thombruce/tnt which I've been working on for a while. It's a hodgepodge of Nuxt, Vue and JS libraries that I think are handy to have grouped together as a framework of commonly used modules.

A total reboot doesn't mean these posts disappear. It doesn't even mean we experience any downtime. I won't deploy the new site until it at least matches what's already here, but it seems like the clearest way out of the bind. Let me describe that a little...

Having some trouble deploying this very website as a dynamic Nuxt project (right now it's static). There are some nice features to be gained if I can figure this out but... I think I've gone a long way in the wrong direction, and I'm thinking a total reboot might be called for.

Happy New Year! 🎉 My main resolution: To write a little every day (these posts don't count). I want to be writing... fiction, maybe some non-fiction, anything essentially that progresses towards being in a book. Some of it will be coming to the website when it's ready.

It has to be said that this is a vanity project. It's not that important. There's some work I need to do to add more basic features to my website too, so we'll see how quickly I get to this. I'm happy for now to have a microblogging platform of my own that I actually like using!

Now that we're on Vercel and I'm happy with the repo rename (https://github.com/thombruce/thombruce.com), we now have access to Vercel's serverless functions. These are going to be essential for my integrations with Mastodon and, eventually, Bluesky.

I've checked and we're definitely now resolving the domain to the new server. I've unpublished the site on GitHub Pages. I just now need to... 1. Probably just comment out the deploy script for now (done!) and 2. Change the repo name and relink Vercel. I'll do that now.

That's done, changes have been made in my Cloudflare DNS and the changes are propagating. Vercel is generating SSL certificates. I'm gonna give it a little time and revisit later. Looks like it's already working, but let's be cautious before I take the next steps.

Fuck it, yeah. Let's make the new canonical URL 'www'. Since Vercel will redirect all traffic seeking 'thombruce.com' there anyway, I can't immediately foresee any downsides to making the apex a redirect. Vercel also promises a faster website experience this way too.

Unexpected choice. I've been using an apex domain for ages (thombruce.com) with the www variant redirecting to it... but I could change this. Have the apex redirect to the www subdomain instead. It's a question of how much of a concern cookie management is to me here.

Step one is done. My site is now on Vercel at https://thombruce.vercel.app/. Changing the target of my custom domain (thombruce.com) to this shouldn't result in any downtime... and then I just need to rename the repo and stop the GitHub builds. Easy.

So I want to change the name of my repo AND move the build to Vercel, ideally with no downtime. First step: Let's build at Vercel from the repo as is. Get both versions of the build active, then we can change where the domain is pointing. After that: change repo name and relink.

Alright, Vercel migration time. This site is currently stored in a repo at thombruce/thombruce.github.io. This creates a GitHub Page at the given 'github.io' address. But if we're moving to Vercel, that naming is redundant and misleading. We want to change it to 'thombruce.com'.

What I'm saying is, despite those earlier posts where we played with Markdown a little, I'm gonna be keeping my micropost text content as plain as I possibly can. I'll probably even think about implementing facets. Bluesky's justification for the approach is really solid!

So text decoration is a little harder to implement for Bluesky or the AT Protocol, but actually it's an elegant and incremental solution... and extensible too. If I wanted to support spoiler tags ahead of Bluesky doing so, I could create my own facet "feature" to handle that.

To avoid syntax barf, the text in a Bluesky post is always... just text. Decorations are handled in a separate array of "facets" which third-party clients can choose to implement or not... and it doesn't effect the displayed text. That fallback is always there, is always clean.

Bluesky's "facets" avoid syntax barfing and simplify character counting. Let's make-believe we have our own syntax; this is what syntax barf looks like: %%Ugly Markup%%. Because third-party clients don't know what my unique syntax is supposed to mean, they can't parse it.

The justification for using "facets" in Bluesky over a markup syntax is actually really solid; I love it! Paul Frazee details it here: https://www.pfrazee.com/blog/why-facets Essentially it boils down to keeping parsing simple for third party clients.

So... despite my toying with markup in a previous post, adding emphasis, and inline code that I'm sure Mastodon will display properly... I should impose a rule: No extraneous markup. Plaintext, hashtags, @ mentions and links. That's the set of features we get here. For now.

It's just this easy: MDC(:value="post.body" unwrap="p") I hesitate to use block-level Markdown, though I expect Mastodon handles it fine. Bluesky is the issue; the code for rich text facets is pretty limited in scope: links, tags and mentions are all that seem to be supported.

That said though... Parsing these posts as Markdown is the easiest/quickest option. And I'm not compelled to use the full set of features; I can use whatever subset I like. I will need to rethink the handling anyway when it comes to serialising the posts for Mastodon.

What that means for me, at least, is that... YES! I can use Markdown to compose my microposts. This is true. But should I? Sure, I'm being a bit cheeky and using all the inline markup in this post, but should I generally do this? I think not.

According to this forum post I found, fediverse content is always text/html by default: https://socialhub.activitypub.rocks/t/content-text-plain-and-fallback-behaviors-for-limited-clients/340 So technically Mastodon clients should support at least a subset of the full HTML spec?

Technically Mastodon will display rich text if it comes from a non-Mastodon application elsewhere in the fediverse. Here's a bit of an explainer: https://fedi.tips/is-mastodon-compatible-with-rich-text-formatting-such-as-markdown/

Easy way to fix links? My static site generator already has a markdown parser, so just treat them as markdown. Bluesky already has rich text support (https://docs.bsky.app/docs/advanced-guides/post-richtext). Mastodon... it's complicated.

That answers that; links don't work. I'll add it to the list.

One last thing before I commit! I don't know if links yet just work implicitly or if I need to do something to handle them better. I've also just added a todo list with a couple of items, so... appropriate time to test this: https://thombruce.com/todo

First priority though: Migrate my site to a platform with serverless functions. Once I've done this, I can begin the work of integrating it with Mastodon. Once I've done that... I will no longer be a social media outcast. I'll have a solution that I think actually works for me!

Eventually I will create an interface for writing these microposts that makes a commit and a push as soon as I hit "send". This will make them go live on social sites a bit faster but I don't need these posts to be super low-latency at this time. Maybe we migrate to a db later.

I don't mind at all if there's latency when I'm creating these posts. Right now I'm typing this in VS Code, posts 6 through 13 are not yet committed to my repo, once I commit and push, the site will be queued to build and the posts won't be live for 5-10 minutes.

I think the right call is to store the likes and follows we need to store in a database and access that information dynamically. This significantly reduces the latency when connecting my site with the fast-moving domain of social media.

Technically, I think my storage mechanism could remain static. There'd be some latency as the site would need to rebuild before the data became readable... but there's no technical reason why this shouldn't work. Is it the right call though? I don't think so.

Not sure what the full set of functions I need to support is, but I think ActivityPub (which Mastodon uses) has the concept of an "Inbox". This inbox receives the activity requests for things like... likes, replies, follows... and your server is expected to handle these.

Notable examples of hosts that support serverless functions: Vercel, Netlify, Cloudflare Pages (which I only discovered exists earlier today). I've already worked with Vercel's serverless functions before, so I think I'll migrate my site there.

Some static site hosts do support something called "Serverless Functions". These are... Let's think of them as micro-servers that engage with requests similarly to traditional servers; they're just used less frequently and for specific needs.

My site is a static website. I like it that way. The code and the content can live together in the same repo; it's super portable and super efficient because it doesn't require a server. Downside? No server. And right now I'm hosting it on GitHub Pages, so no real backend at all.

I need to consider the server-side aspect of this, and I should do it early; I should do it now. I believe that to integrate with Mastodon and Bluesky, I need an address on my site that can receive POST requests and respond accordingly (e.g. adding a follower, tallying a like).

Alright, I'm pretty happy with how this is looking so far. Eventually I'll have support for replies/follows from Mastodon, hopefully also Bluesky. Before that, I'll add support for image attachments, hashtags and links. Emojis? Already supported. 🙂

How quickly I abandon the 280 limit for the slightly better 300 supported by Bluesky remains to be seen. Probably pretty quickly, since Twitter/X isn't a decentralised app like those others and is going to be impossible to integrate in the way I'd like.

For now, I'm limiting myself to 280 characters. This is the Twitter limit. Bluesky's is 300 and Mastodon's is 500 (I think Threads is the same). My plan is to integrate with these eventually; have this be the canonical source of my microposts and allow followers from those sites.

This is just a basic setup for now. No support for replies or threading, so each post is going to be its own, separate entity. No support yet for attachments either, though that's an early priority. And no real restrictions on characters... except those I impose myself.

Hello, World! Welcome to my microblog. That's what these things are called. My replacement for Twitter, now that that's X and also kind of a hellhole. What this actually is is a DIY approach. This is presently just a simple YAML document in my website's repo. More to follow...