This is a followup to my introduction of BlogOnLemmy, a simple blog frontend. If you haven't seen it, no need because I will be explaining how it works and how you can run your own BlogOnLemmy for free.

Leveraging the Federation

Having a platform to connect your content to likeminded people is invaluable. The Fediverse achieves this in a platform agnostic way, so in theory it shouldn't matter which platform we use. But platform have different userbases that interact with posts in different ways. I've always preferred the forum variety, where communities form and discussion is encouraged.

My posts are shared as original content on Lemmy, and that's who it's meant for. Choosing for a traditional blog style to make a more palatable platform for a wider audience, and in this way also promoting Lemmy.

Constraints

Starting off I did not want the upkeep of another federated instance. Not every new thing that is deployed on the Fediverse needs to stand on its own or made from the ground up as an ActivityPub compatible service. But rather use existing infrastructure, already federated, already primed for interconnectivity. Taking it one step further is not a having a back-end at all, a 'dumb' website as it were. Posts are made, edited, and cross-posted on Lemmy.

The world of CSS and JavaScript on the other hand - how websites are styled and made feature-rich - is littered with libraries. Being treated like black boxes, often just a few functions are used with the rest clogging up our internet experience. Even jQuery, which is used by over 74% of all websites, is already 23kB in its smallest form. I'm not planning on having the smallest possible footprint*, but rather showing a modern web browser provides an underused toolset of natively supported functionality; something the first webdevs would have given their left kidney for.

Lastly, to improve maintainability and simplicity, one page is enough for a blog. Provided that its content can be altered dynamically.

*See optimization

How it's made

1. URL: Category/post

Even before the browser completely loads the page, we can take a look at the URL. With our constraints only two types of additions are available for us, the anchor and GET parameters. When an anchor, or '#', is present websites scroll to a specific place in a website after loading. We can hijack this behavior and use it to load predefined categories. Like '#blog' or '#linkdumps'. For posts, '#/post/3139396' looks nicer than '?post=3139396', but anchors are rarely search engine compatible. So I'm extracting the GET parameter to load an individual post.

Running JavaScript before the page has done loading should be swift and easy, like coloring the filters or setting Dark/Light mode, so it doesn't delay the site.

2. API -> Lemmy

A simple 'Fetch' is all that's required. Lemmy's API is extensive already, because it's used by different frontends and apps that make an individual’s experience unique. When selecting a category, we are requesting all the posts made by me in one or more lemmy communities. A post or permalink uses the same post_id as on the Lemmy instance. Pretty straight forward.

3. Markdown -> HTML

When we get a reply from the Lemmy instance, the posts are formatted in Markdown. Just as they are when you submit the post. But our browsers use HTML, a different markup language that is interpretable by our browsers. This is where the only code that's not written by me steps in, a Markdown to HTML layer called snarkdown. It's very efficient and probably the smallest footprint possible for what it is, around 1kB.

Optimization

When my blog was launched, I was using a Cloudflare proxy, for no-hassle https handling, caching and CDN. Within the EU, I'm aiming for sub-100ms* to be faster than the blink of an eye. With a free tier of Cloudflare we can expect a variance between 150 and 600ms at best, but intercontinental caching can take seconds.

Nginx and OpenLiteSpeed are regarded as the fastest webservers out there, I often use Apache for testing but for deployment I prefer Nginx's speed and reliability. I could sidetrack here and write another 1000 words about the optimization of static content and TLS handling in Nginx, but that's a story for another time.

* For the website, API calls are made asynchronously while the page is loaded and are not counted

Mythical 14kB, or less?

All data being transferred on the internet is split up into manageable chunks or frames. Their size or Maximum Transmission Unit, is defined by IEEE 802.3-2022 1.4.207 with a maximum of 1518 bytes*. They usually carry 1460 bytes of actual application data, or Maximum Segment Size.

Followed by most server operating systems, RFC 6928 proposes 10x MSS (= Congestion Window) for the first reply. In other words, the server 'tests' your network by sending 10 frames at once. If your device acknowledges each frame, the server knows to double the Congestion Window every subsequent reply until some are dropped. This is called TCP Slow Start, defined in RFC 5681.

10 frames of 1460 bytes contain 14.6kB of usable data. Or at least, it used to.
The modern web changed with the use of encryption. The Initial Congestion Window, in my use case, includes 2 TLS frames and from each frame it takes away an extra 29 bytes. Reducing our window to 11.4kB. If we manage our website to fit within this first Slow Start routine, we avoid an extra round trip in the TCP/IP-protocol. Speeding up the website as much as your latency to the server. Min-maxing TCP Traffic is the name of the game.

* Can vary with MTU settings of your network or interface, but around 1500 (+ 14 bytes for headers) is the widely accepted default

\
Visualizes two raw web requests, 10.7kB vs 13.3kB with TCP Slow Start\
- Above Blue: Request Starts\
- Between Green: TLS Handshake\
- Inside Red: Initial Congestion Window

Icons

Icons are tricky, because describing pixel positions takes up a considerable amount of data. Instead SVG's are commonplace, creating complex shapes programmatically, and significantly reducing its footprint. Feathericons is a FOSS icon library providing a beautiful SVG rendered solution for my navbar. For the favicon, or website icon, I coded it manually with the same font as the blog itself. But after different browsers took liberties rendering the font and spacing, I converted it to a path traced design. Describing each shape individually and making sure it's rendered the same consistently.

Regular vs. Inline vs Minified

If we sum up the filesizes we're looking at around 50kB of data. Luckily servers compress* our code, and are pretty good at it, leaving only 15kB to be transferred; just above our 11kB threshold. By making the code unreadable for humans using minifying scripts we can reduce the final size even more. Only... the files that make up this blog are split up. Common guidelines recommend doing so to prevent one big file clogging up load times. For us that means splitting up our precious 11kB in multiple round trips, the opposite of our goal. Inline code blocks to the rescue, with the added bonus of the entire site now being compressed into one file making the compression more efficient to end optimization at a neat 10.7kB.

* The Web uses Gzip. A more performant choice today is Brotli, which I compiled for use on my server

In Practice

All good in theory, now let's see the effect in practice. I've deployed the blog 4 times, and each version was measured for total download time from 20 requests. In the first graph we notice the impact of not staying inside the Initial Congestion Window, where only the second scenario is delayed by a second round trip when loading the first page.

Scenario 1. and 3. have separate files, and separate requests are made. Taking priority in displaying the website, or the first file, but neglecting potential useable space inside the init_cwnd. We can tell when comparing the second graph, it ends up almost doubling their respective total load times.

The final version is the only one transferring all the data in one round trip, and is the one deployed on the main site. With total download times as low as 51ms, around 150ms as a soft upper limit, and 85ms average in Europe. Unfortunately, that means worldwide tests show load times of 700ms, so I'll eventually implement a CDN.

1. Regular (14,46kB): no minification, separate files\
   - dev3.martijn.sh/
2. Inline (13,29kB): no minification, one file\
   - dev1.martijn.sh/
3. Regular Minified (10,98kB): but still using separate files\
   - dev2.martijn.sh/
4. Inline Minified (10,69kB): one page as small as possible\
   - martijn.sh/

I'll be leaving up dev versions until there's a significant update to the site

Content Delivery Network

Speeds like this can only be achieved when you're close to my server, which is in London. For my Eurobros that means blazing fast response times. For anyone else, cdn.martijn.sh points to Cloudflare's CDN and git.martijn.sh to GitHub's CDN. These services allow us to distribute our blog to servers across the globe, so requesting clients always choose the closest server available.

GitHub Pages

An easy and free way of serving a static webpage. Fork the BlogOnLemmy repository and name it 'GitHub-Username'.github.io. Your website is now available as username.github.io and even supports the use of custom domain names. Mine is served at git.martijn.sh.

While testing its load times worldwide, I got response times as low as 64ms with 250ms on the high end. Not surprisingly they deliver the page slightly faster globally than Cloudflare does, because they're optimizing for static content.

Extra features

• Taking over the Light or Dark mode of the users' device is a courtesy more than anything else. Adding to this, a selectable permanent setting. My way of highlighting the overuse of cookies and localStorage by giving the user the choice to store data of a website that is built from the ground up to not use any.
• A memorable and interactable canvas to give a personal touch to the about me section.
• Collapsed articles with a 'Read More'-Button.
• 'Load More'-Button loads the next 10 posts, so the page is as long as you want it to be

Webmentions

Essential for blogging in current year, Webmentions keep websites up-to-date when links to them are created or edited. Fortunately Lemmy has got us covered, when posts are made the first instance sends a Webmention to the hosters of any links that are mentioned in the post.

To stay within scope I'll be using webmention.io for now, which enables us to get notified when linked somewhere else by adding just a single line of HTML to our code.

Notes

• Enabling HTTP2 or 3 did not speed up load times, in fact with protocol negotiations and TLS they added one more packet to the Initial Congestion Window.
• For now, the apex domain will be pointing directly to my server, but more testing is required in choosing a CDN.
• Editing this site for personal use requires knowledge of HTML and JS for now, but I might create a script to individualize blogs easier.

Edit: GitHub | ./Martijn.sh > Blog

I’m making an initial version of places.pub available today. places.pub is a collection of Place objects suitable for use in geosocial applications on the ActivityPub network.

Part of my work in the Social Web Community Group at the W3C has been participation in the GeoSocial Task Force. This is a sub-group of the SocialCG that focuses on implementing user stories in ActivityPub related to the intersection of geographical systems and social networking, for example, tagging an image with the place it represents, or checking in to a location.

One important need for geosocial software is that all objects in ActivityPub, including Place objects, need to have a permanent URL as their id property, which shares the description of that object in Activity Streams 2.0 format. However, there isn’t a good dataset of geographical objects — countries, states or provinces or regions, cities, buildings, businesses, parks, streets — available in AS2 on the Web right now. That is slowing down experimentation in the Geosocial Task Force.

Using the service

So, I worked on making places.pub for geosocial hackers to experiment with. It’s a service that exposes places from the amazing OpenStreetMap collection of data as AS2 objects on the Web. So, given an OpenStreetMap object like the Rogers Centre Ottawa, it provides an AS2 version suitable for use in geosocial activities in ActivityPub. It also has a rudimentary search mechanism, although I think most users will want to use the Nominatim service for searching the OpenStreetMap database, and then map the IDs onto places.pub.

Once you know the places.pub ID for a place, you can use it for geotagging objects, people, activities, or using special geosocial activity types like check in, check out, and travel. There is a good list of examples on the places.pub home page, but obviously this is not an exhaustive list!

How it is built

This wasn’t my first time trying to build places.pub; I’d done two earlier versions with different architectures and the same interface. The first time out, about 7 years ago, I created a full NodeJS server that used a full mirror of the OpenStreetMap database, so I didn’t need to hit the OSM API to fetch data. It worked pretty well, but it was really expensive — hundreds of dollars per month to keep a database server of that size running and synched.

I tried a second version a few months ago, which did batch generation of AS2 Place objects from the OpenStreetMap exports, and then uploaded them to the S3 service at Amazon Web Services. This was a whole lot cheaper, but it took a long time to download, convert, and re-upload the data.

This third implementation, with source code available on GitHub, is a little bit easier than both. Instead of sloshing the huge OSM dataset back and forth, I used the version of the data stored in the Google Cloud Public Datasets system on BigQuery. This let me ignore the effort of moving data, and just focus on giving it a good ActivityPub-compatible interface using a Google Cloud Run function. It seems to work pretty nicely.

Next steps

I’d love to see some experimentation with using places.pub for geosocial activity in the social web. I’m going to work on some implementations in my own ActivityPub software. If you find problems with the software, please add an issue on GitHub or let me know on the Fediverse at @evanprodromou.

Die Liebste hat nächste Woche ein Seminar und mir deshalb gerade den Link zur Webseite des Veranstaltungsortes geschickt. Da habe ich dann drauf geklickt und war gelinde gesagt sehr erstaunt.

Es geht um die Webseite von Westhouse Augsburg. Nach dem ersten Klicken kommt die übliche Cookie-Abfraqge und da ich vom Team „Datensparsamkeit“ bin habe ich also alle Cookies bis auf die angeblich absolut notwendigen Cookies abgelehnt.

Danach kommt man auf die Startseite und die hat das Ambiente eines teuer gestalteten Hochglanzprospektes. Ich möchte mich aber gar nicht vom Glamour beeindrucken lassen, sondern will eigentlich nur wissen, wo wir hin müssen wenn meine Frau die Veranstaltung besuchen will. Auf der Startseite findet sich dazu erst mal kein Hinweis, doch dafür fällt mein Blick auf einen seltsamen „Kasten“ am rechten Fensterrand. Und da steht dann:

Sie sehen gerade einen Platzhalterinhalt von TrustIndex. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Ja super. Warum glaubt ihr habe ich die Cookies abgelehnt? Damit ich mich jetzt mit Platzhaltern beschäftigen will…?

Nein ich suche immer noch die Adresse. Ganz oben gibt es in der Mitte das beliebte Hamburger-Menü und da gibtt es einen Punkt „Anfahrt“. Das sollte doch hoffentlich die Frage berantworten.

Doch weit gefehlt, es gibt wieder keine Adresse. Allerdings sehe ich die Beschreibung wie man mit dem Auto hin kommt und kann vermuten, wo das hier ist. Und statt einer Karte sehe ich folgenden „Platzhalter“:
Keine Kekse, keine Karten….
Na, da bin ich jetzt aber mal neugierig und klicke auf „Weitere Informationen“. Und da erscheint dann:
Der große Unbekannte….
Tja, und nun? Da fällt mir ein, dass wir ja von Rechts wegen nicht nur diese fürchterlichen Cookie-Dialoge haben sondern auch eine Impressumspflicht. Das Impressum ist am unteren Seitenrand verlinkt und siehe da, dort finde ich endlich Straße und Hausnummer des Veranstaltungsortes.

Bei solchen Webseiten wünsche ich mir manchmal schon das Web-Design der 90er zurück. Der Browser sagt, die Seite belegt gerade 175 MB Speicher. Für eine lausige Webseite…

I was on a panel on “AI” yesterday (was in German so I don’t link it i this post, specifics don’t matter too much) and a phrase came up that stuck with me on my way home (riding a bike is just the best thing for thinking). That phrase was

AI systems are just tools and we need to learn how to use them productively.

And – spoiler alert – I do not think that is true for most of the “AI” systems we see sold these days.

When you ask people to define what a “tool” is they might say something like “a tool is an object that enables or enhances your ability to solve a specific problem”. We think of tools as something augmenting our ability to do stuff. Now that isn’t false, but I think it hides or ignores some of the aspects that make a tool an actual tool. Let me give you an example.

I grew up in a rural area in the north of Germany. Which means there really wasn’t a lot to to TBH. This lead to me being able to open a beer bottle with a huge number of objects: Another bottle, a folding ruler, cutlery, a hammer, a piece of wood, etc. But is the piece of wood a tool or is it more of a makeshift kind of thing that I use tool-like?

Because an actual tool is designed for a certain way of solving a set of problems. Tools materialize not just intent but also knowledge and opinion on how to solve a specific problem, ideas about the people using the tools and their abilities as well as a model of the problem itself and the objects related to it. In that regard you can read a tool like a text.

A screwdriver for example assumes many things: For example about the structural integrity of the things you want to connect to each other and whether you are allowed to create an alteration to the object that will never go away (the hole that the screw creates). It also assumes that you have hands to grab the screwdriver and the strength to create the necessary torque.

I think there is a difference between fully formed tools (like a screwdriver or a program or whatever) and objects that get tool-like usage in a specific case. Sometimes these objects are still proto-tools, tools on their way of solidifying, experiments that try o settle on a model and a solution of the problem. Think a screwdriver where the handle is too narrow so you can’t grab it properly. Other objects are “makeshifts”, objects that could sometimes be used for something but that usage is not intended, not obvious. That’s me using a folding ruler to open a beer bottle (or another drink with a similar cap, but I learned it with beer).

Tools are not just “things you can use in a way”, they are objects that have been designed with great intent for a set of specific problems, objects that through their design make their intended usage obvious and clear (specialized tools might require you to have a set of domain knowledge to have that clarity). In a way tools are a way to transfer knowledge: Knowledge about the problem and the solutions are embedded in the tool through the design of it. Sure I could tell you that you can easily tighten a screw my applying the right torque to it, but that leaves you figuring out how to get that done. The tool contains that. Tools also often explicitly exclude other solutions. They are opinionated (more or less of course).

In the Python community there is a saying: “There should be one – and preferably only one – obvious way to do it.” This is what I mean. The better the tool, the clearer it’s guiding you towards a best practice solution. Which leads me to thinking about “AI”.

When I say “AI” here I am not talking about specialized machine learning models that are intended for a very specific case. Think a visual model that only detects faces in a video feed. I am thinking about “AI” as it is pushed into the market by OpenAI, Anthropic etc.: “AI” is this one solution to everything (eventually).

And here the tool idea falls apart: ChatGPT isn’t designed for anything. Or as Stephen Farrugia argues in this video: AI is presented as a Swiss army knife, “as something tech loves to compare its products to, is something that might be useful in some situations.“

This is not a tool. This is not a well-designed artifact that tries to communicate you clear solutions to your actual problems and how to implement them. It’s a playground, a junk shop where you might eventually find something interesting. It’s way less a way to solve problems that a way to keep busy feeling like you are working on a problem while doing something else.

Again, there are neural networks and models that clearly fit into my definition of a tool. But here we are at the distinction of machine learning an “AI” again: Machine learning is written in Python, AI is written in LinkedIn posts and Powerpoint presentations.

Tool making is a social activity. Tools often do not emerge fully formed but go through iterations withing a community, take their final shape through the use by a community of practitioners and their feedback. All tools we use today are deeply social, historical objects that have embedded the knowledge and experiences of hundreds or thousands of people in order to create “progress”, to formalize certain solutions so we can spend our brain capacity on figuring out the next thing or to just create something beautiful or fun. Our predecessors have suffered through proto-tools and all the hurt that comes from using them so we wouldn’t have to. And this social, temporal context is all part of a tool.

And the big “AI” systems that supposedly are “just tools” now do not have any of that. They are a new thing but for most problems they hope that you find ways of using them. They do in a way take away hundreds of years of social learning and experience and leave you alone in front of an empty prompt field.

So no, I do not think that the “AI” systems that big tech wants us to use (and rent from them) are tools. They are makeshifts at best.

Liked it? Take a second to support tante on Patreon!

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.