Welcome to!

This is the personal homepage of Noah Petherbridge, and it's where I keep my web blog and various creative projects.

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.

Sketchy Maze v0.12.0
March 28, 2022 by Noah

It's been a while since I posted an update about my videogame project, Sketchy Maze but I've still been working on it and had released a handful of updates since my last post about v0.7.1 and my game is starting to get interesting. 😉

Sketchy Maze is a drawing-based maze game where you can draw your own levels freehand (like MS Paint) and make them look like anything you want. You can draw a castle, a cave or a giant boat, and then play it as a 2D platformer game. You can drag and drop some "doodads" such as buttons, keys, doors and enemies into your level to make it exciting. And as for those doodads? You can also create your own, too, and program them in JavaScript to do whatever you want. The game also includes a built-in Story Mode of example levels to simply play and/or learn from.


Since my last update about v0.7.1 the game has got:

  • 8 new levels (now 12 in total across three built-in levelpacks)
  • 15+ new doodads, including: Anvil, Electric Trapdoor, pushable Box, Thief, Azulians, Checkpoint Flags, and a handful of technical (invisible) doodads for things like a custom Goal Region or Checkpoint Region if you don't want the flags.
  • Scoring and progression system, and hostile enemy creatures you need to dodge.
  • Controls added for touch screens and Xbox-style game controllers including Switch Pro Controllers.
  • Proper platformer physics with velocity, acceleration and jumping.
  • New drawing tools for the editor: Text Tool, Flood Fill/Paintbucket, Zoom in/out.
  • A much more capable JavaScript API for custom doodad scripts to enable more interesting behaviors.
  • Many user interface improvements.
  • 32-bit Windows and Linux support added.

The full change log is always available on the Guidebook for more details.

If you haven't seen my game yet, check it out! It's still in beta so it may be buggy or crash sometimes, but any feedback is welcome!

Tags: 0 comments | Permalink
Week 2 of daily driving the Pinephone
November 15, 2021 (updated December 15, 2021) by Noah

About two weeks ago I again put my SIM card into my Pinephone to see whether I can make it a daily driver device. The last time I tried this was nearly a year ago so I have that benchmark to compare it to as well as some new information now.

The stack:

  • Operating system: Mobian with the Phosh UI.
  • Carrier: T-Mobile (US)

The highlights:

  • I have MMS messaging sorta working: I can receive picture and group chat messages perfectly fine, but I can not send out an MMS myself. I can reply to a picture message as SMS but for group chats, if I need to respond, I can just pick somebody and send them an SMS out-of-band if need be.
  • Battery life is okay - not great, but given how often I actually use my phone, it's not bad either. Every other night I'll plug in my Pinephone or my Pixel 3 to charge, and my Pinephone gets me thru the day and then some (I can leave it not charging overnight, and it doesn't suffer too much for it).
  • Reliability for incoming phone calls while the phone is deep sleeping seem to be improved since last year. My Pinephone was sitting on my desk one day, removed from power, sleeping, and it rang and I answered it.
  • Other cell phone functionality all working OK: calls, SMS, 4G LTE data, and hotspot sharing over WiFi all working.
  • Waydroid seems more stable on Mobian and it runs my Android apps okay, and with KDE Connect I can get notifications from Android apps in my Phosh UI.
  • GPS location accuracy may be a challenge to sort out.

The details:


Tags: 2 comments | Permalink
Waydroid on the Pinephone is a game changer
September 24, 2021 (updated October 11, 2021) by Noah

This week, some news about Waydroid made its way to the r/linux subreddit and in the comments I saw a Pinephone owner write about their experience with Waydroid and none of his complaints had anything to do with it being slow or clunky or broken, which is about what my experience was the last time I tested out Anbox about a year ago.

So it prompted me to check Waydroid out, and... it works remarkably well! It really surprised me. Waydroid makes use of containers to run Android directly on your own Linux kernel, without emulation, and so it performs very well -- some Android apps even run more smoothly than their native Linux counterparts!

I wasn't expecting that the Pinephone was ever going to be able to run Android apps smoothly on a GNU/Linux system, but now that it does, and does so this well, this is a game changer in terms of the Pinephone being "daily driver" ready. Finally, I have a way to use Slack and Discord from my Pinephone, something that was basically not possible at all before!

Screenshot of Discord (Android) running on Mobian

Now, to be clear: even without Android, there are a very good collection of Linux apps that already work well on the Pinephone. Having the option of Android for the odd proprietary app like Slack or Signal is nice to have. Read on to the full blog post for how Waydroid works right now, what are some of its pain points still, and a few screenshots of my Phosh app drawer showing everything I have installed on my Pinephone.


Tags: 12 comments | Permalink
Developing a game from scratch
July 21, 2021 by Noah

For the past few years, on and off (sometimes more off than on), I've been working on a videogame called Sketchy Maze and had been taking screenshots of it along the way. This blog post will be a bit of a retrospective and a series of screenshots showing it from its very first prototype up to the state that it's in now.

I wasn't even sure I was going to get very far on this project. I had once attempted programming a game in Perl and lost steam after barely having a working prototype. I had dabbled a few times getting started programming a game but then decided my brilliant idea of an RPG game wasn't worth all the programming. Stubbornly, I never wanted to just use a game engine like Unity or Unreal but wanted to program it all myself. And programming from scratch is considerably the harder way to go, so your game idea had better be worth it in the end!

The game idea that won out is a personal and nostalgic one. Back in the 90's when I was growing up with videogames like Sonic the Hedgehog and Super Mario Bros., I would often draw my own "mazes" or levels like on a 2D platformer game, with pencil and paper and then "play" it with my imagination. I'd imagine the player character advancing through my maze, collecting keys that unlock doors, pushing buttons that activate traps somewhere else on the page. I'd write little annotations about which button did what, or draw a dotted line connecting things together. My mazes borrowed all kinds of features from videogames I liked, all your standard platformer stuff: buttons, trapdoors, conveyor belts, slippy steep slopes, spikes and water and whatever I wanted.

So my game concept was basically:

  • Players can draw their own mazes completely freehand, with w/e colors they want
  • Players can drag 'doodads' like buttons and keys into their level, and link buttons to devices, etc.
  • And it should be mod-friendly af: players can make custom doodads with custom behavior (programming)

See the full blog post to read how I even got this started and see screenshots of progression between the "Before and After" pictured below. My first target goal was just a stupid simple white window that I can click on to turn pixels black and save it as a PNG image. If I could get that far, I could do all the rest.

Before and After


Tags: 0 comments | Permalink
Sketchy Maze v0.7.1
July 11, 2021 by Noah

It's been a while since I last wrote about my videogame project, Project: Doodle, which has now been given a proper name: Sketchy Maze. There have been a few releases of the game since I last wrote about version 0.4.0 and they bring some exciting new features!

Screenshot of the title screen of Sketchy Maze


Tags: 0 comments | Permalink
"Just compile it yourself!" and other misguided security suggestions
June 9, 2021 by Noah

On forums like r/privacy people often discuss the role of open source software when it comes to privacy and end-to-end encrypted messaging applications. The general consensus is: a privacy focused app must be open source so that people can get their eyes on the source code and audit it for security vulnerabilities, verify it's doing what it says in the tin and without any secret government backdoors built in that would undermine the security and reveal peoples' private chats.

These are all well and good: if the source code is not open, you can't verify the code isn't doing something sneaky like uploading your encryption keys to the service provider or whatever. But, open source alone isn't a silver bullet to help guarantee the security of the app:

  • Just because the code is readable and somebody could audit it for bugs, doesn't actually mean anybody does. Some vendors of such software may hire security firms to deliberately audit their code, but for random small projects that haven't been formally audited, "open source != automatically secure" -- but still, it is better than closed source where nobody can audit the code.
  • Just because the source code is available doesn't mean the program you download from the App Store is built on exactly the same code. Google Chrome, for example, is built on top of the open source Chromium browser but after Google injects a few proprietary services and features; the Chrome program released by Google has features not found in the Chromium source code. This can be helped by so-called "reproducible builds" and I'll cover that below, but reproducible builds do not come "for free."

In this post I'll address a few common tired things I hear people on r/privacy say in regards to this topic and how it's never quite that simple.


Tags: 0 comments | Permalink
Blockchain in a nutshell
May 9, 2021 by Noah

Have you ever wondered basically how blockchains work and what it means to "mine a Bitcoin" and why it's a time-consuming (and energy-intensive) process to mine one? In this blog post I'll summarize what basically drives blockchains and how they work, from my understanding of them anyway.

If you're anywhere close to a novice web developer or have ever hashed a password in your life, you already know the basic technology at play here. And even if you haven't, I think I can get you caught up pretty quickly.

The explanation I give below is surely super simplified and is based on my reading of how these work, along with several "Create your own blockchain in under 200 lines of code" type of tutorials which you could find for Python, or JavaScript or anything. It doesn't cover how the decentralized networking aspects work or any of those details, but just the basics on the cryptography side.


Tags: 0 comments | Permalink
Visual perception and peeking thru the veil
April 2, 2021 (updated April 3, 2021) by Noah

Among my many diverse interests, one thing that fascinates me is to contemplate the nature of the universe and what Reality is made of, or at least, what my perception of Reality is made of and how the inner mind works.

To that end, topics such as quantum physics, simulation theory, and esoteric writings from the world's oldest religions like Hinduism and Gnosticism are interesting to me, and I like to talk crazy about that sort of thing from time to time.

In this post, though, I'm going to write strictly about visual perceptions that I've experienced at different times in my life. Many are related to psychotropic compounds, including cannabis, but now I'm able to experience some crazy things just by meditating while sober too.

Stories on the full blog post:


Tags: 5 comments | Permalink
VNC Server for Pinephone
April 1, 2021 (updated July 24, 2021) by Noah

I didn't find this documented very many places but it's possible to get a VNC server running for "remote desktop" to access and control your Pinephone display from your laptop.

Quick list of related technologies:

  • To take screenshots of your Pinephone, use the grim command.
  • To record videos of your Pinephone's screen, use wf-recorder.
  • To run a VNC Server, use wayvnc.

Mobian already packages grim and wf-recorder so these are just an apt install away, and these are documented on Mobian's wiki. But wayvnc is not yet packaged in Mobian and you gotta build it from source code yourself.

Follow the directions on the git repo, including cloning down the neatvnc and aml dependencies. The README has instructions to build it for Fedora and Arch but the Debian instructions are missing! I found by trial-and-error the dependencies I needed to install to build this program for Debian:

sudo apt install gcc meson ninja-build pkg-config libpixman-1-dev \
  libdrm-dev libxbcommon-dev libwayland-dev

I ran the built binary like wayvnc to start the server and connected with the TigerVNC client from my desktop.

It has a couple of quirks to watch out for:

  • The mouse cursor only appears on the Pinephone's screen, but not in the VNC viewer window, making some UIs hard to work with (the lock screen in particular). Edit: use -r --render-cursor options to get the cursor to work. Thanks, anonymous commenter!
  • The Pinephone display was "too tall" to fit on my screen when in portrait orientation. My desktop monitor is 1920x1080 but the Pinephone display is 720x1280 so it ran off the bottom of my screen by 200 pixels. Switching the display to Landscape fit better.


Tags: 3 comments | Permalink
A federated social app idea
March 26, 2021 by Noah

This is a general idea or concept I've had kicking around in my head about a way that a federated social network could work, wherein the user's own local device controls their identity rather than having a username on somebody's server.

To understand what I'm talking about, first let's run through what a federated social website even is. Briefly:

  1. Facebook, Twitter, Instagram and so on are all centralized social networks. You register a username on, their database holds your profile and user information, and you can follow and talk to other Twitter users that are on the same website. But from your Twitter page you can not comment on an Instagram post; you need to go make an account on Instagram to use their centralized social network instead.
  2. So then you have the Fediverse and for a specific example, Mastodon is a federated Twitter-like web app. It's open source, there's hundreds of servers, each run by various individuals or small companies, and you can install the Mastodon server on your own machine if you like. No matter which Mastodon server you sign up a username on, you can like, follow and comment on anybody's posts on any Mastodon server you like. I could be "@kirsle" on the "" server and you can be "@soandso" on the "" server and we can follow each other all the same. It's decentralized, but each server does still have their own user account base.
    • But what if my chosen Mastodon instance decides to shut down? My profile goes down with it. Sure, I can sign up on another instance but I lose all my history and gotta start over from scratch!
  3. What if there was a way to own my own profile on my local device, but still be able to interact with users on a decentralized fediverse of different servers?

How would it look? With typical websites, there's a database and everyone has a user ID in it along with their email, username, bio text and whatever other details, and each website has their own database. What if you could move that user authentication to the client side? So instead of, "I log in as @kirsle with my password, so your back-end database can attest to my identity" it's instead "I'm telling you who I am, using a profile stored on my phone and not on your database."

The technologies to make this work on the client-side apps would be:

  • Public/private key cryptography. Each user device would roll its own encryption keys, keep the private key to itself, and the fingerprint of the public key becomes your "globally unique user identity token" -- in exactly the same way that Bitcoin wallets work, or how Tor .onion hidden-service domains work, and so on. You can't spoof my public key fingerprint unless you have the exact private key that goes with it.
  • My local device holds a JSON blob of my profile data: my nickname, my avatar picture, my bio text for my profile page, and any other personal account info.
  • When my device connects to your server: I send my public key fingerprint, + my blob of personal account information, + a cryptographic signature of my account blob signed by my private key which matches my public key fingerprint.
    • When your server sees me the very first time, it could create a row in its database using my public key signature as "user ID" or w/e as needed for the server's operation, e.g., so if I create a post, the "user ID author" of the post is my public key. Or it might cache my account info to be shown in comment threads to others (for my avatar URL and display name, etc.)
    • When I come back to your site later, your site still remembers me and I still 'own' the posts I made (can edit or delete them if I want, etc.); nobody else can spoof as me unless they have my private key.
    • If I spam your server you can ban my public key signature, and I'd need to roll a new account. The landscape of spam problems on the Internet is not any different to the current status quo (ppl can just sign up new usernames...)
  • For the technically inclined: think JSON Web Tokens except each individual client app is attesting to their own identity: the client tells the server who it is, without passwords or anything, and the server just takes their properly formed message as-is and uses their public key fingerprint as user identifier for any back-end purposes.

Now, what kind of site would this support? Not a site like Twitter or Instagram where users have a timeline and you host decades worth of pictures for them; these sort of sites require too much back-end state around user accounts.

Think instead of a site more like Reddit. Reddit is a "forum of forums" with tons of sub-communities but it's all on a centralized site. Imagine instead, that instead of subreddits on one site, each subreddit was its own separate server altogether, each server operated by different individuals on the Internet?

The server only hosts the forums and comment threads, not the user profiles. The user profiles are kept with the client app. If a server disappears, only its discussions are lost, not the users too.

So with my "self-authenticated client app" I could connect to a dozen different servers, each hosting their own communities, using my own local device identity to seamlessly authenticate to each server and post messages to their boards. The long-term state of each server, then, is only to do with the forum messages and less to do with maintaining profile pages and timelines. If a particular server decides to shut down and close up shop, nothing is lost, no user accounts were centrally tied to that server, users will just find replacements for their particular community discussions.

This idea is free for grabs, I don't think there's any money to be made from it, and I wouldn't mind if somebody made it a reality, I'll probably be too lazy to develop it myself. :)

Tags: 3 comments | Permalink