What happened was, soon after New Year’s, friends and colleagues in the UK and Germany started letting us know that their emails to us were bouncing. Our “textuality.com” family domain is a Google Workspace (or whatever they call it this year) for email and docs and so on. Its Web presence, including DNS, has for many years been handled by a local outfit I’ll call “CWH” for some absurdly low monthly price, and has been trouble-free.

So, what could be wrong? We investigated and discovered that Google was offering a new-and-improved MX-record option, although they emphasized that the old setup should still work. Anyhow, we installed the New Thing and it didn’t help.

So, we filed a ticket with CWH tech support and somebody got back to us pretty quick, saying they’d changed a firewall setting that was blocking connections to Germany. I detect the scent of GDPR, but whatever.
Euro-email: Bounce, bounce.

CWH: Probably an MX-record issue, and we should wait for DNS propagation. Several days passed and bounce, bounce, bounce.
Us: “Not DNS propagation.”
CWH: “Still could be.”

So we VPN’ed to Germany and discovered we couldn’t ping Textuality’s IP address. Smells like a firewall to me. We told CWH that.

CWH: We have made some changes to firewall settings.
EMail: bounce, bounce, bounce.
VPN+Ping: Request timeout, request timeout, request timeout.

CWH: Try traceroute?
VPN+Traceroute: 14 hops, no joy.

CWH: Your VPN settings must be wrong. Here are instructions to use Windows PC VPN correctly.
Us: Thanks but no.

CWH: Your MX records are configured incorrectly.
Us: No, they are correct per Google guidance. We sent an email beginning “Please believe us.”

CWH: It must be DNSSEC. Check to see if your registrar implements DNSSEC.
Us: We are using your DNS servers.

CWH: Perhaps your registrar is broadcasting an old record?
Us: Our registrar doesn’t do DNSSEC.

At this point we consulted a friend who’s an expert on DNS and Email and even DNSSEC. He verified that not only could you not ping Textuality from Germany, you also couldn’t ping CWH or its name servers. Firewall firewall firewall!

CWH: “I did test the site access using a 3rd party application, and it seems to be accessible on all parts.”
Us: Look at the output, it shows we can’t be reached from anywhere in Germany.

Also, for all the remaining messages in the email trail, we prefixed our input with bold face extra-large text reading: Systems located in Germany cannot ping Textuality.com’s IP address, nor can they ping the IP addresses of textuality.com’s designated name servers. This is the problem.

CWH: Let’s try migrating you to a different server; try pinging these hostnames.
VPN+Ping: Nope.

CWH: Are you sure it’s not your VPN settings?
Us: Are you sure it’s not your GDPR settings?
CWH: Raising your issue to Tier 3.

20 hours pass, then we get email from:

Nash Burns!

…who said “This has been fixed.” It was. Nash’s email signature was “Nash(Rajaneesh) B”. What a great name, though. Thanks, Nash.

Am we mad?

Not really. Consumer-facing tech support is hard. None of their suggestions were unreasonable. Doing GDPR correctly is hard. They’ve been just fine for years and were having a bad week. Could we expect better from any of CWH’s local competitors? Probably not.

It wasn’t funny at the time, but looking back, it kind of is.

I love making incremental improvements to my website. All the changes I make to this website build up to what you see. This has me thinking that websites are both a place to reflect on, discuss, and make change, as well as being something that can, and does, change over and with time. My website grows with me.

While exploring my website, I noticed in the past that the bold typeface in the headings and in my website name looked a bit different in Safari to Firefox. This week, I learned why: I didn’t supply a bold typeface for my website. This meant that both browsers were trying to create a bold effect rather than relying on the typeface itself to supply bold characters. This has now been fixed. My site, which uses the Standard web font, now loads the bold version of the web font too.

Today I also set out to fix how links appear in italics in my blog posts. Links are styled in blue with an underline, but the colour rules for the em tag were overriding the colour of links within the em tag. This meant that links in em tags preserved their underline, but had the same colour as the surrounding text. This, too, is now fixed. It felt good to finally make this change. Small changes collectively make a big difference.

I also have a new “Make a Website” page. I wrote this page to be a short introduction to how to make a website, referring to the excellent resources others have made on the topic, as well as communities of people building websites. I now link to this page both on my home page and my website sidebar. If you have been looking for a sign to start a website, this is it. The web is wonderful.

On a side note, I learned that Ghost, which I use for publishing blog posts – my static site generator reads posts from Ghost, stored as text files – does not allow emojis in permalinks. I learned this while trying to set the permalink for 🌸 to be the eponymous emoji. This is probably for the best: emojis in permalinks do not, on reflection, necessarily fit into how I think about URL design:

In a sense, URLs are user experience. I use them to navigate through websites. As a site creator, clearly defining URLs helps me know what is where. This is important to me. I want the experience of searching for a page – either for reference, or as I develop my site – to be as intuitive as possible.

Finally, I created a new “for you” page. It reads:

This entire website is for both me and you.

Thank you for visiting!

I much prefer my for you page to any one I have seen so far.

Related is what Sir. Tim Berners-Lee says of the web: “This is for everyone”.

Note: My site styles may be cached for you, so to see any changes to the typeface you may need to do a hard refresh of a page. One day I will figure out how to clear the styles that power my offline mode from readers' caches when I update the styles. That, however, is a task for another day.

At Front End Study Hall yesterday there was a discussion about what endeavours are similar to web development. There was a particularly rich discussion (documented in the afore-linked notes) related to gardening and web development. My takeaway from the discussion was that building for the web has more in common with other tasks than I had thought about before.

I have been thinking about one-off pages on my website that I use to document different ideas, like my ideas list or my patterns list. I keep thinking about how I should present these. Should I have a page that lists all of the pages? But what if a page isn’t ready yet? The benefit of the current way I share these pages – either directly with friends or, more commonly, by linking to them in a blog post when they are relevant – seems to work well. With the current system, I share when I am ready.

I sometimes think of these one-off pages as “wiki-like pages”, in the sense that they are updated over time – they grow. I don’t consider these pages a digital garden because they aren’t heavily linked. Many of my one-off pages stem from some notes I have taken in Apple Notes that I think, after reaching some point of maturity, should have a URL. You could call them “slash pages”, but I am not a fan of that term.

The reason I think about all these words is that they have a certain weight to them. A wiki implies something different than a digital garden, just as a page implies something different to a blog post. While “wiki-like pages” made sense to me for one-off, growing pages, “page” may be the best way for me to think of these for now.

When I consider how I want to share these pages, the best system is the one I have right now – the one where I link to pages in a blog post every so often, when I am ready. The one where I can put a URL on something without the pressure of it showing up on a list of all the pages I garden. My system is a bit inefficient, but it is maybe good enough? It is good enough for now, at least.

On reflection, there is something joyful about being able to casually share a new page in a blog post, where the page is most appropriate. The one-off pages I garden aren’t a notebook so much as they are an amalgamation of bullet points, a potential starting point – a place with more information. In blogs, I refine and define and synthesise and reflect. In pages, I often want to get the notes down so they have a home. So that I can build on the idea later.

Indeed, building on things feels very much in the spirit of having a website. We’re always building on what we have. I garden where I can. As Jeremy said in the aforementioned Front End Study Hall discussion about gardening and web development: “the joy of the thing is in the development - you cannot plan for it.”

In the spirit of talking about one-off pages, this may be a fun time to share I have a page on this website that lists songs that are related to rhubarb pie. If you have any suggestions that I can add to the list, please do let me know!

This is my (late) contribution to the January 2026 Grizzly Gazette Carnival on the topic “How I ___”, where contributors are invited to fill in the blank. I saw the Carnival a few days ago and, after some thinking, the idea “How I find links” came to mind.

Whenever I am on a video call, I love helping to find links. If someone shares a document, I will ask for them to share the link so everyone on the call has access to the same resource. If someone mentions a document but doesn’t have the URL to hand, I will try my best to find the link and share it in the meeting notes or chat channel as soon as I can. I proactively find links because having relevant link fast means that the discussion can keep going without someone – often the speaker – stopping to find the link.

There are a few ways I find links. One of the most valuable tools is the Firefox address bar, which can read my browser history. If I know the link I am looking for, I will type in as many words as I think I need to find the link via the address bar autosuggest feature. With the right query, and provided I have opened the link, I will be able to find it. The utility of the address bar is in part aided by my love of opening and skimming links shared in discussions I am in.

The more links I have seen, the more likely I am to be able to find the one that is relevant to the discussion, especially using the address bar browser history search feature. I love skimming information both to take it in and create a mental bookmark of where specific piece of information may be.

If someone references an asynchronous discussion in a call and wants to share it – for example, a Slack thread – I will try to find the relevant link to the thread and share it with everyone. Sharing a direct link to the discussion means everyone is on the same page without having to tag someone in a thread (tagging may not always be appropriate, especially if a link is for reference only). Slack filters help immeasurably in finding a thread that mentions a piece of information. For example, in: and from: let you search within a channel and messages published by a specific author, respectively. In general, fast search tools with filters help me find links faster.

When I am looking for a thread, and in general, I try to remember whatever exact keyword will help me find the piece of information. Often, this is a word or two. My recall is aided if someone mentions a resource I have encountered recently.

My inspiration for this topic in part came from reading Thomas’ “20 Social Roles” blog post, which outlines various informal roles people have in digital social environments. The “Infovore” role resonates a lot with me:

The Infovore is someone who collects information and knowledge, which can be on a specific interest or domain, or out to things of potential interest. Quite often they have a system for recall or retrieval of this information / knowledge. The Infovore is often curious with broad and deep interests that wants to hold on to things they run across and have them within easy reach.

The Infovore is the person who people turn to and ask the question, starting with, “have you seen anything on…”.

My system for recall is usually my browser history or Slack (or the relevant chat). If a resource is one I have not yet encountered but think I can find (i.e. an MDN article on a web development topic), I will use Google. The inurl: filter is especially helpful when I am looking to narrow my search to something more specific. I occasionally use intitle: too, but I find inurl and a relevant keyword matches most of my searches.

I sometimes need help finding information. Indeed, finding information in a community or organisation is a social activity. Everyone has a different piece of the map. If I don’t know how to find something, I will try to refer someone to the person that does.

Context is important, too. I can usually help people in the same community or organisation find a link, but it would be harder for me to find a resource with little shared context.

I love helping people find things, and learning how to use information retrieval tools to help people find what they are looking for. My observations above are a brief summary of how I find links. It is hard to write down everything because my workflow varies. With that said, I thought I’d document some of my tips! TL;DR: knowing my tools, opening lots of links and skimming as much as I can, staying and on top of new information all help me find links for people who need them.

I’m curious: do you have any tools or workflows for finding links you have encountered? If you do, feel free to email me at readers [at] jamesg [dot] blog.