To spread awareness of the Linux ecosystem, the very first "Live CDs" played a crucial role: by taking away most of the fear of overwriting their hard drives, they allowed more people to test and effectively use any spin of the Operating System, and by keeping the filesystem in RAM, have any changes magically disappear on reboot. This has always been possible, RAM constraints aside, because desktop BIOSes tend to support easy booting from external devices.
The situation on Android devices is, however, more complex. Since most consumer ARM devices are not allowed to boot by any drive other than the internal flash storage, the fastboot protocol used on most Android phones solved this by enabling, in most of its implementations, commands to boot a custom kernel (just on unlocked devices). Furthermore, by unofficial means, even iPhones supported by projects like checkra1n could theoretically sideload kernel code from the modified bootloader.
The "network boot" feature has always been, in fact, one of the most requested features to postmarketOS, and maybe one of the points that prevent it, in practice, from getting more widely to the mainstream.
Initiated around one year ago by Mark "nergzd723", then picked up again and finalized months later by Luca "z3ntu" Weiss (Fairphone), the initial support for network boot has finally been approved to be integrated inside postmarketOS, and will likely arrive to all Fastboot-supported devices in the next weeks.
The network-assisted "live" boot process that is being enabled works fairly simply: we already have Ethernet via USB, even in the pre-init stage. Combining this with a small yet powerful protocol, nbd, that is also implemented in the BusyBox set of utilities that the initfs of postmarketOS uses, we get the ability to load a block device that is present on another host, in this case the host PC that initiates the flashing and to which the device is attached, like a full network disk.
How this works in short is that:
- We add an initfs
pmbootstrap, which is a tiny shell script that will be appended to the initialization stage of the bootable image. This script will load the
nbdserver that keeps listening, and loads the main system image whenever it becomes available.
- When running the
bootcommand from the desktop host to the USB attached device, the latter receives a
fastboot bootcommand, so the internal bootloader downloads and live-boots the small kernel image to RAM without flashing it to the system partition.
- This in turn boots to the initfs, the Linux initialization stage, which starts the
nbdservice seen above and waits for the image to arrive over USB.
- Then it mounts this image as the destination root filesystem, and proceeds to the boot phase, with
nbdstill enabled to receive whatever new chunks of the image are needed, exactly as if it was a physical peripheral mounted into the device.
This process is "tethered", meaning that the PC/USB Ethernet connection is the boot medium, and by lazy-loading blocks as if it was a disk drive, if the cable is unplugged, the system will clearly stop working as expected. 
As a final warning, the Fastboot protocol tends to have varied implementations, and can get buggy especially on older or peculiar Android devices. So it is not sure whether all devices implement Fastboot's
boot command directly, just ignore it, or even misinterpret it in disastrous ways. So always make sure to keep a backup of your original fastboot images if you want to try anything that involves flashing Android systems.
You can find the merge request that this article was referring to below, in the hope that this will help more people try out postmarketOS on their old Android devices, and bring the mobile Linux ecosystem one step nearer to the mainstream.
 An alternative approach would exist, at least for devices that can afford to dedicate gigabytes of their RAM (so realistically ~3/4GB in total) to pre-loading the rootfs in memory, and have a live session that tolerates cable disconnections. In this case, one could download the root image to the device even more simply (e.g. through HTTP!) and then mount it after it is received and its checksum has been verified. But this is not yet possible in postmarketOS, and so lies outside the scope of this article.