{ "version": "https://jsonfeed.org/version/1", "title": "Jack.is typing", "home_page_url": "https://jack.is", "description": "I teach sand to think. Also occasionally write blog posts.", "author": { "name": "Jack Platten" }, "items": [ { "id": "https://jack.is/posts/self-hosting-your-pds/", "content_html": "

Bluesky is great (as evidenced by my multiple posts on it), but I wanted to own\nmy data more than it living on the Bluesky servers. Now I could have just used\nthe standard deployment as shown in the PDS repo,\nbut I wanted to do something a little more fitting my deployment practices.

\n

Why

\n

A few years ago, I moved my webserver (what runs this site, my PDS, and lots of\nother services) to CentOS Stream back when that was still viable, then Rocky\nLinux as the new replacement when Stream sort of died off. Is it perfect, is it\nthe right way to do things? No, but it’s what I prefer at this point. 1

\n

The Problem: part one

\n

The default Bluesky PDS is intended for being deployed on Ubuntu 20.04/22.04. It\nwill fail to deploy on anything other than those two distributions (even 24.04\nwhich also works but that’s neither here nor there).

\n

Solutioning a problem

\n

While I was in the testing phase of deploying my PDS, I was using an Ubuntu\nserver that I could successfully deploy using the installer. I already use Caddy\nthough, so the compose file having Caddy dockerized is not ideal. Fixing that\nwas a pretty easy cleanup to get a proper pds.env file out of it, since\nthere’s no canonical source outside of the installer. Now I had a relatively\nstandard PDS deployment using Docker, but using the Caddy service I use for\neverything else on my server.

\n

Best Practices?

\n

I have opinions on the way Bluesky PBLLC has made the systemd unit for the PDS\nin GitHub. It deploys as a oneshot, so journalctl is not super useful,\nsystemctl will never show it as running, and it is generally just hard to set\nit as a dependency or a dependent of any other services due to it being oneshot.

\n

Fixing this took me on a rabbit hole / detour on how to do it “better”.2

\n

Enter Sandman Podman

\n

I had been watching my coworkers explore Podman a bit at work, and looking into\nit, it had the perfect thing for my needs, the ability to “systemd-ize” a\ncontainer workload in a way that made sense for both the container, and for\nsystemd. I also took this opportunity to set up litestream\nfor backups as well.

\n

Now that everything’s mostly stable, I can finally document all my configuration\nfor anyone else to use.

\n

Under the hood it’s using Quadlets,\nso all of the unit files we’ll create in /etc/containers/systemd.

\n

First we create a pod to contain everything and publish the port:

\n
pds.pod
[Pod]
Volume=pds.volume:/pds
PublishPort=127.0.0.1:3000:3000
\n

Then we slot in a volume:

\n
pds.volume
[Unit]
Description=Bluesky PDS Volume
\n
[Volume]
Label=app=pds
\n

Now that we’ve got everything organized, we can bring in the PDS container itself:

\n
pds.container
[Unit]
Description=Bluesky Personal Data Server service
Before=caddy.service
\n
[Container]
Label=app=pds
Image=ghcr.io/bluesky-social/pds:0.4
AutoUpdate=registry
Pod=pds.pod
EnvironmentFile=/opt/pds/pds.env
\n
[Install]
WantedBy=multi-user.target default.target
\n

I make this container boot before my Caddy service which brings up all the\nassociated resources as part of the quadlet.

\n

We then make the appropriate changes to the Caddyfile:

\n
/etc/caddy/Caddyfile
[...]
*.at.jkp.sh, at.jkp.sh {
        tls {
                on_demand
        }
        reverse_proxy http://localhost:3000
}
[...]
\n

Now I get autoupdates for my PDS without needing to use the watchtower container\nalong with logs that feed right into systemd. Additionally, my PDS storage\nitself ends up abstracted away for me in a podman volume, rather than being\nscattered in a random non-standard place on my VPS. In short, it does basically\nexactly what I want it to do, just the way I want it, with some learnings along\nthe way.

\n

Footnotes

\n
    \n
  1. \n

    I’ve actually moved this server back over to an Ubuntu 24.04 deployment,\ndue to RHEL-likes running a bit slow for me when it comes to package updates —\njust kidding, it’s back to using CentOS Stream now ↩︎

    \n
    2. \n
  2. \n

    the oneshot method is a totally valid way of doing it to make it “easy”,\nbut it had too many quirks / compromises for my liking ↩︎

    \n
    3. \n
\n
", "url": "https://jack.is/posts/self-hosting-your-pds/", "title": "Self hosting your PDS with Podman", "summary": "A writeup of gotchas and other fun stuff along the way of deploying a PDS", "date_modified": "2025-11-24T06:18:20.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/fantastic-favicons/", "content_html": "

I’ve finally made my own favicon (inspired by the un-imitable Robb), instead of just using the generic Astro one\nthat everyone gets when you make a website.

\n

I wanted to go the extra mile though and make sure it matched the theme of the\nsite. After a bit of digging I discovered that SVG supports media queries, so\nall the fun light/dark mode detection we can do with CSS on the web, also works\nin your favicon (at least assuming you’re using a browser that supports SVG favicons. 1)

\n

After vectorizing my work, I added some classes to the paths, put it all in a\nsingle SVG like so:

\n
    [...]
    <path d=\"m213 87h138v140h-89v86h-49zm49 90h39v-40h-39z\" fill=\"#eaedf3\" fill-rule=\"evenodd\"
            class=\"dark\"></path>
    </svg>
    <style>
        @media (prefers-color-scheme: light) { .dark { display:none; } }
        @media (prefers-color-scheme: dark) { .light { display:none; } }
    </style>
\n

All I have to do is treat it like any other SVG favicon and it just works.

\n

Sadly, it doesn’t work in Safari, so Safari will always have a light mode\nfavicon. Not the end of the world, just a bit of a bummer.

\n

Footnotes

\n
    \n
  1. \n

    Can I use SVG favicon? ↩︎

    \n
    2. \n
\n
", "url": "https://jack.is/posts/fantastic-favicons/", "title": "Fantastic Favicons and Where To Find Them", "summary": "Did you know that CSS in SVGs can use media queries?", "date_modified": "2024-12-30T07:31:23.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/verifying-verification/", "content_html": "

Imagine it’s the late 90s, and you want to see what the New York Times has to\nsay about your favorite political topic this week. Now you’ve heard they’ve\nfinally gotten on the InterNet? The World Wide Web? You’re not quite sure what\nto call it, but you have a Sunday edition in your living room, and it has a web\naddress in the masthead.

\n

You open up Netscape Navigator, type in http://www.nytimes.com and your DSL\nconnection chugs for a second as more kilobits than a computer from the 80s\nwould know what to do with fly into your shiny new Dell.

\n

After all of that though, you know you’re at the New York Times’ website, since\nyou went there right from their physical paper. There wasn’t a middleman, or\nanyone telling you that they were in fact the Gray Lady, you just did a little\nbit of leg work.

\n

Time Warp

\n

Now it’s 2010, and you want to see what the Times has to say about your favorite\npolitical topic this week. You could head to their website, grab the paper\nfrom the guy on the corner, or for your first time you could open up this new\nwebsite called Twitter, and there’d just be a handful of words written by the\nTimes, summarizing a story, and you wouldn’t have to go anywhere. How do you\nknow if it’s actually the Times? Well Twitter thought of that for you, and they\nadded a little blue checkmark next to their account for you. 1

\n

Now you can trust that @nytimes is the Times on Twitter, right? Right? Well for\na while you used to be able to, but eventually it all fell apart. And in my\nopinion, that’s a large part of why Bluesky is popping off (or “has the juice”\nas the kids say) as Twitter / X slowly begins the doom spiral that any site\nsees in the future as they become no longer relevant.

\n

The “problem”

\n

So Bluesky / ATProto\nis created to decentralize Twitter (originally, then is spun off entirely pre\nMusk acquisition), and a primary tenet of both Bluesky PBLLC (the corporation)\nand\nATProto (the protocol itself) is to ensure that long term, the ecosystem is\nprotected from any actor in the space from turning hostile. There’s no “special\nsauce” that Bluesky PBLLC has (other than chat/DMs but we’ll set that aside for\nthe time being) that is exclusive to them.

\n

Every part of the ecosystem then needs to be designed to be hostile-proof,\nfrom where user data lives, to how users consume and create data. This goes as\nfar as how user identities are stored and referenced. There’s been a lot of work\nput in to ensure that in the long run, you are totally in control of your\nidentity, not Bluesky PBLLC.

\n

So the “problem” here is that Bluesky doesn’t have a concept of verification,\nat least not the way Twitter had. There is no “central arbiter” of trust,\nbecause how can you have a central arbiter of trust when the entire ecosystem\nis designed to avoid that single point of failure?

\n

Instead all the “verification” is done with domain names, and there’s been\nmore than a few folks upset / weirded out / annoyed that there isn’t as much\nverification as there was on Twitter.

\n

The more I think about it though, the less I think it is a problem, and more\nus as a social media using society not remembering the olden days.

\n

Why this matters

\n

We’ve spent the last 10-15 years forgetting that the web is a protocol, not a\nplatform. Mike Masnick touched on this in Protocols, not Platforms\n(and in fact is now on the board of Bluesky PBLLC). In the example of the 90s,\nthere wasn’t a platform saying whether or not the NYTimes on the web was\n“verified”, there was just a little bit of legwork to check and crosscheck that\nindeed this website was theirs. There was no middleman, just a protocol.

\n

However, in the next time warp, we’re instead relying on these centralized\nparties to decide who is and isn’t verified, and shifts us to treating the web\nas a platform, not a protocol. People don’t browse the web, they use Facebook,\nthey use Twitter.

\n

The concept of domain handles, verification, the whole nine on how Bluesky\nhandles this is the first step on getting us as an internet-using society back\nto protocols.

\n

A domain is the most ownership of anything you can have on the web. If a new\nATProto social site opens up, you know that jack.is there is also me, just\nlike you know it’s my Bluesky account, just like you know it’s the site you’re\nreading right now. I own my identity, not Instagram, or Twitter, or Bluesky, and\nI think that means something more than a little check in a circle that gives me\nthe good feelings.

\n

Footnotes

\n
    \n
  1. \n

    “So you see, that’s where the trouble began. That check; that damned check” ↩︎

    \n
    2. \n
\n
", "url": "https://jack.is/posts/verifying-verification/", "title": "Verifying verification", "summary": "alternatively: how I learned to love did:plc", "date_modified": "2024-12-03T15:01:55.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/bluesky-comments/", "content_html": "

After being inspired by Emily Liu’s post on\nhow to do Bluesky comments, I thought I could add it here too, but with one\nminor plus to it.

\n

Emily’s method was great, but required hardcoding the atproto URI into the post\nitself. That’s a little hard to do with my deployment and post method, where the\nRSS feed is generated, and then that triggers an Echofeed\n(Not Sponsored) that posts to Bluesky.

\n

Because of this, I wanted something better. Ideally, I could have it just find\nthe right post without me having to worry about it. Thanks to the power of the\nBluesky API, I’m able to do that!

\n

The special sauce is right here in getPostAndThreadData. It runs a search for\nthe Echofeed emoji I use for all my posts (📝), looks for my author DID, as well\nas the page URL that would have been posted. It then limits it to 1, and grabs\nthat URI. Once we’ve got a URI, we then pass it to Emily’s code like normal\nalong with some styling and design tweaks.

\n

Is it perfect? Not yet, but now it’s just fine tuning some CSS styling (and also\ngetting React to be chunked a little better).

\n
src/components/react/BlueskyComments.tsx
const getPostAndThreadData = async (
  slug: string,
  setThread,
  setUri,
  setError,
) => {
  const agent = new Agent(\"https://public.api.bsky.app\");
  const assembledUrl = \"https://jack.is/posts/\" + slug.toString();
  try {
    const response = await agent.app.bsky.feed.searchPosts({
      q: \"📝\",
      author: \"did:plc:cwdkf4xxjpznceembuuspt3d\",
      sort: \"latest\",
      limit: 1,
      url: assembledUrl,
    });
    const uri = response.data.posts[0].uri;
    setUri(uri);
    try {
      const thread = await getPostThread(uri);
      setThread(thread);
    } catch (err) {
      setError(\"Error loading comments\");
    }
  } catch (err) {
    setError(err);
  }
};
\n

In the words of Brennan Lee Mulligan: “GET IN THE COMMENTS!”

", "url": "https://jack.is/posts/bluesky-comments/", "title": "Blog, now with Bluesky comments", "summary": "A show and tell of my new comments section powered by Bluesky", "date_modified": "2024-11-26T01:41:27.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/analytics-showdown/", "content_html": "

Doing an analytics showdown on the site here between a few services to see which\none shall win for 2025.

\n

Tinylytics

\n

My current provider of some of the juicy info (and provider of the fancy kudos)\nbuttons. It gets the job done, but I’d love to see more info.

\n

Goatcounter

\n

Offers more information, has a sweet craigslist-era aesthetic, and could be self\nhosted if I want.

\n

Umami

\n

My current front runner in all honesty. Has everything I want, and then some,\nand is being selfhosted by me right now. Does what I need it to do and I think\nwill win.

\n

If I switch however, I’m going to have to reimplement my upvote buttons somehow\nbut that’s a problem for future me.

\n

Update

\n

Umami self-hosted won.

", "url": "https://jack.is/posts/analytics-showdown/", "title": "Analytics Showdown", "summary": "Some more analytics in play here", "date_modified": "2024-11-21T22:21:02.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/blog-updates-part-2/", "content_html": "

All the dust should have finally settled from the tweaks I’ve made to the\nsite. Now everything is one page which allows for fancy view transitions from my\nlinks right to the blog. I did break RSS again (sorry Joshua) but no way to do\nthat migration nicely.

\n

Now I can have my blog and my\nPDS for Bluesky\nall in one place. With that said, I still haven’t moved my Bluesky account to my\nPDS just yet, but it’s ready to go for when I’m ready to push the button.

", "url": "https://jack.is/posts/blog-updates-part-2/", "title": "Blog updates part 2", "summary": "Pardon the dust, again", "date_modified": "2024-11-19T01:42:09.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/on-bluesky/", "content_html": "

So, Bluesky is now a thing. I mean it was a thing before today, but the past\nweek or so seems to have been the “screw it i’m outta here” moment for a lot of\nfolks on X, the everything app Twitter1. I made my account long before\nthis Eternal September, but I think I might spend more time on there than I had\nbeen previously. Here’s some random-ish thoughts on how I feel about Bluesky,\nATProto, and how I feel about Mastodon / ActivityPub as a consequence.

\n

The Vibes

\n

Twitter, and I mean Twitter before it turned to hell in a handbasket, had vibes\nfrom various circles. You had Tech Twitter, you had Weird Twitter2, etc. Even\nwith all of that though, the vibes and memes were still often in sync because\neveryone was using the same app, and had at least some of the same trending\ntopics they were aware of. Milkshake Duck, bean dad. There was always a main\ncharacter, and often you didn’t really want to be the main character.

\n

For better or for worse, Mastodon doesn’t always have those vibes in my opinion.\nIt’s often a little bit stuffy. I’ve found Tech Twitter there in many ways, but\nWeird Twitter never seemed to migrate there, even when it was first popping off\nbefore Bluesky was a thing.

\n

Bluesky though has all your circles, and is picking up at a much faster than\nMastodon ever did. You’ve got your\ndril, you’ve got your\ndarth, you’ve got your\nWeRateDogs. Having one of those on\nMastodon was a challenge, and I don’t think there was ever a time even if all\nthree of those accounts had an Mastodon / AP presence at all, were they ever\nposting at the same time.

\n

So the vibes are there for Bluesky like Old Twitter the way Mastodon just isn’t.\nBut what about the tech?

\n

The Tech

\n

Now I was an avid ActivityPub defender (and still am to some extent) when\nATProto originally launched, and was feeling like Bluesky was too “corporate”,\nand kind of didn’t look into it much, and only begrudgingly joined.

\n

Only relatively recently did I do a deeper dive into the pros and cons of\nATProto, and I’ve sort of turned around on how I feel about the two.

\n

I tried to run my own Mastodon server one time, and to be honest it Kinda\nSucked. Mastodon simply doesn’t scale well down to one or two users. It’s fine\nif you’re on a larger server as you can share the load (shoutout\nAdam for omg.lol\nand the associated Mastodon server social.lol), but the effort I had to go to to\neven try to get Mastodon working on a server that already had services on it and\nit was not fun.

\n

Mastodon also has some odd protocol design decisions that make life harder for\nsmall web, which seems oddly counter-intuitive. The most obvious one (and one\nthat I’ve talked about in the past)3 is the fact that any rich link previews\nfor any posted link (the OpenGraph info) is fetched by every single\nActivityPub instance that sees that post. In other words, if you’re followed by\n1,000 users on 1,000 separate Mastodon / ActivityPub instances, and you post a\nlink to your neat little blog, in the span of a few seconds, you’re going to get\n1,000 requests to your website. Is this necessary? Not really, but it’s the way\nthe protocol has been designed, and continues to stay that way. There’s even a\ncute name for it, a Mastodon stampede4. This just isn’t sustainable.

\n

ActivityPub is also aggressively chatty when it comes to the actual\ncommunication between servers. Migrating between servers is basically just like\nshoving a HTTP 302 at your followers and hoping for the best. You don’t get to\nmove your posts, just your followers and following. Your username doesn’t stay\nthe same either.

\n

ATProto on the other hand is built on layers of abstraction, so your handle is\njust a reference to a permanent identifier. Change your handle, no problem. Want\nto move your account entirely from one PDS (Personal Data Server) to another? No\nproblem. The protocol has support for it from the beginning. Rather than sending\na bunch of pushes when you post something, your PDS just adds a new post to your\nPDS, and the network aggregates and displays to clients. It just feels cleaner.\nSpinning up a PDS compared to a Mastodon server is like night and day. I was up\nand running with my self-hosted test user in about 10 minutes and that was with\nhaving to tweak the install script slightly to meet my preferences.

\n

The Summation

\n

So which one should win? It’s not that one can win and the other shouldn’t, they\neach have different design goals. However, I’ve come around on which one is (at\nleast currently), more scalable, and I think it’s ATProto. From a social\nperspective, Bluesky seems to be winning the normal user demographic, which\nMastodon always had trouble getting users to adopt.

\n

As for my self-hosted PDS, I’m still deciding whether or not to move my current\nBluesky hosted account to it. There’s currently no import path back to Bluesky\n(not because of protocol reasons, but because of giant account reasons), and\nthat makes me feel like this is a permanent commitment if I do. We’ll see I\nguess.

\n

Footnotes

\n
    \n
  1. \n

    considering that you still can’t use X as a bank like was promised, lol ↩︎

    \n
    2. \n
  2. \n

    see dril, et al. ↩︎

    \n
    3. \n
  3. \n

    have I overused parentheticals yet? since I used another one in the\nfollowing line, clearly not ↩︎

    \n
    4. \n
  4. \n

    get it, because mastodons are like elephants and elephants stampede? I’m\ndone with the footnote overuse I promise ↩︎

    \n
    5. \n
\n
", "url": "https://jack.is/posts/on-bluesky/", "title": "On Bluesky", "summary": "Some random thoughts on Bluesky (and Mastodon)", "date_modified": "2024-11-16T05:29:26.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/blog-update/", "content_html": "

We (I? I’m not a fan of talking about myself in the third person, but that’s\nneither here nor there) now have a few cool new things.

\n

Author Attribution on Fediverse

\n

Thanks to Robb\nposting it, I now have my fancy fediverse author tags configured, so it shows\nattribution properly when my post is posted.

\n

It’s simple, but it’s neat.

\n

Tri-state dark mode selector

\n

And I don’t mean the tri-state area. 1

\n

The Astro them I use, Astro Paper supports both\nlight and dark mode. However, once you click the selector, it switches from\nusing system selected (prefers-color-scheme) to the user selected option and\ndoesn’t allow a way of switching back. I didn’t love this, so I added a third\noption.

\n

Now the theme picker rotates between system, light, and dark. Pick whichever\ntheme suits your fancy, no matter what your operating system tells your browser.\nOr pick system and let your operating system be the boss. You decide.

\n

Footnotes

\n
    \n
  1. \n

    boo this man ↩︎

    \n
    2. \n
\n
", "url": "https://jack.is/posts/blog-update/", "title": "Blog Updates", "summary": "A quick update", "date_modified": "2024-10-09T23:33:46.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/sorry-in-advance/", "content_html": "

So turns out that I had some mismatched links (trailing slash vs no trailing\nslash) and keeping track of all the places where they were mixed up was\nimpossible.

\n

In other words, sorry for your RSS reader getting confused again if it sees all\nmy posts as new entries again since the guid changed. We should be good now\nthough, with less breaking of your readers.

", "url": "https://jack.is/posts/sorry-in-advance/", "title": "Sorry to RSS readers", "summary": "an apology for the annoying RSS tomfoolery that's been going on", "date_modified": "2024-04-12T13:27:50.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/mastodon-stampede/", "content_html": "

If you’re running a site that dynamically generates content, you should probably\ndo some sort of caching to prevent your site from exploding whenever someone\nposts it on Mastodon and friends.

\n

For example, if you use Caddy, it might look something like this:

\n
        @fedi {
                header_regexp User-Agent (http\\.rb/\\S+\\s\\(Mastodon|Friendica|Pleroma\\s|Akkoma\\s|Misskey/|gotosocial)
        }
\n
        # do something with the detected user agent that's cache-y
\n

Since this blog is static, I just tank the Mastodon hits as necessary, but\nsomething to keep in mind if you’re hosting your own thing.

", "url": "https://jack.is/posts/mastodon-stampede/", "title": "Mastodon Stampedes", "summary": "\"fun\" fact: each Mastodon server gets their own copy of your OG card", "date_modified": "2024-04-09T18:19:02.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/new-domain/", "content_html": "

After literal years of jonesing for it, I’ve finally gotten jack.is as a\ndomain. Sorry for whoever previously had it, but you did let it go after all.

", "url": "https://jack.is/posts/new-domain/", "title": "A new brand", "summary": "A new domain for the blog and brand", "date_modified": "2024-04-05T00:00:00.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/blog-setup-2024/", "content_html": "

A semi-deep dive into the newly deployed plttn.me.

\n\n

It’s time for the regularly scheduled blog updates.

\n

Yesterday (metaphorically speaking)

\n

The prior setup was using Hugo and deployed to either Netlify, Cloudflare Pages\nor my own box. This was great, but after thinking through the Small Web ™️\nmovement some more I thought it made more sense to move to something in-house.

\n

Today

\n

The site now uses Astro and deploys right to my server.\nFor deploying, it’s a two-step process. All commits on main on GitHub are\nchecked. After everything checks out, I can trigger a release in GitHub to\ndeploy to my server.

\n

Here’s part of one workflow:

\n
name: Check pushes
on:
  push:
    branches:
      - main
\n

Here’s the other:

\n
name: Deploy
on:
  release:
    types: [published]
\n

DNS Sidenote

\n

I’ve also switched to using Desec for my DNS hosting, it\nfits my needs nicely, is free, and enforces DNSSEC.

\n

Hopefully the first of multiple blog posts to come.

", "url": "https://jack.is/posts/blog-setup-2024/", "title": "Blog Setup 2024", "summary": "A brief summary of the newly deployed plttn.me", "date_modified": "2024-01-28T15:33:51.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/pardon-the-dust/", "content_html": "

Pardon the dust. Updates in progress.

\n\n", "url": "https://jack.is/posts/pardon-the-dust/", "title": "Pardon the Dust", "summary": "More to come soon", "date_modified": "2024-01-27T21:15:07.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/yet-another-octopress20-guide/", "content_html": "

So there’s only about 30 50 thousand pages on this general topic, but I\nfound that about half of them were out of date, so I figured I should try and\ncollect all the info into one big post. I’ve referenced where I’ve found some of\nthe stuff that’s harder to find from Googling using the wonders of Octopress\nfootnotes.

\n

Unfortunately, as I was finishing up this post, the post announcing Octopress\n3.0 comes out. While I had known it was coming, I wasn’t expecting it to be so\nsoon. Obviously this post will be less useful, but it should still be\ninformative. I’ve included what I think will need to be modified to function on\n3.0 at the bottom.

\n

Table of contents

\n

My Site Flow

\n\n\n

I’ve got a drafts workflow using a couple tasks I found online1 and then\npromptly modified:

\n
## -- Misc Configs -- ##
\n
drafts_dir      = \"_drafts\" # directory for draft files
\n
# usage rake new_draft[my-new-draft] or rake new_draft['my new draft'] #
desc \"Begin a new draft in #{source_dir}/#{drafts_dir}\"
task :new_draft, :title do |t, args|
if args.title
title = args.title
else
title = get_stdin(\"Enter a title for your post: \")
end
raise \"### You haven't set anything up yet. First run `rake install` to set up an Octopress theme.\" unless File.directory?(source_dir)
mkdir_p \"#{source_dir}/#{drafts_dir}\"
filename = \"#{source_dir}/#{drafts_dir}/#{title.to_url}.#{new_post_ext}\"
if File.exist?(filename)
abort(\"rake aborted!\") if ask(\"#{filename} already exists. Do you want to overwrite?\", ['y', 'n']) == 'n'
end
puts \"Creating new draft: #{filename}\"
open(filename, 'w') do |post|
post.puts \"---\"
post.puts \"layout: post\"
post.puts \"title: \\\"#{title.gsub(/&/,'&amp;')}\\\"\"
post.puts \"comments: true\"
post.puts \"#placeholder\"
post.puts \"categories: \"
post.puts \"---\"
end
end
\n
# usage rake publish_draft
desc \"Select a draft to publish from #{source_dir}/#{drafts_dir} on the current date.\"
task :publish_draft do
drafts_path = \"#{source_dir}/#{drafts_dir}\"
drafts = Dir.glob(\"#{drafts_path}/*.#{new_post_ext}\")
drafts.each_with_index do |draft, index|
begin
content = File.read(draft)
if content =~ /\\A(---\\s*\\n.*?\\n?)^(---\\s*$\\n?)/m
data = YAML.load($1)
end
rescue => e
puts \"Error reading file #{draft}: #{e.message}\"
rescue SyntaxError => e
puts \"YAML Exception reading #{draft}: #{e.message}\"
end
puts \"  [#{index}]  #{data['title']}\"
end
puts \"Publish which draft? \"
answer = STDIN.gets.chomp
if /\\d+/.match(answer) and not drafts[answer.to_i].nil?
mkdir_p \"#{source_dir}/#{posts_dir}\"
source = drafts[answer.to_i]
filename = source.gsub(/#{drafts_path}\\//, '')
dest = \"#{source_dir}/#{posts_dir}/#{Time.now.strftime('%Y-%m-%d')}-#{filename}\"
puts \"Publishing post to: #{dest}\"
File.open(source) { |source_file|
  contents = source_file.read
  contents.gsub!(/^#placeholder$/, \"date: #{Time.now.strftime('%Y-%m-%d %H:%M %z')}\")
  File.open(dest, \"w+\") { |f| f.write(contents) }
}
FileUtils.rm(source)
else
puts \"Index not found!\"
end
end
\n

For this to work using rake preview, you’ll need to modify your preview task\nslightly, add the flag --drafts to the jekyll call.

\n
system \"compass compile --css-dir #{source_dir}/stylesheets\" unless File.exist?(\"#{source_dir}/stylesheets/screen.css\")
jekyllPid = Process.spawn({\"OCTOPRESS_ENV\"=>\"preview\"}, \"jekyll build --watch --drafts\")
compassPid = Process.spawn(\"compass watch\")
\n

The Build Process

\n

Personally, I don’t want to have to deal with building and uploading my site.\nInstead I use Travis-CI targeted to a specific Github repo branch, and some\nmodified rsync scripts.

\n
language: ruby
cache: bundler
\n
rvm:
  - 1.9.3
branches:
only:
  - master
\n
before_install:
  - echo -e \"Host *\\n\\tStrictHostKeyChecking no\\n\" >> ~/.ssh/config
  - echo -e \"$DEPLOY_PRIVATE_KEY\" > ~/.ssh/id_rsa
  - chmod 600 ~/.ssh/id_rsa
  - eval `ssh-agent -s`
  - ssh-add ~/.ssh/id_rsa
\n
script:
  - bundle exec rake integrate #move any stashed posts to source
  - bundle exec rake generate #generate static to /public
  - bundle exec rake deploy #rsync /public to server
\n

Rsync Setup

\n

\"Travis

\n

You’ll need to configure your deployment account’s SSH private key in Travis-CI\nby replacing all new lines with \\n, and then escaping that to \\\\n, so that\nit ends up being one line with \\\\n in between each original line.2\n(NOTE: Make sure the key was generated without ssh-agent running, and set a\nblank passphrase.) Next, go to your Travis-CI settings, create a new environment\nvariable, name it whatever you want, I used $DEPLOY_PRIVATE_KEY, then paste in\nyour one-line private key into the variable section. Now that it’s a environment\nvariable in all Travis workers your builds will use, the before_install tasks\nwill disable strict host key checking (requires input, which Travis doesn’t\nallow), and then echo the contents of DEPLOY_PRIVATE_KEY to id_rsa, then add\nthat key to the ssh-agent, in my case, allowing the worker to connect using the\nuser travis-ci to my droplet.

\n

If the user you’re connecting with in your Rakefile’s settings isn’t the owner\nof your specific directories on your hosting server, rsync will probably fail to\nsync properly. In that case, you’ll need to add --omit-dir-times to\nrsync-args in the Rakefile.

\n

After all of this, you should be good to go. If you’re using the master deploy\nmethod, push your site up to master, and it should build properly on Travis, and\ndeploy to your rsync destination.

\n

Octopress 3.0

\n

For the most part, as far as I can tell, these modifications will mostly still\nwork for 3.0. The drafts changes will no longer be needed anymore, as the Jekyll\ndrafts workflow is now using a separate drafts folder. The .travis.yml will\nneed to be tweaked slightly, as well as the _config.yml having an exclude\nadded to keep Jekyll running on Travis-CI from trying to build the templates in\n/vendor, but other than that, this post is mostly forwards compatible to\nOctopress 3.0.

\n

Footnotes

\n
    \n
  1. \n

    Never Stop Building ↩︎

    \n
    2. \n
  2. \n

    Grosser.it ↩︎

    \n
    3. \n
\n
", "url": "https://jack.is/posts/yet-another-octopress20-guide/", "title": "Yet Another Octopress 2.0 and TravisCI Guide", "summary": "A quick (and outdated guide) on how to use TravisCI to deploy a Octopress blog", "date_modified": "2015-01-17T19:18:29.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/atcute-comments/", "content_html": "

Having comments on my blog with Bluesky is pretty nice, but what’s not so nice\nis having to bring in the entire @atproto/api package. It seemingly can’t be\ntree shaken down via Vite, so you end up with a massive JS file for comments.

\n

How massive is it? More than 700kB.

\n

\"screenshot

\n

It’s kinda a lot, and as it is I had to tweak my Astro config to make Vite not\nwarn about this:

\n
astro.config.ts
  vite: {
    optimizeDeps: {
      exclude: [\"@resvg/resvg-js\"],
    },
    build: {
      chunkSizeWarningLimit: 768,
      // TODO find a better way to handle this
      // where \"this\" means the bsky react import chunk size
    },
  },
\n

I wasn’t a huge fan of this for a few reasons. One, that was a lot of unneeded\nJS being delivered that I didn’t need, and I had to modify a warning setting\nwhich seemed less than ideal.

\n

I had seen @atcute/client by Mary float across my\nfeed, and poked at it a bit, but only after I figured out how to make unauthenticated\nrequests with it did it become clear how much better it was going to make my\nbundles.

\n

Only took a little bit of modifying the work I had done using Emily Liu’s example\nto instead use atcute:

\n
src/components/react/BlueskyComments.tsx
const rpc = new XRPC({
  handler: simpleFetchHandler({ service: \"https://public.api.bsky.app\" }),
});
\n
const agent = new Agent(\"https://public.api.bsky.app\");
const assembledUrl = \"https://jack.is/posts/\" + slug.toString();
\n
const response = await agent.app.bsky.feed.searchPosts(...);
const response = await rpc.get(\"app.bsky.feed.searchPosts\", {
  params: {
    q: \"📝\",
    author: \"did:plc:cwdkf4xxjpznceembuuspt3d\",
    sort: \"latest\",
    limit: 1,
    url: assembledUrl,
  },
});
\n

The unexpected benefit here is that @atproto/api didn’t actually have all the\nhelper functions Emily needed for it to work, so there was a direct call to one\nof the xrpc endpoints. Now that everything just uses rpc.get, it’s a lot more\nconsistent and easier to follow.

\n

I did have to add a few //@ts-expect-error sprinkled around, but they’re all\nguarded by typeguards so I’m not too worried.

\n

Now instead of 700kB, my BlueskyComments.js is only 10kB. A vast improvement.

\n

Thanks again to Emily for posting their code to begin with, and Mary for an\nexcellent suite of tooling that’s much more compact than the full ATProto API.

", "url": "https://jack.is/posts/atcute-comments/", "title": "Optimizing Bluesky comments", "summary": "using @atcute/client to make comments better", "date_modified": "2025-01-12T06:31:38.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/editor-setup-2020/", "content_html": "

Goodbye Atom

\n

I wanted to like Atom, and I was one of those stubborn ones who had been putting\noff trying VS Code for probably years and continued to use Atom and putting up\nwith the subpar performance, even on a relatively overpowered computer.

\n

A few weeks back though, I decided to bite the bullet and give VS Code a fair\ntry, and after using it for just a few days, I didn’t see myself going back to\nAtom anytime soon. There’s just so much more performance in Code compared to\nAtom (which confuses me because they’re both Electron), and included in that\nperformance is more features included standard, instead of needing 100\nextensions to get what I want out of it.

\n

Looking at the writing on the wall, I don’t foresee Atom lasting too much\nlonger, I haven’t seen a new feature added to Atom since right around the time\nAtom Teletype came out, and then that’s been pretty much it since then.

\n

Sadly this means my theme that I’ve spent the better part of five years tweaking\nand modifying will end up slowly dying, but given that Pubster really isn’t\nprimarily my work when you boil it down, I don’t feel too bad about it.

\n\n

Hello Code

\n

So what’s my Code look like now?

\n

\"Editor

\n

I’ve started using Iosevka as my programming font with it configured to more or\nless match Pragmatica Pro’s font features, and I’m really enjoying it so far.\nI’ve tried a bunch of different fonts, and had tried Iosevka in the past and\nwasn’t sure how I felt about it, but now that it’s got ligature support and\ndecent hinting, I’m a fan. Additionally, for plain text editing (markdown,\nplaintext, commit messages), I switch over to Iosevka Sparkle which is designed\nfor prose use using settings.json overrides for specific languages:

\n
\"[markdown]\": {
  \"editor.defaultFormatter\": \"esbenp.prettier-vscode\",
  \"editor.fontFamily\": \"Iosevka Sparkle, Iosevka\"
}
\n

As for the color scheme itself, I decided to give\nMonokai Pro a try, and I’m really loving it. The theme\nitself is nice, and the file icon themes it comes with are also fantastic and\nclear without being obnoxious. While it does cost a few bucks, for how nice it\nlooks I think it’s definitely worth it.

", "url": "https://jack.is/posts/editor-setup-2020/", "title": "Editor Setup 2020", "summary": "A quick summary of my current (at the time) VSCode setup.", "date_modified": "2020-05-26T19:29:00.000Z", "author": { "name": "Jack Platten" } }, { "id": "https://jack.is/posts/comments-api/", "content_html": "

Have we yak shaved enough yet on comments? I don’t think we have, what’s one\nmore post among friends.

\n

The problem

\n

As mentioned in Bluesky Comments, my posting workflow\ndoesn’t allow me to know the Bluesky post ahead of time. So I thought, well I’ll\njust use the search API to find the post URL based on my echofeed post. That\nworked pretty well, but then I saw this skeet:

\n
\"bryan
bryan newbold (⛱️ sabbatical edition) @bnewbold.net
\"Bluesky\"

please don't use the bsky \"search\" endpoints as a generic API or for automation. it is not designed for that, is an expensive waste/abuse of resources, and we will block by IP or user agent.\n\nsearches should come from direct human queries in the moment

January 19, 2025 at 7:08 PM UTC
\n

My first reaction was “Oh it’ll be fine this is just limited use and there was\nanother post that says it’ll be fine for limited use”. It was fine, but after a\nday or so after Bryan’s post, I started getting CORS errors from my search\nfunction, and I figured that was that, and I needed to do this a better way,\nand maybe learn something along the way.

\n

The research

\n

I had seen Jetstream in my research prior to now, and figured some sort of\ndatabase would probably be the best bet, where it’s just a single lookup, rather\nthan every browser of the site having to do the search (even if it wasn’t blocked).

\n

My initial thought was using Typescript for a server API, and there’s definitely\nstill benefits to there, being a robust ecosystem of ATProto packages. I however\nwanted to Think Different™ so I decided to write it in Rust, both because I\ncould, and also because I wanted to learn a bit of Rust “systems” programming,\nsince I’ve been spending a lot of my day in Typescript.

\n

After doing some very detailed Kagi searches 1, I discovered Rocket\nand determined it was actually perfect for my needs. Simple declarations of\nhandler functions, and it’s nice and type-safe. What’s not to like.

\n

It’s Rust time

\n

With just a bit of boilerplate code, I can spin up the API handler needed for\nthe metadata info for my front-end.

\n
main.rs
#[get(\"/\")]
fn index() -> &'static str {
    \"at-comments database API server\"
}
\n
#[get(\"/<slug>\")]
fn post_meta(slug: &str) -> Result<Json<models::Post>, NotFound<String>> {
    match db::post_meta(slug) {
        Ok(post) => Ok(Json(post)),
        Err(_) => Err(NotFound(\"Resource was not found.\".to_string())),
    }
}
\n
#[launch]
async fn rocket() -> _ {
    // setup websocket stuff
    tokio::spawn(post_listener::subscribe_posts());
    // setup server to respond
    rocket::build()
        .mount(\"/\", routes![index])
        .mount(\"/\", routes![post_meta])
}
\n

There’s two important parts here in the main server, and I’ve labeled them A and\nB.

\n

Part A: Metadata endpoint

\n

We’ll say for the sake of argument that somehow the web server has the info\nfor a given post already (since we’ll discuss the Jetstream and DB in part B),\nso part A is the thing that looks up info for a given post. One of the nice\nthings about Rocket is that it has lots of type guards, so all I need to do\nis specify that it should be expecting a string input in the path, and it’s\ngoing to return a Result<Json<models::Post>, NotFound<String>>. We call out to\ndb::post_meta(slug) which checks the database using the post slug, and returns\nthe Post object. Since Post is tagged as a Serialize struct in db.rs, Rocket\ncan just convert it to JSON using library code and safely return it. If it’s not\nfound, then it just returns a 404 and we move on with our day.

\n

The comments code now just needs to make a request to the endpoint to get the\nBluesky post rkey:

\n
BlueskyComments.tsx
const getPostAndThreadData = async (
  slug: string,
  setThread: (thread: AppBskyFeedDefs.ThreadViewPost) => void,
  setUri: (uri: string) => void,
  setError: (errorString: string, error: string) => void
) => {
  const url = `https://meta.jack.is/${slug}`;
  const meta = (await ky.get(url).json()) as Meta;
\n

After getting the metadata, it just acts like normal.

\n

Part B: Websockets and databases

\n

So how do we get the post info to put in a database for the API route to have\nwhat it needs? Bluesky Jetstream of course. Using jetstream-oxide,\nas well as the patches from cyypherus, we can now listen to the Jetstream and\nfilter for just my posts. This actually ends up being more robust than the old\nsearch API, as here I can restrict my filter to “just posts with 📝 as the first\ncharacter”, which couldn’t easily be done using the search API.

\n

Using Diesel the websocket loop then inserts into a postgres\ndatabase with all the info needed for the front-end to find the post.

\n

Next steps

\n

There are one or two improvements I’d like to make here, primarily around the\ndatabase handling. It’s not using connection pooling at the moment, but figuring\nout how Rocket handles all of that (and passing a connection to an arbitrary tokio\nfunction) was out of scope for this MVP.

\n

In case you’re curious, you can find the code here: at-comments-listener.\nIt’s primarily designed for me, so there’s a lot of stuff in there that’s hard\ncoded, but maybe someone will find it interesting.

\n

Footnotes

\n
    \n
  1. \n

    “rust web server framework” ↩︎

    \n
    2. \n
\n
", "url": "https://jack.is/posts/comments-api/", "title": "Comments API", "summary": "On how I learned something new, and made my comments better in the process", "date_modified": "2025-01-26T07:02:45.000Z", "author": { "name": "Jack Platten" } } ] }