The project met the exact same end its predecessor (the PirateBox) did, and for pretty much the same reason. However, the project is quite old, and the focus on reflashing portable routers was a necessity then, but not so anymore - specifically, PirateBox (2011) actually predates the first Raspberry Pi (2012), and especially the first Pi with an onboard Wi-Fi (2016).
I'm just wondering, why hasn't a SBC-based alternative popped up yet? I think the project is/was awesome, I actually did maintain 2 public PirateBoxen for a while. Is it a simple lack of interest? The fact LibraryBox tried to pick up after PirateBox kind of suggests otherwise. I feel like it's actually easier now than ever to build a Libary/PirateBox-like project (although I do imagine an on-board network card probably has way worse performance than even those old portable routers).
I've even tried to put together an image like that in the past but I couldn't find a reproducible solution for creating raspi images so that put me off, maybe it's time to give it another try...
The main problem with these projects - which was not much of an issue when the projects started - is that mobile phones of today seek access to web servers at vendors, including the OS source and possibly others such as the phone manufacturer and ISP. The phones balk if they don't connect to those servers. PirateBox and LibraryBox are not just captive portals to Internet connections, they are local content and app servers and don't need the Internet.
So when you connect to a Box via Wi-Fi your phone demands to connect to Internet hosts even though this is unnecessary for this use case. This behavior is confusing to the user. Some early solutions involved trying to spoof Apple servers for example, but the names and IPs of these servers kept changing and this kluge became ineffective.
The only solution I am aware of is to pre-inform users of a local IP address to browse to once their Wi-Fi is connected to the Box. But depending on the occasion and venue, getting such instructions to the audience and having them follow it, can be its own problem.
You can setup DNS on the box to redirect users and to give a friendly name to your box. That's what we do for butter box (https://likebutter.app/box/). To make it a step easier, we provide a QR code. But even that is a little clumsy since you must first connect to WiFi, then scan the code.
Captive portals sound nice until you find out how limited they are -- a lot of styling, JS and browser features are simply unavailable. So, you need to tell users "Close this, then go open this site in your real browser"...
Of course, you can't and probably don't want to redirect HTTPS traffic since you don't have the matching cert for e.g. https://google.com
I actually have a "MonsterOTG" portable WAP. https://www.youtube.com/watch?v=THnT-rWFnE8 ...their pitch was "put your kids movies on an SD card and they can navigate to them from their iPad (on a road-trip)"... or have all the media on one SD-card and not have to have them on all your phones (like a proto-NAS, kindof).
I used it actually while on a trip to "fake" being a web-server. eg: `scp index.html 10.1.10.1:/media/files/public` (or whatever) and then I could have my phone navigate to it. Chromebook => "OTG-Wifi" && Phone => "OTG-Wifi". Chrombook.push(); Phone.fetch(...);
I couldn't connect directly from phone to chromebook, but if they were both on the same (captive) wifi, I could actually have the phone navigate to the server running on the chromebook via that little device as a "wifi mediator" (even while in the middle of nowhere with no internet for 50 miles around). I had some episodes of Twilight Zone that I'd ripped and could connect to it while on a flight. You could take the SD-Card out of your camera and fetch pictures over to the macbook-without-sd-card situation, then clear the card and take more pics (or keep them on and just be guaranteed that you have a backup).
There's really some non-pirate use cases of things like that, and the overall concept is pretty cool! Got me thinking of something like a neighborhood "Captive SSID", like a LAN that you opt in to vs the WAN that's always connected. It's really instructive to think through for yourself personally: if you were on the moon, and all you had was a wifi access point that held SD-Cards
> when you connect to a Box via Wi-Fi your phone demands to connect to Internet hosts
I don't follow: When my phone connects to a wlan, it will try to connect to the Internet, and if the phone can't do that then the phone won't function on the wlan?
> The only solution I am aware of is to pre-inform users of a local IP address to browse to once their Wi-Fi is connected to the Box.
What is the response from this local IP address that solves the problem above?
The goal was to make LibraryBox, but with just a little more frontend and a little more flexibility. It had a lot of the earliest things: Simple wifi support, and was built to enable you to add services like Gopher, maybe Gemini, IRC, etc.
In the end, there was not quite enough interest. Jason moved up in the ranks of the then Berkman Kline center, 2018 became a very touchy time for things.
You can easily run Alexandria, which at its core is a very basic directory browser, the admin panel can be turned off. I wanted to add the ability to upload & expand archives of files, but couldn't find a good way to do that at the time.
Butter Box (https://likebutter.app/box/) and Internet In a Box are two modern descendants of the concept. Both run on RPis (and, nominally, some other hardware).
Putting together the images isn't terribly difficult. For Butter Box, we just run a script to install all the things we want, then make an .iso of that, which we distribute on our site and in hardware form.
Those onboard network cards are indeed a problem. You can get single-digit # of simultaneous users. But other than that, they tend to be very fast for large files since you're not going out over the Internet and can saturate the WiFi connection.
Thanks for situating this in history! It's easy for people to look at the project and be like "why no RPi?" without understanding that when LibraryBox started, Raspberry Pi's didn't have onboard wifi, and the travel routers we chose to support were SIGNIFICANTLY less expensive as well. We're in a very different hardware world now.
> LibraryBox is sadly no longer under development. A combination of hardware/firmware lockdown made the continuation of the project's goals untenable.
I've been worried for the last few years that this kind of lockdown is going to be the end of open source OSs for the masses.
Right now we have secure boot, and it's feasible but a pain to work around it to, say, install Ubuntu on a Dell XPS. But the next step after that is, "no, you can't disable secure boot. That would be insecure."
There's a lot of hardware out there that is available though isn't there?
Arduinos, Raspberry Pi ?
Maybe not ideal for this situation, but still available, with lots of handy extra hardware rather than relying on repurposing some other hardware not at all meant to be used in this way.
That's great for hobbyists and tinkerers, but when Joe Schmoe off the street thinks, "man, I sure am tired of the full screen unskippable ads in Windows 15", he's not going to follow that up with "I guess I'll go buy a low power hobbyist board to tinker with an alternate OS for nerds". Whereas today you can still just install Linux on the same laptop you're already using, and sometimes even Joe Schmoe off the street does just that.
It's kind of already there. When I search for "hardware computer without secureboot", the first two pages is "how to install w11 without TPM". We're not even talking about linux.
ButterBox is a semi-spiritual successor to LibraryBox for RPis and similar hardware, and built in collab with the F-Droid project, to provide off-grid app store access (as well as chat, and general file service):
I have an open-source project that is similar to this. Its purpose is to allow easy creation of an off-grid digital library. It can automatically download videos, archive web pages, PDFs, etc. It has a global search which searches all your files, as well as any Zim files you have downloaded (Wikipedia, etc). It also uses OpenStreetMap to display a map which renders the map tiles offline.
We build Butter Box, a tool for making life offline a bit smoother.
It's based on this same principles and in fact, one of the creators is friends with Jason :-)
Ours is tailored for scenarios where Internet is unavailable due to disaster, government shutdown or simply cost. It has an app store, an encrypted (matrix) chat server with a simple web UI, and maps (since you probably didn't download google maps for you area before the Internet went out).
We localize the boxes (mostly for central and south america) and have sent a few dozen around the world to communities with various use cases.
FWIW: one of the other main issues with the project as it neared its end was the move to mandatory SSL connections. By its nature, LibraryBox has to be able to work entirely offline, and trying to sort out how to manage SSL connections in that situation without also causing potential security issues in sensitive use situations...well, we tried and couldn't come up with a reasonable, usable solution to those overlapping issues.
100%. This is something we are trying to solve with Butter Box (https://likebutter.app/box/) but there aren't great answers.
I've considered shipping a unique-to-device certificate for e.g. box123.comolamantequilla.com with each box. It doesn't solve the evil maid scenario of someone copying it, but it at least provides TLS. Realistically, our users are offline and mostly not going to verify that comolamantequilla is owned by the organization they're intending to trust.
So how does it work form a user's POV? I connect to the network and then get a "sign-in" like screen that lists all the files on the device? Or does it route all requests to the local server? Can you make this airdrop compatible?
Why can’t I get the same thing with an external USB drive? Bear with me a moment - what does LibraryBox do that’s better than flat file storage? Multiple connections? (Does it do caching as a way of ingesting new content for offline viewing?)
Security is a big one. No way I'm plugging into some random public USB outlet. Aside from that, I believe they were indeed intended to serve multiple people at once... encampments, communities, short term installations, etc.
Afaik, a random WiFi wouldn't be able to exploit local-execution bugs - it would have to use remote exploits, which are harder to pull off, or limit itself to network eavesdropping. USB drives, on the other hand, can trigger execution with local privileges - as well as exploiting bugs in hardware-handling system code, of which there are always plenty.
> Almost any computing device on a network can share files this way, with a bit of configuration.
LibraryBox is designed to be a deployable appliance that works where no network exists that's configurable by non-technical people. Nobody even intimated it was a novel technical approach to physically transferring data. You could pick any method of transferring data and say, "well why didn't they just use [method]?" I suspect you're just hunting for opportunities to make critical comments.
Modern network interfaces are safer even in a default config without a local firewall enabled. Not even windows has SMB or the like enabled by default anymore. Theres a lot different sorts of USB devices that thing could pretend to be.
At one point there was a sort of "starter" content set that was made up of CC or public domain works that was distributed by the community as a torrent. But the project itself was always about the hardware/infrastructure aspect, not the content itself.
It would be a better user experience in a coffee shop to just have a media server on the network. People are already likely connected to your wifi for internet. Setup a local domain and post QR codes for it.
As soon as music is involved, ASCAP will come a-knockin' in the US at least. They're legally pugnacious even when they're in the wrong knowing that bar/restaurant/coffee shop/store owners don't have the resources to fight them.
I'm sure I have had routers that you could plug a USB drive into and browse the contents from any device connected to the Wi-Fi. And couldn't you do this with pretty much any random Wi-Fi capable laptop?
I am a techno-skeptic most of the time, but I don't think this idea is particularly crazy. Usability-wise, something you can talk to (in your own "low resource" language) is a winner.
The catch is that you have users without either the sophistication to size up how trustworthy this model is or to do out-of-band verification (remember: no internet). I think a RAG model serving answers from Wikipedia could be suitably safe, but we'd have to do some user research to know more.
A future version of an ebook library would be an offline large language model? So like, instead of downloading Moby Dick, you can ask for it to be generated?
There is definitely interest in providing off-grid communities easy access to lightweight LLMs... one idea is to use something like: https://github.com/mlc-ai/web-llm to deliver it in a browser
Yeah, to clarify, I didn't mean it would be a direct replacement for literature, just that on the same theme of of providing a resource in places where connectivity is an issue, an LLM is a reasonable way to compress a whole lot of human knowledge into a relatively small space in a usable form.
I'm just wondering, why hasn't a SBC-based alternative popped up yet? I think the project is/was awesome, I actually did maintain 2 public PirateBoxen for a while. Is it a simple lack of interest? The fact LibraryBox tried to pick up after PirateBox kind of suggests otherwise. I feel like it's actually easier now than ever to build a Libary/PirateBox-like project (although I do imagine an on-board network card probably has way worse performance than even those old portable routers).
I've even tried to put together an image like that in the past but I couldn't find a reproducible solution for creating raspi images so that put me off, maybe it's time to give it another try...