(a sort of 2020 retrospective and 2021 progress post)
We did not plan to spend most of our time this past year indoors…
…and yet we did.
And while indoors, progress was made.
In January of 2020, we partnered with a local prototyping engineer to produce an agricultural sensing system that would utilize the system for the base station and payment processing.
In February of 2020, when the pandemic began to shut down the country, and most funding potential dried up, our team made a personal financial investment into the original project, putting the agricultural application (among others) on hold, and dedicated the year to assessing and refining the underlying technology into something for more generalized non-personal technical use.
In the remainder of 2020, periods of intense development interspersed with periods of everyday use refined and focused the needs of a general computing interface, while making portability of data and hardware clearly necessary core foci.
In February of 2021, we tested our first real-world end-user application, a birth announcement website with per-group messages and a “wishes for baby” guestbook.
Since February, development has been almost entirely on paper and solar-powered hardware, as the working system supports most of our development needs for the moment, and funding the next major steps appear to be our next major hurdle.
The arrival of my family’s first human child is a fairly momentous occasion for me, personally – and it prompts me to look ahead, especially with this system I’ve been designing.
It’s one thing to have a solar-powered server hosting the development docs in a forest somewhere, and it’s a good thing to be efficient and environmentally conscious.
It’s an entirely different thing to intentionally benefit the end user, I’m looking deeper than just the abstract data-win of “less energy used per commit” or “powered entirely by sunlight”.
What are the dangers of putting automation in the hands of a user?
What does an intentionally anti-toxic system look like?
What does healthy interaction with a computer look like for a child? How can I protect my own child from the dangers of advertising, malware, and communication with internet denizens? How can I protect my child from corporate interests, content addiction, or gamified toxicity?
How can I develop now, so that in a year or three, I have a ‘safe’ toy to hand them for playing, tinkering, and their own modifications?
How can I give other people, especially my own child, the positive and empowering tech experience that I was privileged to have? How can I design the hardware so a childhood toy can become the tool of an adult professional regardless of chosen vocation? How can I pass on the ease of computer interaction gained through a lifetime of familiarity with technical systems, without requiring a technical background from a young person? How can I give my child a lifetime’s worth of consistency and reliability in the tech they’ll have the option to use?
I cannot answer these questions directly without research, so this system exists both as a functional re-implementation of my organic systems of automation, and as a project for research into user-centric design.
I’ve always communicated more readily with computers than with humans, and whether or not that knack is hereditary, I want my child to have a good experience.
That is ultimately why we have chosen to move forward to seek funding for full time development of this system, and that is why I will forgive myself for the compromises I make to see this system work the way it was intended.
For all the ones who are disadvantaged by technology.
For my child, and all the children like them.
That is what drives me towards the goals of this system.
Sometime in the late 1990s, after extensive salvaging of all available electronic scrap that I could beg, buy, borrow, or garbage-dive for convinced me that hardware dev without funding was functionally impossible for someone that people still perceived as being a child.
This led to the assembly of functional requirements & a parts list for modular augmented reality heads-up-display(s) using off-the-shelf parts.
Another part of the DarkPi project has fallen into place with the announcement of the Multipath TCP protocol for the Linux kernal.
The protocol allows the transfer of information over multiple connections. This will enable the DarkPi to do two things. First, it allows for better resource allocation. On a distributed network like that established between DarkPi nodes, network bandwidth is at a premium. Secondly, it will theoretically allow the end user’s connection to be split between multiple exit nodes, increasing the difficulty of tracking an end user.
I made a comment more than a month ago about how I had acquired a wifi dongle and would be testing the wifi capabilities of my Raspberry Pi. That didn’t exactly work out like I had planned.
The wifi adapter I obtained is the Linksys Compact Wireless-G USB Adapter with SpeedBooster (model number WUSB54GSC). While working through SirLagz’s tutorial on how to turn your Raspberry Pi into an access point, I ran into a few issues. Namely, the wifi adapter that I was (attempting) to use has some driver issues. I worked at it for a few hours, but didn’t make any significant progress. I’ve decided to not pursue this avenue, and instead purchase a long range wifi antenna of the sort I’ve mentioned in the past.
I’m not sure which one I’ll end up getting (although I’m leaning towards one of the UbiquitiWifistations), but when I decide I’ll post it here. I have a bit of cash from Christmas that I’ll be using, so while my budget isn’t large, it is larger than it was before.
In other news, I’ve run into a bit of tech that may both make the DarkPi more interesting and more feasible. It’s called “FreedomPop” (Forbes was running this article on it), and it’s a service that makes monthly internet (nearly) free. Put down a deposit, and you can get 500mb of 4g wireless access. Share that with others, and you can get free upgrades.
I haven’t tested it yet, but my thought is this: Instead of trying to make the DarkPi connect to the internet via any nearby open access points, why not use one of the USB dongles produced by FreedomPop? Ideally, each DarkPi would have one of these. A single DarkPi would be forced to directly connect to the internet through the dongle. But bill_mcgonigle mentioned in a comment on SlashDot that it might be possible to spread out the packets over all available connections. If this is possible, any request on a given node network could be distributed over a random number of nearby nodes, reducing both the bandwidth on any specific node, and protecting the anonymity of anyone on the network. I’m going to do a bit of digging to see if FreedomPop supports linux, or at least provides drivers usable on linux.
I ordered a Raspberry Pi a bit ago, and it arrived just this last week
After resolving an issue with networking (protip: make sure you use an undamaged CAT5 cable), I installed and tested a few utilities, and basically tried to see how much the hardware could take. Despite the fact that the Pi is only running at 800mhz (with 256mb of RAM) I was even able to briefly host a Minecraft server. The next step in the development process will be setting up and testing several different intrusion detection systems.
With the direction I’m taking this project, the GUI is not going to be used, so I am currently using something called Raspbian Server Edition 2.1 (RSE), which is a stripped down version of the Raspbian OS. The current version of RSE has an install size of just over 200mb.
The real gem, however, was the blog written by SirLagz, the maintainer of RSE, and specifically his post on how to turn your Raspberry Pi into an access point. While it’s not directly applicable to the current stage of development, once I start testing wireless hardware for the Pi, the walkthrough he provides will be a perfect starting point.