Ok, since cura is super old and @foosel wasn't really for it I am dropping shipping of it in the next build (committed to devel).
I am considering adding slic3r but that is a different issue for now.
Adding a modern slicer such as slic3r might actually give reason for a Pi4 to control OctoPi.
Will note I have no hardware and can't test it though.
You don't think but you don't know. I believe there is hard evidence that you CURRENTLY can't install a 32-bit version of the OS.
Will this change in the future? I don't know. Technically, it should be possible (by wasting 4GB of memory).
Don't you love it when you answer your own questions? 
I based my thinking on what the raspberry pi foundation says. You'ld think they know.
Your hard evidence only shows that you cannot install the CURRENT 32 bit version of OctoPi on the RPI 4 8GB. The new 64 bit image thats floating around in this thread does not work because it is 64 bit, but because it has all the required bits. It is very possible to create a 32 bit version of OctoPi that runs on the RPI 4 8GB and all the other raspberry pi models.
I think we are in violent agreement. I have always said CURRENT and you are adding " that could change in the future".
Unfortunately, neither one of us has one of these 8GB beasts to verify 
The first step of answering a question is for the question to be asked.
I am completely new to any of this. Got my printer a week ago. Ordered a new Raspberry Pi (4, 8 GB). Installed the 64bit beta and followed Setting up OctoPrint on a Raspberry Pi running Raspbian to install Octoprint.
So far, everything seems to work: I see the interface, can install plugins, etc. (But I have not connected the printer to the Pi or a camera yet. ^^)
I uploaded it again because the link wasn't working anymore.
There are some problems with the picam and hardware acceleration in the 64bit image right now.
I tested some things but they didn't work out. For now I suggest using a usb cam.
Do not run rpi-update - it breaks alot of the pi related stuff like vcgencmd.
hoops, 
I tested the rpi-update, so I will reinstall the card, no problem.
With a usb camera, it works fine, but I can't get octolapse to work.
The problem may come from me, I need to spend a little bit more time on it.
Thank you 
for your efforts, I would wait for a change for the camera pi.
I'll keep an eye on new updates from the raspberry people.
Yeah, my assumption is they haven't even got a stable kernel yet that supports everything. From what I was reading relative to the h264 was that the openamx driver probably would never be supported, and everything was pointing toward utilizing v4l drivers. I know nothing about this stuff though so take my word with a grain of salt as they say.
Any chance you could refresh this link so I could try it out? Thanks!
I refreshed it yesterday
Hi,
I'm completely new to the 3D printing community, Raspberry Pi and Octoprint. So I'm as green as can be. I was also one of the overly enthusiastic people that rushed in and just bought a PI 4B without reading the details about Octopi not functioning of 8GB. I just figured having more memory seemed like a good thing.
Anyway after shouting many colourful words at my Pi 4 and throwing my hands up in the air, I found you guys here discussing this issue and wanted to express my enormous gratitude to you guys for coming up with a solution to this. I'm using the beta now and happily printing away!!!!
You guys are life savers. The remaining hair on my head thanks you too.
Cheers
For what it's worth, the 32-bit version works completely fine on a Pi 4 8GB... once you've updated the packages. I put a brand new OctoPi SD in my Pi 3, sudo apt-get update, sudo apt-get upgrade, and then it worked completely fine on my Pi 4 8GB.
Nice, but keep in mind, that a 32 bit OS still can only use 4 GB of RAM, even when you update the packages.
No, one process can only use 4 GB ~3 GB, but multiple processes can use up more than that.
Edit: for reference, from the article about the launch of the Rpi4/8GB:
Our default operating system image uses a 32-bit LPAE kernel and a 32-bit userland. This allows multiple processes to share all 8GB of memory, subject to the restriction that no single process can use more than 3GB. For most users this isn’t a serious restriction, particularly since every tab in Chromium gets its own process. Sticking with a 32-bit userland has the benefit that the same image will run on every board from a 2011-era alpha board to today’s shiny new 8GB product.
I see - then I've got wrong information...
I remember back in the day when we ran 32bit x86 servers general they were limited to 3 or 4gb per process but overall the kernel could use some thing like 64gb although not going over 16 was recommended. (I think we ran them at 24GB)
But I have seen some benchmarks somewhere showing even the pi 3+ is faster on 64bit pios. Of course benchmarks and actually noticeable difference aren’t the same thing.
That is probably not due to the 64 bit-ness of the tested release, but more due to using ARM v7 instead of ARM v6 instructions. The 32 bit Raspberry Pi OS is still (mostly?) using ARM v6 for compatibility with older Raspberry Pi boards.