iroh seems like a very well positioned product in the era of people rapidly building applications for personal use. I'm really interested in seeing how they continue to grow.
I personally have been looking off and on at providing an "app relay" using it, where people can get an OSS, self-hostable (if desired), zero config way to remotely access their app/data on their network. This would be separate than a "network relay" (a la Tailscale), as this is done selectively as part of the application server and client, requires no knowledge or configuration as the user, and exposes a much smaller surface area.
I would recommend that changing to GPL just to gain better ad blocking, which is far from being a primary feature, is probably not the greatest idea if you care about licensing.
I wasn't taught directly (and don't know what I'm doing still), but I've had a lot of fun learning about retro hardware design as a software engineer. I've made a few of my own reverse engineered designs, trying to synthesize how the real designers would have built the chip at the time, and ported others for the Analogue Pocket and MiSTer project.
Unsong is extremely amusing to me for some reason. Something about how Scott comes up with reasonably sounding similarities and manages to make those relate to an overall story.
That ends up not actually being that fast. The real goal was to be able to wake the Pocket/Tamagotchi core and have it automatically fast forward time as if the device was running that whole time. But when the FPGA fabric (and my design) limits us to 1800x, that means we get a whopping 30 minutes of sim time per every 1 second of real time. So even if you slept the device for a day, it's unreasonable to wait for it to fast forward.
Nothing special happens when fast forwarding, other than you can kill your Tamagotchi very quickly :P
As someone with no hardware experience, I find working with HDLs to be a very different environment and potentially hard to reason with. I did my best to document things from a software perspective (particularly for the Analogue Pocket) (https://github.com/agg23/analogue-pocket-utils/wiki). My code is also running in some capacity in most of the main core ports to the Pocket.
I wrote my first project in VHDL (https://github.com/agg23/openfpga-pong) due to the type safety, then learned that the US (and Analogue team) primarily use Verilog, so I switched. I don't use many System Verilog features, but I saw no need to use older versions unnecessarily.
I've talked to the Amaranth people. I'm not incredibly interested in using real programming languages to write HDL, but I think I like keeping programming and hardware separate in some ways.
The Analogue Pocket is fantastic for getting started with FPGAs because everything you need is built into the device and it's not "too" expensive. You do lack Pmods. There is the fully open source Game Bub (https://www.crowdsupply.com/second-bedroom/game-bub) as a cool new platform to target, but it will have orders of magnitude fewer users than the Pocket. NOTE: I am extremely biased about the Pocket; I have a working relationship with Analogue and own the main platform ports to the Pocket (for example NES, SNES, and many more).
This is something you can accomplish very easily in a ESP32 form factor, streaming audio over wifi/bluetooth. However, it doesn't fully deliver the same experience; the goal was for it to replace your phone, so it needs to support a lot more functionality such as data persistence, offline support, notifications, cellular, maybe some form of visual IO (the laser projector), etc.
From my perspective I was just interested in the excellent industrial design, which is something that is virtually impossible for a DIY setup to attain.
It would, but the vulnerability was found and patched in mainline Android a few months after the device came out, but with over half a year until support was dropped. We obviously can't expect them to have kept the OS up to date, especially given the pressure they were under, but applying security patches seems very reasonable.