Kirsle.net
I blog about anything I find interesting, and since I have a lot of varied interests, my blog entries are kind of all over the place. You can browse my tags to sort them by topic and see which ones I frequently write about, or the archive has a complete history of my posts, dating back to 2008!
Besides my blog, I have pages for my creative projects, which are linked to on the navigation bar.
I write a lot about Linux and Android, Minecraft, and I like to rant about stuff. Generally anything that makes me curious. Also check out my Bookmarks for all sorts of cool websites about various topics I'm interested in.
For the geeks: this website respects your privacy and doesn't run any third party ads or analytics. This site speaks HTTP and doesn't require any JavaScript to work.
Asahi Linux with LUKS EncryptionIn 2024, after I accidentally spilled a whole cup of coffee over my old Dell XPS laptop, I was suddenly in the market for a new computer and I picked up a 13" Apple Macbook Air M3. It was my first Apple computer in a very long time (before that I had an old Intel Macbook Air from ca. 2013), and having a macOS computer enabled me to finally debug and fix WebRTC errors in my chat room, but I was also greatly looking forward to Asahi Linux adding support for Apple Silicon M3 computers so that I could eventually install Linux onto this device some day.
At the time, Asahi Linux had support for M1 and M2 Apple Silicon devices so I thought it'd be maybe a year or so until M3 was supported. It took a little while longer than that, but as of this month they have released M3 support and I went ahead and installed it. It was quite easy to set up with their automated installation script.
There seem to be just a couple of issues they are still working out, which they mention in that blog post but briefly they are:
The most pressing matter for me, though, is that the Asahi Linux installer (still) doesn't provide an option for full-disk encryption with LUKS. I consider disk encryption to be an absolute must-have especially for small, portable, easily stolen devices such as a laptop. This poor guy on Hacker News learned this the hard way when his Macbook Pro running Asahi Linux was stolen, and without the disk encryption, the thief got his files and decided to blackmail him for profit.
While they have an open feature request to add LUKS setup to the installer, in the meantime it is possible to encrypt Asahi Linux separately, if a little involved.
Here is what worked for me in Sept. 2026.
In recent years, some new insights and research about the brain and mind have been making their way around the Internet and words like "aphantasia" have started being discussed on social media and elsewhere.
Apparently, not every human mind is the same in the way that we experience our inner worlds, and people from both ends of these spectrums have been surprised in recent years to learn that other people can have totally opposite experiences, and yet we all think our own minds are "normal" and we all coexist and function in the world regardless.
So, I thought I would write a blog post and document how my inner world is, to add my own data points to the discussion. For science.
Specifically I want to talk about the following aspects of the mind:
About a decade ago, I wrote a blog post titled "SmarterChild and Other AIM Bots" where I talked about some nostalgic memories from my early days with software development when I programmed my own chatbots that ran on AOL Instant Messenger.
I said on that post that I would follow it with a blog about MSN Messenger chatbots, but I never ended up getting around to doing so! So let me get into that finally, a decade later, with this blog.
In 2026, it is possible to get back online with MSN Messenger and sign them in to new servers hosted by Escargot.chat, so I have recently been playing around with MSN as well as AOL Instant Messenger in recent days -- AIM is also back with new, open source online servers that can revive the old messenger apps (and chatbots!) and give this old software something new to do in the modern era.
👉🏻 See Also:
I have recently posted a video on YouTube where I get my old Perl chatbots that I last touched in 2004 back online again connected to modern MSN and AIM chat servers, so check this out as well!
Without further ado, let's get into some of the weird & interesting quirks of MSN Messenger that was revealed when we popped open the hood of the MSNP protocol to develop our chatbots back in the day!
These silly random holidays always have a way of sneaking up on me when I least expect it, and today (July 14) is apparently National Nude Day!
I don't widely publicize it, on this blog especially, but one of the 'two main pillars' of my life (in terms of how much time I spent invested in it, and the things I am the most well-known for in some circles online) -- besides for example my interest in chatbots and my RiveScript chatbot scripting language -- is that I am a nudist.
Don't worry: I won't be linking to any of my nude socials from this site, though I do the opposite quite regularly. My friends in the nudist world have the privilege to see a much fuller and more authentic version of me (mind, body and soul), and I do frequently link to my personal websites like Kirsle.net from over there, even with my real full name attached to these pages!
Despite being a social introvert, I am not shy about my nudism and in fact I found the lifestyle to be extremely beneficial towards building up my self-confidence and tearing down my anxieties. Back when I was a teenager, I was so self-conscious and reserved and anxious for days to even exist in the world, and I owe a ton of my progress towards self-acceptance to my experiences with the online nude communities.
Speaking of shyness (or lack of), one of my most successful side projects in recent years is a social networking site I built for nudists & exhibitionists called nonshy. I launched it back in August of 2022, and without even doing much to advertise it, the community grew purely by word of mouth to over 12,000 members now. After I was laid off from my day job in Big Tech early this year, I established a business of my own in order to monetize nonshy and that has been going very well! I wrote my story about this project recently, in "high level" and generic terms, on my previous blog post if you'd like to read more about that!
Let me know if you'd like to hear more about this from me! I could talk more about it (again, in 'high level' and 'safe for work' terms here on my blog), about my experiences with anxiety and how everybody important in my life came to find out about this at varying points in time (and about how nobody actually really cares at all about it -- even when I've had co-workers stumble upon these profiles of mine online!) I write a lot about personal topics like this as well on my other blog, which I don't mind sharing a link to if you ask me in private!
In the tech industry, a "Full Stack Software Engineer" is somebody who is single-handedly capable of writing all of the source code needed for an application (especially in the context of web applications). That is, they are able to develop both the 'Back End' code (the part that runs on the server side, which handles your business logic, databases, authentication & security, API, etc.) as well as the 'Front End' code (the user interface that your customers will see: like a website's layout, design and controls).
Some Full Stack Engineers also know about the DevOps or deployment side of things: how you actually take all that source code and deploy it to your production web servers, and make it scalable for thousands (or millions) of concurrent users and keep it all running smoothly and securely.
In my 18-years long career in professional software engineering, I had always been a Full Stack Engineer. I may have only began my professional career in 2008, at twenty years old, but I had already been writing software for much longer ago than that! Back when I was just a teenager in high school, I already had developed and released several open source projects and I had a handful of production websites already under my belt, including one time a full MySpace clone I had programmed when I was 16. So, by the time I entered the workforce, I already knew how to fully write & ship a production application all on my own: the back-end, the front-end, and the deployment to production -- the complete lifecycle.
In 2026, I took things a step further and successfully launched my own company to monetize one of my most successful side projects, taking my "Full Stack Engineer" title and expanding it to "Full Stack Entrepreneur!"
That is: I had single handedly built a whole entire product, all by myself, from scratch -- and I didn't even use A.I. to help me build it!
In this blog post, I link to a Live Demo Website where I can show off what I built and you can play around and explore it, as well as an Open Source version of my product so you can see some of my code. And then I will tell my story about how this project became successful enough to launch my own profitable company around it!
I've been a software engineer for basically my whole life, at least ever since I first taught myself to write HTML code when I was 12 years old, and in the modern era when Artificial Intelligence and Large Language Models are commonplace, I of course have adapted with the times, as I had done before whenever a new paradigm shift in the engineering landscape had come about.
In this modern era of A.I. vibe coded apps that get built and deployed while full of bugs and security holes, which then get trivially hacked in short order and the company's data all leaked online, I thought I'd write a little about how I, a career software engineer since 2008, approach the use of A.I. in my projects.
If you happen to be a junior developer just getting started in this space and relying heavily on A.I. to do most of your job, maybe reading about my approach to A.I. could be helpful to inspire you on a different way of doing it, and help you grow as a self-sufficient developer who uses A.I. only as a tool to automate the tedious parts but without it being a crutch that you rely on too heavily that you couldn't survive without it.
I taught myself everything I know about software development, and since 2008 I have been working professionally as a "full stack" software engineer.
In 2008 I was building web apps using Perl and old-school JavaScript (jQuery), and as my career progressed, I learned many other languages and frameworks, from Python to Go, Angular to Vue.js, I have used Amazon AWS and Google Cloud Platform, and outside of my day job I have always had many side projects and apps I built myself, and deployed them on my own servers and managed the complete end-to-end process all on my own.
Even while I was still in high school, I had written and launched many websites, custom blogs and forums, and even a MySpace clone, so by the time I was ready to enter the workforce at 20 years old, I already knew the full stack: back-end, front-end, deployment and systems administration.
All of that is to set the context of where I was coming from before A.I. came about.
For my personal taste, I have never wanted to have A.I. built directly into my code editor.
When GitHub Co-pilot came out and your code editor had A.I. built directly into it, I never touched that myself.
The only time that I had A.I. in my editor was when I was working at Meta from 2023-26. At Meta, they have a custom build of VS Code with a ton of proprietary plugins and integrations, and there was an A.I. built in, and it would've been more trouble to remove the A.I. than to just let it be.
I can see the appeal of it: at Meta I was building an internal app to manage licensed music and I was creating a data schema to store it, with fields like Title, Artist and Album. As I got started writing the first couple of fields, the A.I. automatically picked up what I was laying down and it suggested fields like ISRC, UPC, Copyright, Duration, Genre, and so on which were all fields I wanted to add and it was fun to be able to just hit "tab-tab-tab" and accept all the suggestions.
But again, for my personal taste I do not like having an A.I. in my editor. I don't want it inspecting my entire project's source code, I don't trust it to make large-scale refactors for me, I prefer to keep my separation of concerns and have A.I. over there and my code over here without the two directly inter-mingling.
The way that I utilize A.I. is to chat with it separately in my web browser, or more recently, locally on my PC using LM Studio.
One of the first things I found A.I. to be super helpful for was database queries. When I have a complicated question to ask of my database, I can open a chat session with an A.I. and tell it what I want to do, and briefly describe my tables and their relevant columns, and it gives me a custom tailored solution made specially for my exact use case.
For example, on a social networking site I built as a side project, I wanted to pull some high-level demographics data about my users, counting them by age ranges and genders, and also mix in some high-level statistics about the content that those users generated on the site. And I wanted all of this to be done using a single database query. There were many tables involved and many different questions being asked of my database at once, but I knew it was more efficient to let the database do this work rather than have my web app gather it the slow way by making many separate queries.
Before A.I., I would have had to search Google and land on StackOverflow pages where others before me were asking to solve similar problems. I would have to first read and understand the StackOverflow question, to judge if their database looked anything similar to mine, and then read through the many answers, some of which posed much more complex solutions than the others. Now, with A.I. I can just tell it what I want out of my database and what my tables look like and it tells me exactly how to do it.
The A.I. doesn't need to understand my entire codebase for this. When I was learning Rust recently, when my code wouldn't compile and my usual trial-and-error to satisfy the borrow checker wasn't working, I would open a chat with Gemini and tell it just enough context so it can help me sort out the problem. I'd paste my struct and trait definitions, and the function or piece of code where the error occurred, and it would teach me about why Rust was unhappy and how to fix my code.
And that brings me to the next point...
When A.I. does give me some code back, I don't simply copy and paste it into my project and call it a day. I study the code to learn from it, and I rewrite it in my own style. Since A.I. doesn't have my entire codebase for context, it doesn't know how I usually name my variables or how I like to write my code, but that isn't important.
I treat A.I. the way that I used to treat senior software developers back when I was learning how to code. I work with them collaboratively, in a chat context, to learn from them and not rely on the A.I. as a crutch.
After I had ChatGPT help me with some of those gnarly database queries I mentioned above, I started to learn what the general structure is, how I could compose multiple 'subqueries' or 'Common Table Expressions' and in the future I was able to write my own queries without asking the A.I. again for help.
A part of how I approach A.I. today actually began years back when the iPhone was first launched (ca. 2009).
Back then, I was living in Los Angeles and my friends had the iPhone and Google Maps for navigation.
One day, one of my friends had lost or broken their phone, and they were driving us somewhere and they had no idea how to get there and had to ask one of us to help navigate for them. This friend was born and raised in Los Angeles, it was their hometown, but they had already come to depend too heavily on GPS navigators to the point where they were utterly useless at navigating anywhere without it. And we weren't even driving anywhere crazy, we mainly all hung out on the west side (Culver City/Santa Monica), on streets that should be well-known to all locals.
I took it as an early warning that I would not let myself depend too heavily on GPS and let my mental maps in my head atrophy.
Whenever I am driving to a new location for the first time, for sure, I will use a GPS navigator to get there. If it's a one-off or rare trip, that's OK.
When I am driving to somewhere for the second, third or forth time -- if it's an important place like a new friend's house, for example -- I challenge myself to learn the route to get there. I may use GPS the first couple of times, especially if there are many different intersections and turns to make, but if I am still using GPS to get there after that, I consider it to be a personal failure.
And this is how I approach A.I. today. A.I. can be a very good teacher and it can give me custom tailored solutions to my problems, but I use it first and foremost to learn, I treat it like a knowledgeable friend who can teach me things and make me a stronger developer.
But if A.I. were to suddenly disappear tomorrow, I would still be a self-sufficient developer who can architect a full app end-to-end, and I would be a little smarter having had the help of A.I., but I don't rely on it as a crutch; I could really take it or leave it.
I have only sometimes asked an A.I. to fully create an app for me from scratch, the so called "vibe coding" way.
I don't have A.I. built into my editor, though, so it was a chat session from which I copied the code out and the A.I. helped get me started on my project.
I wouldn't blindly trust a fully A.I. generated app, though -- A.I. makes mistakes, and many startup companies had found out the hard way when they vibe coded a social media app which had no security at all and hackers then trivially leak all their customer data from unsecured data stores that had no credentials set at all. A.I. is good at giving you something that "basically works" and does what you said, but A.I. often doesn't care at all about security or doing anything the right way.
The kinds of projects I had vibe coded were for small personal things, things that I thought would be mildly cool to have but that I wouldn't want to sit down and make a whole big thing out of. For example, a personal app to help me cross-post to multiple social media apps like Bluesky and Mastodon at once. To build something like that myself, I'd have to sit down, write all the tedious boilerplate that any web app needs, read through the API docs of each platform, develop and debug and test it all the hard way, it might take me a week. Or I can ask A.I. to get me started with a full single page app which already "basically works" and has the correct API calls and everything, and then take it from there and review the code, polish it up, fix the inevitable bugs.
But I'm not deploying an app like that to production, especially if it's a much more involved app having a back-end and many more source files than a self-contained single page app would.
In summary, A.I. is useful as a learning tool and I think the best use case for it is to help grow your own knowledge. Treat it like your own personal tutor. When it helps you with your project, don't just copy and paste it and call it a day, but study the code, ask questions about it, use it as a learning exercise to help strengthen your own brain and grow as a person.
A.I. has massively improved my workflow and made me a faster developer, even while I keep A.I. in its own chat window and talk to it out-of-band from my project. I have always been a "fast coder" and, because I write my code from scratch, I am automatically mindful about what I'm doing and the security implications of my code.
A.I. can save me hours of time when it comes to the tedious things, like integrating a third-party API or giving me a skeleton template for a complex feature to build on top of, but I'm not relying on A.I. to the extent that I deploy a buggy and broken project for it or to where I would be lost without it in case A.I. were ever taken away from me.
In recent months as the true costs of A.I. are beginning to show, a lot of hosted A.I. services are going behind steep paywalls, and they're holding all of the junior developers hostage -- developers who got started in their career by using A.I. and they rely on it too heavily, in the same way that my friends in Los Angeles rely so much on their GPS navigators.
Like everything else, A.I. is a tool and it can be used in good ways or bad ways. Hanging your entire career on using A.I. in the wrong way, to the point that you become "locked in" when the A.I. companies enshittify their products (in the same way that Uber, AirBnb, etc. have gone), and having no choice but to pay them any amount of money they ask for, because you are so dependent on their product for your own livelihood, is not a good way to use A.I. in my very humble opinion.
Over the past couple of weeks, I decided I would get serious again about learning how to program in Rust and I have ported my chatbot scripting language, RiveScript over to Rust.
You can check it out on GitHub at https://github.com/aichaos/rivescript-rs
The Rust port is fully 'feature complete' to a similar extent that the JavaScript and Go ports are, including some optional features (kept in other Rust crates) that are similar to the extras that the JS and Go ports come with:
RiveScript is a scripting language for chatbots that I had invented in the early 2000's.
It can be used to program the classic sort of "canned responses" chatbot that was especially popular back then, where your chatbot needed to anticipate all of the questions a user could possibly ask up front and give a pre-programmed response back. It has nothing at all in common with modern LLMs such as ChatGPT, though, RiveScript could still be useful in 2026 when paired with an LLM, so that you can "hard-code" responses to important questions and guarantee that your chatbot answers them how you would like, before falling back to an LLM to handle everything else.
RiveScript itself is a lightweight library that just handles the chatbot scripting language, designed to be very easy for chatbot developers to integrate it into their custom programs. (For example, RiveScript doesn't come with LLM fallback support, but it's very easy to write a custom program of your own that could do that).
A simple example of its syntax looks like this:
+ hello bot
- Hello, human!
See its official website RiveScript.com for details!
The Rust port of RiveScript is interesting because RiveScript, when it first released in 2005 with the original Perl implementation, it used the file extension .rs to contain your chatbot's response data.
In 2013, a Rust language developer contacted me about changing my file extension because the upcoming Rust language used .rs for its source files, and RiveScript was causing some complications on GitHub and in code editors when it was being mistaken for Rust code.
So I had changed the official file extension to .rive but most of the RiveScript ports would read files with both .rs and .rive extensions (for backwards compatibility).
This is the first new official port of RiveScript I have written since 2015, so the Rust port will only consider .rive file extensions to be valid by default when loading your chatbot's brain.
The first proper programming language that I taught myself was Perl, and I taught myself to program specifically because I wanted to run these kind of chatbots on AOL Instant Messenger back in the day, and some Perl code to do so was the first thing I stumbled upon.
So, the initial version of RiveScript was written in Perl, as I used Perl for everything back then.
But, Perl was already starting to lose popularity even back then, and I wanted more people to be able to use RiveScript and make their own fun chatbots. So I personally ported RiveScript into several other programming languages: Java, JavaScript, Python and Go.
RiveScript.java was my first ever Java project, RiveScript.py was my first Python project, and the Go port was one of my first Go projects!
RiveScript made for a really useful library for learning the ropes with a new programming language, as a proper RiveScript port involves touching so many different features of a programming language: filesystem access, regular expressions, lists and hash maps, classes and interfaces.
I was given a very good tour of Rust during the development of this project!
The infamous Rust borrow checker was interesting as compared to the other programming languages.
For those who aren't familiar: Rust as a programming language doesn't have a 'garbage collector' to automatically reclaim memory when your variables go out of scope (the way that Python, JavaScript, Go, Perl, etc. all do), but also, unlike C or C++ which also have no garbage collector, in Rust you don't need to worry about freeing your own memory yourself either. In a C program, errors around freeing memory lead to all kinds of problems and vulnerabilities when it's done incorrectly: your program can either have a 'memory leak' if you fail to free your memory, or a security bug if you free memory incorrectly and then use it again later in your program.
Rust avoids all of those pitfalls of C with its borrow checker. You basically need to prove, at compile time, that all of your variables are being handled correctly: where were they declared, which function has access to them, which parts of the code are able to write to them? And when you have satisfied the compiler and your program actually builds, then you know confidently that it doesn't have memory leaks or memory-related vulnerabilities; Rust manages the lifetime and memory of your variables automatically, freeing their memory when it knows they are no longer reachable anywhere, and so on.
Coming from other programming languages like Go, where it's totally OK to pass a mutable pointer to my master RiveScript struct all over the place, in Rust I had to be a lot more deliberate about when the master RiveScript struct is mutable, who has access to it, what they can do with it, and so on.
This leads to a few interesting quirks that the Rust port of RiveScript has compared to the others:
In RiveScript (generally), there is a feature called 'Object Macros' where you can write custom program code to add dynamic behavior to your bot. For example, you can let a user ask "what is the weather like in Los Angeles?" and have the bot go and fetch that information from a weather API using a custom Object Macro function.
In all RiveScript ports, object macros are given two parameters: a pointer to the master RiveScript struct, and a string array of parameters given to the macro function.
The *RiveScript pointer is sent so that the function can get or set user variables or potentially mutate the inner state of your chatbot. In most programming languages, it's fine to pass mutable pointers around all willy nilly - the languages depend on the programmer to ensure any mutations are done safely (e.g., by protecting internal hash maps with a mutex). In Rust, you can not give a mutable pointer to multiple parts of your program at the same time.
So in the Rust port, object macro functions receive a 'Proxy' object instead: it exposes a subset of useful function calls from RiveScript that an object macro would commonly want to use, but it is not the literal same RiveScript struct that is running your chatbot. Reading user variables will pass through and read them from RiveScript, but setting user variables will have the Proxy keep a 'staged' HashMap of the pending changes. (If you set and then read the variable, you get back the recently updated 'staged' copy instead of the one from upstream).
After the object macro function returns, RiveScript takes the staged writes and commits them properly to storage.
As I was building and testing the Rust port, I came across a decades-old bug in RiveScript that affected the JavaScript, Python and Go ports!
In RiveScript, responses from your chatbot are grouped into "topics", where the default topic is named "random" and whenever a user is within a topic, the only triggers their messages may match are the ones written for that topic.
Here is a cheeky example of how topics could be used to 'punish' a user for using foul language with your chatbot:
+ [*] (list|of|bad|words|like|f bombs|goes|here) [*]
- Watch your mouth! I will make you apologize for using harsh language before we
^ can continue chatting any more. {topic=apology}
> topic apology
// While in this topic, only these triggers are available to match.
// The '*' trigger matches all possible messages when a more specific
// trigger failed to do so.
+ *
- Nope, apologize first before we can chat.
- Say you're sorry so we can move on.
- You offended me earlier, apologize so we can chat properly again.
+ [*] (sorry|i apologize) [*]
- OK, I'll forgive you. Just don't let it happen again! {topic=random}
< topic
Anyway, in RiveScript it is possible for topics to "include" or "inherit" the triggers that belong to another topic.
> topic my_topic includes another_topic inherits a_third_topic
// ...
< topic
The intended behavior is:
* then the inherited topic's triggers would be unmatchable, since they're all a lower priority than the included topic.The default example RiveScript brain that ships with all ports comes with an RPG demo that implements a basic text-based role playing game, featuring multiple scenes or 'rooms' and it uses these topic inheritance features to have common 'base commands' that are available in all rooms of the game.
However, in most ports of RiveScript (in JavaScript, Go and Python for sure), the RPG demo gets stuck at a certain point because of a subtle nuance in how topic includes were handled.
I had created a minimal test case that demonstrated where the bug happens:
> topic global
+ help
- good luck
< topic
> topic mars includes global
+ breathe
- can not breathe
< topic
> topic puzzle inherits mars
+ north
- wrong
+ west
- wrong
< topic
> topic puzzle1 includes puzzle
+ west
- right!
< topic
When the user was in the puzzle1 topic and they typed "west", they ended up matching the "wrong" response from the > topic puzzle inherits mars topic, because puzzle1 includes puzzle and they had a duplicate trigger in both.
I was a bit confused to see this example was broken across 3 different ports of RiveScript. I thought: "surely, this demo did work at one time, back when I first added it!"
The original Perl port of RiveScript had the demo working correctly, which confirmed my suspicion.
The other ports of RiveScript had broken this example between 2012 and 2014, during the "v1.0" eras of the JavaScript and Python ports of RiveScript specifically.
In the original Perl implementation:
When triggers are sorted in memory, only their text contents were sorted and stored on an array.
The response data for those triggers were stored in a Hash Map, keyed by the trigger text and containing its responses.
When the user's message matched a trigger on the sorted list, its details were looked up in the hash map and handled from there.
However, this meant that 'duplicate' triggers would overwrite the key on the Hash Map. Sometimes, a 'duplicate' trigger is actually wanted, for example, if your chatbot has many "yes or no" questions that it could ask of the user, you may have many triggers to capture the user saying 'yes' but each trigger is linked to a different %Previous response from the bot.
In the Perl port, duplicate triggers with %Previous don't function correctly because of the Hash Map.
In the JavaScript and Python ports, I had (at some point between 2012-14) refactored the bot so instead of the Hash Map it would keep an array of all triggers with their responses, so duplicates were allowed and the %Previous case worked as expected, but it introduced the bug with topic includes/inherits.
The Go port (which was written the most recently) took inspiration from these ones and inherited the bug as well.
Now, the RPG Demo RiveScript code itself could have been rewritten to be more clear (using inheritance instead of includes to avoid the specific duplicate trigger), but given that the RPG Demo code existed for many years and it was once functional (still is for Perl, and once was for JavaScript and Python), I thought it best to actually fix RiveScript to make the demo work again.
So: when a topic 'includes' another and the two topics have an identical trigger, the first-party version belonging to the current topic will shadow the other one and take priority.
At the time of writing, the Rust port has this RPG Demo example working correctly, making the Rust port now even slightly more correct than the JavaScript, Python or Go ports!
I may update the other ports soon to backport the fix for them as well.
The below is all speculative and I'm not sure it will happen, but here are some possible future plans for RiveScript.
Apart from bug fixes in the current ports, any major new development (if it happens) I will only be doing in the Rust port.
Let me explain.
While RiveScript made for a very useful project for me, for learning the ropes with a new programming language by porting over a native implementation of RiveScript, this became a double edged sword over time for RiveScript itself. The Python and JavaScript ports had proved especially popular, and they received feature requests and actual code contributions from the community on GitHub. But RiveScript had to be slow to evolve because I wanted all 5 ports to be more or less compatible in their functionality. I couldn't commit to adding a big new feature to RiveScript itself unless I was prepared to implement that feature 5 different times in 5 different programming languages.
Over the years I had sometimes thought about what a "RiveScript 3.0" might look like. The current RiveScript language has a few pain points, with its syntax and features on the edge case, that could be improved upon. But I no longer have the motivation to maintain 5 separate ports (now six separate ones, with Rust added) for such an ambitious project.
A couple of the brilliant features of Rust, though, are:
Just about every programming language is able to link with C programs, so the above means that a library can be written in Rust and then have bindings created for JavaScript, Python, Perl, Go and so on which all use the Rust library via the C shared object API.
This is significantly better than my hopes for the Go programming language were: in Go, you can similarly compiled a Go program as a C shared object, however, because Go has a garbage collector, your C shared object brings along the full Go runtime environment. While a third-party program can link to a Go object, it can only do so one time, as adding a second Go DLL will cause the Go runtime to be added again and it will conflict with itself and blow up in your face. That all is not a problem with Rust crates compiled as C shared objects.
So if I find it a worthwhile endeavour to overhaul RiveScript, this is how I would basically want it to work:
rivescript3 and that would be the Rust binding (separate from the rivescript 2 library that already natively exists in some languages, which would still be around).Anyway, in the modern world with LLM chatbots like ChatGPT, I'm not sure the demand is so great for a classic "canned responses" type of chatbot anymore.
During all my years working on RiveScript, I saw two different waves of interest come and go around these kind of chatbots: they were booming in the early 2000's with AOL Instant Messenger chatbots such as SmarterChild, then it dulled down for a while until around 2012 when Facebook Bot Platform came about and people could program chatbots for FB Messenger (and Google/Microsoft had their versions). This was the era when the JavaScript and Python ports were especially popular. That hype again simmered down, and now we have LLMs which blow RiveScript completely out of the water.
One could still pair RiveScript with an LLM to get the best of both worlds (deterministic responses to important questions before falling back on the LLM), and RiveScript already would fit that niche well enough, so it may not be urgently needed to improve the quality of life for the RiveScript language itself.
Anyway, that's about all the news I have about RiveScript lately! Check out the Rust port if curious and let me know how well it works!
Somebody had asked me about this recently, and I thought I must have already written a blog post about it before, but apparently I had not!
If you (or someone you know) has been curious about how to break in to software engineering as a career (or a career change), then this post is for you. A proper college degree is NOT even necessary for most software jobs!
The basic steps I will recommend are as follows:
Now I'll go into each of these in more detail.
For my career, I have mainly worked in the "web development" space so my recommendations here are coming from that world. See the footnotes for some advice for other software development paths (e.g. videogame development).
If you don't know any programming languages yet, you should choose a popular language to be your first one, and you should prefer to choose one which has a large amount of companies that use it because that's where the jobs are at.
My current recommendations would be:
If you aren't familiar with what front-end vs. back-end is, I can describe them briefly:
It's also possible to be a "full stack developer" where you are building both back-end and front-end code, but that usually requires you to learn multiple programming languages and technology stacks. For somebody just getting started, your time would be better served to pick the one you resonate with the most and focus your attention on learning the programming languages and frameworks for that language.
Note: after you've learned one language, it is much easier to learn your second one. There are so many things they all have in common: functions, variables, and control flow are very similar across them all.
There are tons of free tutorials online that teach you how to build web apps in any of these programming languages. Just google for something like, "Build a web blog in Python" or "Build a Twitter clone in JavaScript".
Those two projects (a web blog and a Twitter clone) are very common examples that you'll find a tutorial for in any programming language. "To Do" apps are another example. These kind of projects will have you learning many real world skills, such as databases and authentication cookies, that you would use at a real job.
Most such tutorials will not only help you learn the programming language itself, but also use a popular "web framework library" built for that language. Almost nobody is programming a raw HTTP server in Python, but they will use a web framework that provides the basic structure and shape of their app and then they fill in their custom business logic on top.
For some specific recommendations of very relevant frameworks that currently see widespread use in business:
In my career at Python shops, we've always used Flask to build our apps and Vue.js has been most commonly used on front-ends at multiple companies I've worked. React.js is very popular as well.
If you aren't disciplined enough to teach yourself how to code, and you don't want to dedicate two to four years of going to University, you can look for some "coding bootcamps" in your area too. Those bootcamps will typically go for several weeks and teach you everything you need to know about web development.
I've interviewed and worked with people whose sole educational experience was via these bootcamps and they did just great on the job.
A very good way to learn a programming language is to actually have a project that you want to build.
If you just go to a programming language's website and read through the tutorials there, they can be rather boring. They have you writing trivial little programs to learn how if/else expressions work, and silly things like that. After you have picked up the bare basics, I recommend jumping in and starting on a project of your own.
That's where the aforementioned "build a blog" style of tutorial will come in. Those will give you a good structure to follow, using real world frameworks and libraries that professional developers use at work.
It doesn't really matter much what you choose for your project. If you don't already have a website, programming a web blog is a good first option. Then, you'll have a website that you can post things on and document your journey of learning how to be a better programmer!
You could also build something like a videogame, or a chatbot, or a little web page that connects to various social media APIs and provides status updates from all your friends in one place. Something to scratch your own itch. It doesn't really matter a whole lot what your project is!
The important part, though, is that you open source your project and get a GitHub account and put your source code on it for others to see. (If you don't like GitHub, you can try GitLab instead).
The point is: having source code online will already make you stand out from the crowd when you begin applying at places to work. I have interviewed hundreds of developers over the course of my career, and most of them don't have a GitHub link or anything on their resume. Those who do are already putting themselves off to a good start with me.
After you have gotten a project or two under your belt and have learned the basics of how to build a website, you can start applying to companies for a web developer position.
There are always a ton of little startup companies or other small businesses who need anybody that can code. They don't even care if you have a college degree or not, and that is where having some source code up on GitHub can be helpful, so you can point to that as evidence that you know how to code.
The larger corporations will often say they want their candidates to have a Bachelor's degree in Computer Science or similar, but, once you've gotten your foot in the door at a small startup company and keep at it for about 5 or 10 years, you'll start getting recruiter e-mails from even Google, Meta and Amazon with them wanting you to apply to them. A few years of "real world" experience is typically a lot more important than some piece of paper from a university.
The above was basically how I did it, and I'll tell you how.
I taught myself how to program since I was a young teenager. I learned how to write web pages in HTML when I was 12 (using the very same W3 Schools HTML tutorial that I linked above!), JavaScript soon after, and when I was 14 I taught myself Perl so that I could program chatbots for AOL Instant Messenger.
Throughout my teen years, I had published many Perl modules online as open source software. Some were related to my chatbot projects, some of them were Perl/Tk GUI toolkit modules, some were very niche things such as Data::ChipsChallenge which could manipulate data files for the old Windows 3.1 game "Chip's Challenge".
I got my first proper job as a software developer purely because of my open source projects. I just pointed at my CPAN page as a place for recruiters to see my work.
For my second software development job (because I was still fairly green with only a few years' experience), the job interview consisted 100% of me going through the source code of RiveScript.pm, my chatbot project I had written in Perl, and explain how I designed my code and what I would do better if I rewrote it all again.
And: nobody ever asked me about a college degree for any of these jobs. When I got my first job, I was only one year in to a college program (at ITT Technical Institute, rest in peace). I only even went to college because motivational speakers at my high school made me think it was absolutely required. I only finished out my Associate's degree (two years total) and called it quits, only because I wanted to have something to show for my student loan debt at least. But nobody in my entire career has ever asked or wanted to verify my college degree.
Way back when I was interviewing to get my first couple of software dev jobs, I was naturally pretty anxious and worried that I wouldn't do well enough to pass those interviews. But after I got in and then it was my turn to conduct the interviews, and got to see how it looks from the other side of the table, I wonder what I was ever so worried about.
Throughout my career, I have interviewed hundreds of software developers. Many of them were fresh college graduates who went to school for computer science, but had no "real world" coding experience. Others had come from other companies and had years or decades of experience.
A thing that surprised me is that so many people who come in for an interview, just don't know how to program. I once saw this article, "Why Can't Programmers... Program?", which may be the origin story of the "Fizz Buzz" meme of recent decades.
But, I've found it to be fairly accurate. At a software dev interview, we'd often ask the candidate to write out a quick "puzzle program" to test their logic and coding ability, and for most candidates, it was like pulling teeth. They would usually get through it, with some help, over the span of 20 minutes or so.
Usually, it was the fresh college graduates who struggle the most. You'd think, being fresh out of school, their knowledge of programming would be sharp. But, in class they learned a lot of esoteric problems and rote memorization of algorithms, so when faced with a new problem they haven't specifically seen and practiced before, they freeze. Whereas programmers who had a whole career already of real world experience at various companies, they fared a lot better on these kind of questions.
The point I'm wanting to make is: if you actually know how to program, even if you're nervous at the interview, it is a night and day difference and you will already stand out greatly compared to most of the candidates who walk through that door. Having your own "real world" projects you programmed for fun, and put on GitHub, puts you at a great advantage even above the fresh college graduates who spent the last 4 years learning about computers.
When I see a GitHub link on someone's resume, it's a huge green flag for me. In the time leading up to the interview, I'll check out their source code and prepare some questions about it. If you can walk me through your projects and explain how they work, you're basically going to pass the interview. It may not seem like much, but you would be a breath of fresh air for the interviewer after they just watched the 10 previous candidates struggle their way through a "Fizz Buzz" algorithm.
This one is a valid question and the answer is just that "we don't know."
The above advice all worked out great for me and others I met during my career. The software industry bubble may be finally about to pop soon. The industry is genuinely concerned that "junior developers" may start to go extinct, as companies race to replace them with A.I. and only retain their "senior developers" on salary. Eventually, those senior developers will retire or die off, and nobody will know how to code anymore because A.I. has made everyone dumb and companies won't be able to hire new senior developers to replace them.
However: I say learning how to program is a valuable skill to have no matter what you do for your career. Even if you don't get a job as a software developer, being able to write little scripts and programs to automate the tedious parts of your job will continue to pay dividends for your entire lifetime.
While the above advice was especially for "web development" jobs, much of it applies more broadly to any kind of software development.
If you want to get into videogame development for example, C Sharp (C#) is a useful language to learn because of its prominence in the popular game engine Unity. Those are also useful skills if you want to program Virtual Reality (VR) applications.
If you are interested in mobile apps, the answer is straightforward there: Swift for iOS and Kotlin for Android, and there are many mobile app tutorials out there to get you started.
If you want to get into "systems programming" such as to work with microcontrollers and embedded systems, C is still king and will never be going away, and Rust is a popular up-and-coming language with many new jobs opening up as it can fulfill many of the same roles that C can, but in a more (memory) safe way. Many companies are rewriting their systems in Rust lately, and Rust has a massive library of modules available for doing anything from web development to videogames to desktop/mobile applications to embedded systems development.
And the rest of my advice above still applies: pick a language, check the job market if that's a concern, and then pick a project.
This may be a hot take, but in 2025 my favorite web browser is still (and has been for decades) Mozilla Firefox and I'll tell you why.
Disclaimer: I am not affiliated with Mozilla in any way, I have never worked for them or taken any money from them. I just like their web browser and have a lot of thoughts about the Web in general, as the below post will make abundantly clear. I only started thinking about writing this post after a friend asked me what my preferred browser is recently and why I said "Firefox."
In 2025, there are only about three different types of web browsers:
In terms of market share, Google Chrome currently corners 66% of the entire market and when you add the other Chromium-based browsers, such as Microsoft Edge at 5.18%, and smaller derivatives such as Brave, the Chromium Blink engine has 79% of the global browser engine market share.
Safari has a decent slice of their own, at 17.59%, thanks in large part to the way that iPhones and iPads mandate the use of the Safari engine to power all web browsers and their not insignificant market of Macbooks which have Safari as the default browser. Safari, however, does not run on Windows or Linux so while Safari is a nice browser with a good chunk of the market, it is isolated only to Apple devices whereas Firefox can run everywhere.
But Firefox only has 2.51% of the market and its engine, Gecko, could be at risk of going extinct one day.
Why is the Chromium monopoly worrisome? Because it is largely governed by Google, who is an ad company and has somewhat of a conflict of interest when designing web standards and Google's decisions in Chromium will have a ripple effect across all downstream derivatives.
I also lived through the "browser wars" era when Internet Explorer 6.0 clung to life for way too long, and had way too large of a market share, and it wasn't keeping up with the times and making life difficult for web developers who couldn't use the shiny new features that Firefox and Chrome were bringing to the Web because we had to maintain compatibility with Internet Explorer 6. A Chromium monopoly would again lead to web developers getting complacent, and designing their websites only for Chromium and not caring to test them in Firefox because they don't see the point.
I continue to use and support Firefox so that when my entry appears on a website's analytics, I want web developers to know that Firefox users still exist and they should continue to support it on their websites, lest we all just give up and let Chromium dominate the Web.
Ha.
The vast majority of Chromium developers are full-time Google employees. The Chromium project sees hundreds of commits daily with mainly Google engineers working on the codebase.
Yes, Chromium is open source and theoretically if Google makes an unpopular decision that benefits only their own interest, other downstream derivatives of Chromium could patch those changes out and undo them. For example, when Manifest v3 came out and crippled the ability of ad-block extensions which strongly benefitted only Google's interests, the other downstream Chromium browsers could simply revert those changes and maintain support for the old, working, ad block extensions.
For a time.
I'll tell you how it goes when you fork a popular project such as Chromium. If you're, say, Microsoft Edge, you take a snapshot of the Chromium codebase and then you modify it to add or remove features and you release your derivative. But then, as time goes on, you would need to rebase your code on the upstream Chromium so you can take advantage of all the security fixes, features and bugs that Google has fixed on the upstream codebase.
Web browsers are massively complicated programs and the Web is a fast moving target. Every day there are new vulnerabilities discovered that companies like Google and Mozilla need to fix in their browsers to keep them safe and secure. Google is constantly working on Chromium, and if you have a browser fork based on Chromium, you need to keep track of the upstream project and rebase your code on their latest changes to keep up.
Maintaining a web browser is a full-time job that requires hundreds or thousands of engineers. Even Microsoft could not keep up: they stopped trying to maintain Internet Explorer or their first version of Edge (which was based on IE), and threw in the towel and decided to make a Chromium based browser so that they could leverage the engineering talent of Google in providing a solid base for them to build on top of.
So, Google does something unpopular like Manifest V3 and early on, it's a simple issue to just revert those changes in Chromium when you rebase your browser. But over months or years, Chromium sees a lot more code changes, many of those changes touching the same parts of code that Manifest V3 touched. Suddenly, when you rebase your project on Chromium you get "merge conflicts" because parts of the code that you have customized (like, say, when you removed Manifest V3 before) can't be reconciled with the latest state of the Chromium code. So you need to figure out what the merge conflict is about and how to manually resolve it.
These little merge conflicts keep coming up, and the burden of keeping your fork of Chromium up to date while avoiding all the misfeatures you don't want only grows over time. Your browser team is miniscule compared to the headcount of the Google engineers who are churning out hundreds of commits per day to Chromium.
Eventually, all of the downstream Chromium browsers will feel the effects of whatever it is that Google wants to do with their browser engine. Web browsers are expensive to maintain and very few people other than Google have the budget or manpower to manage them. Again, even Microsoft could not keep up with their own browser engine.
There exist a few downstream Firefox derivatives too, such as LibreWolf or Zen.
Some of them customize Firefox to have better privacy features or add-ons by default, or they exist only because of some controversies of Mozilla that the developers decided were worth creating a Firefox fork over.
I don't use these derivatives for the following reasons:
See what I said above about Chromium: it is massively expensive to maintain a web browser, and if Mozilla is a small team compared to Google, these Firefox derivative maintainers are even smaller.
One of Mozilla's largest sources of income actually comes from Google: they pay Mozilla to keep Google as the default search engine. Google does this because it keeps the regulators at bay, so Google avoids getting an antitrust monopoly lawsuit by being able to say "but Firefox exists! And look, we support them financially, too!"
If, god forbid, Mozilla decides to give up on Firefox or is no longer able to maintain it, Firefox and all downstream derivatives will be dead, the Gecko engine would not keep up with security fixes for long and these tiny teams who maintain Firefox forks won't be able to keep going.
So, I stick with Firefox proper because that's where Mozilla is.
Of course, Mozilla and Firefox are not without their own controversies. I said at the top of the post that Mozilla is the least abusive browser vendor, not that they have never done anything to stir up bad press among the community.
However, I do always find it ironic when I see comment threads on Reddit about people dunking on Mozilla about something that is relatively minor, and then they go running arms open back to Google Chrome who is abusing them 100X more severely, but I digress.
Some of the most common things I hear people rail on Mozilla about include:
I did a bit of research just now to dig up what the Mozilla controversies were, and the above are just about it. Some people were unhappy about Mozilla commentating on politics before. Again though I find it funny when people will crucify Mozilla over something small and then run to Google Chrome with Google's whole dedicated wiki page of controversies or to browsers like Brave with their own shady dealings and "sorry we got caught" history of controversies.
The only way you get an ethically spotless web browser, I suppose, is to go with a purely volunteer-driven, open source, non-corporate one like those Firefox downstream browsers. But, again, those browsers will not exist if Mozilla ever stops developing Firefox so this is why I just stick to Firefox and have for decades, ever since they wrested some market share away from Internet Explorer 6.
Now, feel free to fight it out in the comments but this is my hot take and I'm sticking to it. 😎
I had originally written this post on my NSFW blog back around May of this year. With the recent surge of interest in Bluesky, I thought I would copy it over here to my tech blog to give it some wider visibility.
Bluesky is a very interesting app, and it is different in some important ways to Twitter and the others that came before it.
Bluesky will not enshittify over time like its predecessors have. On the surface, it appears to be "just another Twitter" but the real interesting technology is happening under the hood. Bluesky is being developed in such a way that Bluesky (the corporation) can let go of it and allow it to be distributed as an open source, open standard network that is not under the control of a single corporation who could one day destroy it.
Below I will paste my original blog post with some of the NSFW paragraphs edited out for the different audience that I have on Kirsle.net.
I've been on Bluesky for about 4 months now and have learned a bit more about how it works and I find it rather interesting, so I thought I'd write about it and give some advice on how to get started and especially how to find your fellow nudists & exhibitionists there. So, in a similar spirit to my Getting started with Mastodon post, I'll write about Bluesky especially for an audience of people who aren't already using it. And even if you are already on Bluesky, maybe you'll learn something cool from this post anyway!
Compared to Mastodon, getting started on Bluesky is fairly simple right now: there is only one front-end web server available so far, at https://bsky.app/ where you can go and sign up in a familiar way like any other site you've used. Bluesky intends to support federated instances in the future (and they've made some good progress on that, so far), which I'll get into below, but for now at least you can avoid the choice paralysis of needing to find a server to sign up on like you have with Mastodon.
In this post I'll tell you about how content discovery works, how adult content is tagged and how to find your people to follow. And I'll also go into what's especially interesting about the way that Bluesky works as compared to Mastodon and the rest of the related fediverse.
First, let's address the elephant in the room. On Mastodon, the general sentiment about Bluesky is one of negative skepticism, and many people on Mastodon talk shit about Bluesky and compare it to Twitter. After Elon Musk took over Twitter and started making a lot of people very upset, a lot of them flocked over to Bluesky and the folks on Mastodon say things like "you're moving from one platform created by a billionaire, to another platform created by a billionaire, and you think this time it's going to be different? Have you learned nothing?"
Well, to that I say: this time it absolutely can be different, because Bluesky is not just another centralized website controlled by a corporation in the way that Twitter (and Facebook, Instagram, etc.) are. The key technology behind Bluesky is called the AT Protocol which is being developed and released as an open source standard for federated web services, and Bluesky is only one app that runs on the AT Protocol. The thing with an open standard is that everybody can participate in it, and people can write their own custom apps that use it, and they can all inter-operate with all the other apps using it, and once that's out in the wild there is no controlling it or governing it from the top down.
Mastodon is a good example of this: the server-to-server language behind the scenes on Mastodon is called ActivityPub - it's what allows Mastodon servers to be hosted by many different organizations or individuals and still allow you to follow and comment on people anywhere else. And Mastodon is far from the only ActivityPub app: Pixelfed and PeerTube are just a couple of other examples. So, despite the origin of Bluesky having been started by a billionaire as an internal project at Twitter, the technology they are building to run it on is to be a distributed open standard.
The problems we faced with centralized sites like Twitter, where a change in ownership or a pivot in business strategy left all their users held hostage, aren't nearly as possible with federated services like Mastodon because you can simply move to a server run by somebody you trust better. There's no way it can be enshittified from the top-down in the way a centralized platform will be.
Now, it is fair to remain skeptical of Bluesky until full federation and open-source self-hosting becomes possible. They are actively developing the AT Protocol and, while third-party developers are already writing code to support it, the system is not fully open and ready yet. The down side of building an open standard is that, once it's out there, you've lost control of the direction it will evolve. It's important to design it the best as you can in the beginning, which is why Bluesky has been going at such a slow pace. But, they've been continually making good progress: it is now possible to self-host your data on your own server and complete data migration of your account to your own server is working (and is much more fully featured than a Mastodon account migration, which I'll get more into below).
So, let's get into the user experience of Bluesky. You've created a new account and have a lot of questions, like: how do I find people to follow? How is "adult content" tagged and discovered?
One thing that I noticed pretty quickly was that hashtags don't exist on Bluesky (though I've seen some screenshots to suggest this feature is 'coming soon', edit: we have them now). I would post some of my nudes, though, and get followed by random people and I didn't know how they were even discovering my page, especially if my recent post hadn't yet been reblogged by any of my followers!
Instead of hashtags, Bluesky has a featured called "feeds." When you sign up an account, they'll suggest a few feeds for you to discover, themed around various topics. I followed a few feeds with names like: Science, Astronomy, Developers, and Fungi Friends.
I don't know how feeds are created, but it seems that a developer somewhere had to write some code to create a feed. You don't need to worry about that, though: if you find the feed you can simply follow it/add it to your home timeline and be able to see the posts that the feed has discovered.
[redacted] Here are a few NSFW/adult content-oriented feeds I have found, if you're an exhibitionist like me and want to find your people there:
You may need to go to your "Settings -> Moderation -> Content Filters" to enable adult content if you like to see that stuff. 😈
Sharing a post on Bluesky should be very familiar compared to Twitter or anything else you've used. You can write some text and attach some pictures.
A couple of notable aspects of sharing a post that I want to highlight are:
I highly recommend writing alt texts because: those "Feeds" that help others discover your post will see your alt texts as well. When I wondered how people were discovering my posts without any hashtags, that was how. You don't need to spam a bunch of hashtags in your posts like you did on Twitter, you can just graphically describe what is shown in your pictures and be picked up on the relevant feeds for people who want to see that stuff.
And also: describing nude pictures in writing is just a very fun exercise in itself. 😈
I should also share some of the current lack of features or quirks about Bluesky that you may want to know about here.
Issues like these seem to be on the radar of the Bluesky/AT Protocol developers and may be improved upon in the future. For me personally, they are non-issues: I've always treated my Twitter (etc.) page as fully public, I've rarely ever had to block anybody, and for DMs you have always been better off taking your conversations to proper chat platforms anyway.
I think I should elaborate on that last point: Mastodon has Direct Message support but their web interface is clear that DMs on Mastodon are not secure. They say that because a DM needs to be synced to the other server your friend is on, and your server admins on both sides do have the technical capability to look in their database and read your DMs. New users on Mastodon are surprised about this, but guess what: this has always been the status quo even on centralized sites like Twitter. Whoever runs the server and database has always been able to read your DMs if they so chose to, unless your DMs are explicitly "end-to-end encrypted," which they usually have not been.
I don't know how Bluesky will implement DMs, but they seem to share this concern and (I suspect) they will bring DMs only when they are able to end-to-end encrypt them properly, which is a hard problem to solve for website-based applications, for reasons I won't get into here.
But anyway, if you're one who liked to run a "private" page where almost nobody but your friends can see your posts, etc., I thought it fair to point out how Bluesky currently works in that regard.
Mastodon and ActivityPub more generally are interesting, but I wrote before about some of the pain points and issues I have with it.
The good news is, Bluesky and the AT Protocol address some of the biggest pain points in ways that I find very interesting. In fact, the whole reason that they are developing the AT Protocol to begin with is because they found ActivityPub to have fundamental limitations that were at odds to their vision of how much better an open, federated social network could be.
A couple of examples in particular of the pain points with Mastodon include:
On Mastodon, if you no longer like your current server and want to move, you can "migrate" your account to a new place. However, this doesn't work the way that most people would hope: only your followers are moved over, but not your posts, and not the list of people who you follow.
Migrating to a new Mastodon host is basically like starting over with a fresh new account. The only nice thing that Mastodon migration does for you is to automatically move your followers, so you don't need to tell them about your new profile and they'll update to follow it automatically. Usually. Your mileage may vary with non-Mastodon software and you still might lose some followers in the move.
One of my #1 top favorite features of sites like Tumblr or Twitter was how I could write a bunch of posts over many years, and at any time, somebody who newly discovers my page was able to scroll all the way back on my timeline, if they wanted, and easily see everything I had ever posted before.
On Mastodon, this usually doesn't work very well: following somebody on Mastodon is more like subscribing to their newsletter. Your local server will show you their new posts going forward from the moment you began following them, but chances are very good that your local server does not know about their old posts from before. The only time their older posts may be available, is if your local server already knew about them before (e.g., because somebody else on your server also follows them, and so has been bringing in their posts). This is a fundamental problem with ActivityPub more generally: it is an "inbox/outbox" based protocol and there lacks a standard method to deeply retrieve historical posts from another server.
On Mastodon, it is a common experience that somebody follows you and you visit their profile, and only see maybe a couple of posts, and a notice that says "Older posts from this user are not available, click here to go to their Mastodon server to see their full page." That would be okay, but if that user is primarily NSFW and all their posts are nudity/porn, it becomes very tedious to scroll back through their page: you need to click to reveal every single blurred picture, because you probably don't have a local Mastodon account on their server, so you can't have an "automatically show me NSFW content" setting there. Speaking for me personally, I never dig very deep into somebody's page on Mastodon if I need to put up with all of that.
As I mentioned on my Fediverse pain points post, moderation on Mastodon is handled at the server level: your local server administrator makes decisions about how to moderate content coming from other servers, in ways that can harm their local users if these decisions are not ones that you would agree with. And as an end user, your only recourse then is to migrate your account to some other Mastodon server, run by somebody you like better, or to self-host your own Mastodon server where you get to decide on these things.
In an ideal world, this would be OK: since Mastodon is open source and anybody can run a server, sometimes those servers will be home to terrible people, such as racists or transphobes or general assholes. Your server admin being able to wholesale ban these servers keeps you and the rest of your users safe. But sometimes, server bans are put in for absolutely stupid reasons, personal beef between two server admins, over drama that you don't really care about, and now because a server block was put in place, you are cut off from your friends who had accounts on the other server.
The only way you avoid getting caught as collateral damage in moderator drama like this, is to self-host your own personal server yourself, where you alone get to make these moderator decisions, but that comes with its own helping of downsides: needing to have the technical skills to run a server correctly, not having a local timeline of like-minded users to discover, etc.
Recently, Bluesky has open sourced their Personal Data Server code which allows you to self-host your data on your own machine, instead of hosting it on Bluesky-managed servers. Along with the PDS, you are able to migrate your account from Bluesky's servers onto your own.
Bluesky migrations are full data migrations. They don't just move your followers like Mastodon does, it will deeply migrate all of your data: your complete timeline of posts and their attached images, and everything. This is what Mastodon users hoped for when they saw there was an ability to migrate to other servers when needed, but Mastodon fell far short of user expectations here.
And, Bluesky solves the timeline problem here too. My account is all hosted on the main Bluesky server, but I follow some self-hosting enthusiasts who've already set up their own PDS servers, and I can view their profile page within Bluesky's (bsky.app) web interface, and I can scroll all the way back to the beginning of their timelines if I want to, and I don't have to click to reveal all their NSFW images because I'm viewing them from the server my account is on, where I have opted-in to see adult content without blurring. So again here, Bluesky's style of federation does what I would hope for and expect Mastodon to do, but which Mastodon does not do.
And finally, Bluesky puts moderator decisions in the hands of users where it belongs. Admittedly, moderating 'the entire Internet' is a big job and most people don't really want this responsibility, so Bluesky has "moderator lists" where you can choose to follow somebody else's list if you like theirs. So if you want to keep yourself shielded from terrible people, you can follow somebody's moderation list where they do that job for you. But if they make decisions you don't like, or they cut you off from your friends on accident, you can fix that yourself by changing which lists you follow. You avoid inter-admin drama over silly nonsense you don't care about that way. For a bit more reading, here is a recent Bluesky blog post about moderation.
Identity regards your username or how people discover you in the app.
On Mastodon, your identity is tied closely to the Mastodon server you signed up on. If you signed up on the server "mstdn.social" your Mastodon handle looks like "@[email protected]". If I want somebody to follow me on Mastodon, I give them that full identity handle and they paste it into their search bar to bring me up.
The down side comes when I want to migrate to another server: my identity will change! My first Mastodon profile was @[email protected] because I signed up on the mastodon.social server. I've migrated a few times since then, which always gave me a new identity. I was able to move (most) of my followers each time, so they didn't really need to care that much, but I did need to update my blog and find/replace all the places I linked to my profile and update to the new location.
On Bluesky, identity is de-coupled from the server you signed up on. They rely on the tried and true Domain Name System for identity. For most Bluesky users, they have names that look like soandso.bsky.social where they have the "bsky.social" domain in their handle. This may be OK for most people who don't own their own custom domain names, but you don't have to have a .bsky.social handle. My handle on Bluesky is my blog's domain name: @kirsle.net. If you have your own domain name, you can use it as your Bluesky handle, and then you never need to worry about changing it, even if you migrated to a different Bluesky server in the future!
And even if you have a .bsky.social handle now: you could keep that handle even if you migrate servers, too. But if you were interested in self-hosting your data, getting your own domain name is the most sure way to make sure you're always in charge of your identity.
Should you check out Bluesky, my profile link is at https://bsky.app/profile/kirsle.net and you can give me a follow.
I think that'll do it for today, until I have any more exciting news about Bluesky (probably when they make further advancements towards allowing open federation and full self-hosting). When the dust settles with all of that, I plan on setting up my own Bluesky servers for myself! 😎
0.0019s.
