I wonder what the smallest viable, most useful, design would be.
Maybe just a pendrive plus an appropriate cable so that the smartphone can read the pendrive, copy from “/pen” to “/phone” and back as appropriate? Just give those cables to everybody? Say “Micro-USB B” (which is male) to “Micro-USB A-type Female”. http://www.cablestogo.com/learning/connector-guides/usb
Within /phone, locals would have a “questions.txt” (or maybe a “thislocation-q.txt”) to request further files. Etc?
As @trythis has suggested, maybe start very small, with say one village and one “central” entity. (I have a problem with “central”. I work in flu surveillance and we epidemiologists consider ourselves central, when in real life what’s central is the patient and her helper, without whom we wouldn’t even exist. Anyway.)
I like the direction you are thinking - but I am afraid most phones can only be a USB-client, they cannot necessarily host other USB-devices (e.g. pen drives) - even if they can be connected with a cable.
You could leave to cable away entirely though and do transmission via bluetooth.
The other thing is that I would believe it would make sense to break it up into smaller packages that cover specific areas of interest. Of course you would always have a basic package (and a local package) that would need some serious curating though. If you use plain vanilla file sharing methods such as bluetooth and built in file managers you’d be pretty restricted in terms of elegant updating and file preferences/selection methods, but that is a tradeoff that may be acceptable in certain circumstances.
Re “central”: I think what you are trying to say is: one highly connected, and one pretty isolated. When I said 5-6 villages, what I had in mind was the 5 you know from rolling dice. Perhaps with one arm extended by one village (making it 6) to see if that changes what is happening along that arm.
Re starting small: One could also consider applying this to the library itself. If we dilute the effective quality of information by (info overload) quantity - that may work against us if we don’t have a very effective interface.
Some phones have a USB master mode, but not all (as trythis mentioned), and for some of those having it it needs rooting (“jailbreaking”) the phone to activate it. But I like the local syncing idea because it’s so simple. It will only need a piece of electronics that (1) accepts a USB stick as USB client, (2) accepts the phone as USB client and (3) accepts instructions from an app on the phone to copy certain files between these two USB mass storage devices. It will even be faster than via wifi. A Raspberry Pi could do that (it saves the $$ for the wifi module and lowers the power requirements). But I am sure we can find simpler and cheaper devices which can also do this, since it’s a pretty simple task. If @trythis knows the simplest solution, I’m sure he’ll let us know
Some more ideas that piled up in the last days for gradually connecting these library servers to multi-village intranets and finally to the Internet:
Connecting villages together with DIY data links. Appropriate tech could be for example the Village Telco kits, the APRS-IS packet radio network, the Guifi DIY long-range wifi network technology, or visible light data connections with cheap laser diodes (which is licence-free electromagnetic spectrum, so everyone can play with it …). Obviously, laser diode connections require line of sight between two villages each, but that is a given in Nepal's hilly region. These connections can easily go from village to village until reaching the next city with "real" Internet access.
Maybe winged drones (or even turtles) could deliver the USB sticks in a delay-tolerant network? :-)
This whole idea could very well also become a civil society dialogue space (with a slow but rich dialogue) in rural areas, according to Natalia's comment.
Sorry, but I don’t think I know the simplest method. You’d have to take into account at what level you want to do all the stuff (protocol used). Some pretty basic FPGA may be enough to do this - but I wouldn’t know where to look for one that does it “out of the box”. And I’d be even more lost to re-configure one to do what is needed. You could probably find some ASIC / ASSP that does what you need pretty easily. The only thing is that then you’d be stuck with that method and could not adapt to changing needs (not very resilient/long term).
I tried to find something based on the wiki leads, but my most of the stuff looks like it was mothballed 5 years ago. This one, or this one looked like it may be useful. Here is a decent overview of some players (also seems alive) and considerations. Here is bytewalla from KTH. Mentioned also in this question. The French seem to be busy as well with CASA, which seems to fit our needs fairly well - app here, take some time and browse their site. Berkeley is getting its hands dirty too :). MIT runs some money numbers on DakNet (there’s also slides). ION may be over the top but it is active and seems to be working nicely (where it can be implemented). Here’s a relaxed video that may give additional impulses - but I haven’t scanned it yet. Here is 95pp that’ll hopefully help with an up-to-date overview in this field.
Wow guys, this is super-interesting but honestly beyond me. Example: I checked out guifi, but could not find a beginner’s guide to the technology that would help me to describe it to someone else (this is not specific enough).
Are you aware of a high-level description of DIY telco options “for dummies”? How do I start to build the language and the basic knowledge to even have a discussion with you?
To be honest I start to “swim” in many of the documents as well. I think the high level description is would start with “the bush drum and morse code” and very quickly gets extremely complicated and full of acronyms. You can transmit and store info in many, many different ways of course. A few core concepts are a/synchronous, bandwidth, latency, proxy servers/relay stations, and of course the protocol, and architecture (or topology). The last term is often important in our context as we generally like 2p2 (peer to peer, everyone on eye level). Funny enough the military side prefers a similar architecture (because it is robust/resilient) but they often call this net-centric - and don’t like to share as much. Because this would make things much too simple, the market decided to bring in intellectual property (patent) considerations - and made it crazy beyond belief in one swift stroke.
As transmission and storage technologies became much more powerful recently, we can basically start our own small telcos and have started to do that. As we can’t or don’t want to take the “commercial (patented) solution” we’ve started to make you own protocols (standards) for the applications (using the hardware) we care about. However, as these are not all the same or compatible - things get a little bit complicated. That’s part of why I try to avoid digital technology - I’ve been exposed to this crazy world for decades - and you can never lean back and say: “Ah, now I understand it all.” Because in a couple of years much of this will be outdated.
Tried to find a good intro, but documentation does not seem to be their strong side (the Wikipedia page has some stuff though). Rough explanation of their technology: it’s a network where each participant owns and operates a so-called “node”, which is a device in the network that has one uplink connection to another node (and from there to other nodes etc. and then to the Internet), and zero or more incoming connections, using this node as uplink. Nearly all their nodes are wireless network devices … using the same technology as wifi in your computer and phone (the standard is called 802.11 something). The advantage of this is, it’s unlicenced spectrum: everyone can use it to transmit data without having to ask for special permission before. The difference to normal wifi at home is, they use directional antennas and other “better equipment” (and I assume, some protocol level tunings of timings etc.) so that they can easily cover 2-3 km of line-of-sight distance between two nodes. Don’t know much more about Guifi myself, but @Perulera does … she has installed some of the Guifi nodes
Depending on the capability to fix a wire, and the period of time considered – I’d probably would push wireless over wire, due to lack of moving (and vanishing) parts. Of course the “bigger hubs” would should have both …
Once the basic structure is fixed one could check if it is possible to turn this into a flyby library based on drones that navigate thermals (during the day) and mountain waves (esp. in Nepal). I already had begun sketching out a related project concept just to provide a platform for whatever. After seeing the weight/capability/power requirements of the open hardware one should be able to turn this into a flying library with directional antennas. Rare content would of course require a second pass - but this way it would be possible to serve very remote areas as well. Of course the challenge would be producing a specialized drone (swarm) that gets enough meteo info to be good enough to cover some areas better than googles balloon can. And be locally findable & fixable with a stick of hot glue for most of the crashes.
To connect rural Nepal to the digital world, it is always good to use what is there already. Which means, GSM mobile network for most of the villages. Data network over GSM is often not available (for reasons I’d really like to know). But GSM signals are transferred digitally, so this is calling for a kind of ingenious hack to route a data connection over a GSM voice connection. Of course an acoustic modem would work (at slow speeds at least), but since GSM is digital, there could be much better options It would still be slow, but the advantage is that the local knowledge servers could sync themselves during the night (when there’s little load on the phone network), and take their time for it. It might even work to get a special rate from the phone network operator for such long-lasting connections during night hours.
The same slow syncing over slow connections could be achieved with packet radio (AX.25 and similar) connections. Free spectrum, long range, inexpensive equipment. And again, during the night hours (and when applying spectrum sensing), not much interference with other users.
Morning, everyone - just a short update, from 120 entries we made it to the final 15 and on Wednesday will do the pitching. If we end up being three best ones, we get the money to make it happen! Fingers crossed, your input will be crucial to get the idea there;)
It’s a fantastic project, I am fully behind it. I even have a very small idea of my own to contribute, though you guys have probably already thought about it.
BTW: this project is, finally, crowdfunding material. Let’s see…
Hey, could you make some sort of document or folder available so we can see where this has already gone and give you more informed contributions?
Perhaps you could also mark up areas you would like to change/expand somehow but are a little stuck in. And areas you don’t want to change for reason that may a bit difficult to communicate in the little time available?
You can help us out here, by adding ideas or even already starting to shape a presentation format (slide by slide, some images, etc). @trythis, as you’re with us, I’m not worried about the result.
I’ll be busy on something else for now. I assume you have started fiddling on the slides anyway. If you get to a “final draft” status I can perhaps look over them once more. Feel free to msg me so it does not get delayed.
Public link to view the presentation slides. Nothing urgent, but if you’d have a look it will surely help us further The slides are really nothing fancy so far. (And honestly, I’m running outta energy and creativity for presentations at the moment …)
Welcome to also just edit the slides if you see something. I’ve given you edit permissions to that document. No need to ask before making changes, just create a slide copy and work on that if you’re unsure (since there’s no suggesting feature in Google Slides so far).
(the 