I don't think that this is a particularly viable option. While people can run whatever services they want on their routers/networks, I think many would agree that it would be extremely unwise to open their routers for random people to run arbitrary applications on the device that is responsible for providing connectivity and protection for network. Further, routers are also not usually general purpose computers -- many have limited RAM, very little storage (that isn't designed for high frequency write cycles), and typically pretty weak CPUs (because they can rely on dedicated routing hardware that is purpose built). Just running the API would be challenging, and then running other executable code would probably overwhelm the resources on the router, causing it to slow down or even crash OOM.
Router at home used for WFH. It has more than just entertainment enabling value. Also on private property. Would QoS policies protect adequately the technical side? And renting out to a business entity responsible for content protect adequately the legal standing?
I never thought enough to run a packaged mastodon instance. A very small Nostr maybe. Or countless scripts that populated free Heroku until not long ago.
on consumer routers, no. Ironically, QoS actually slows down many routers because it requires the CPU to inspect and evaluate the traffic... further, QoS (as enabled on the router) is about shaping network traffic - it doesn't shape the CPU bound processes.
I'm not going to comment about the legal aspects of this -- I don't know the answers and I could only speculate. If you are curious, feel free to consult a lawyer about this (also, keep in mind that laws are different in every jurisdiction, so it could be really complicated when you consider local regulations all the way up to federal/national laws).
A little bit of research yielded the model mentioned has a CPU roughly equivalent to a Pi2. With hardware accelerated networking features. Peoples do a lot of things with a Pi2. Newer models are even better. RAM is the main constraint.
If large corporations with fleets of hundreds or thousands of this nano computers have not come out with a better use of them, there may not be a good business case. But worth exploring the idea.
I can think of few ways to trace responsibility back to the ultimate beneficiary of a nano service. Less so how to recognise revenue with nano installations. If that is the way.
That is really not very impressive. As a reference, the pi4 is actually pretty powerful, but the earlier pi devices are not really suitable for routing purposes.
As I also mentioned, aside from processor power, storage and ram are often minuscule. Openwrt 22.03 is supposed on devices with as little as 8 MB storage and 64 MB ram (that’s megabytes, not gigabytes. The minimum requirements will be going up for future versions, but even still, openwrt occupies much of that storage and ram just for the base os. A pi4, by contrast has up to 8gb ram, and often is used with memory cards of 16 GB or larger.
Well, if you're talking about actual usable "ram" in the typical sense, you're probalby looking at devices with 256MB RAM. IIRC, OpenWrt splits the ram in half... one half is used for /tmp (i.e. a RAM disk), the other half is normal functional RAM. Only more recent or premium devices will have 128-256MB RAM.
Sure... again, you're targeting a subset of routers at this point (but you already were based on the RAM)... obviously more and more of the routers these days do include USB ports (or SD card readers).
But how much memory (both storage and RAM) would it require to actually get the API running when you include the core API and all of the dependencies? And then how much would each job need? Have you researched this?
Not sure what you're really getting at here...
but... are you in a position to say how much RAM and storage would be required to get the basic API running such that a hello world program could be executed?
I am not. But I will assume your system allocates all available memory for itself so nothing else can run on the side. And all additional packages available are just for the sake of testing the make toolchain. I may try to replicate via RCS instead of git. Just for a little taste of the old days.
Or applications running on our devices providing day to day non essential services. With helpers. Also non registered VoIP calls. And we trust business even after the discovery. Who knows where we may end up to.