We created Clarity a minimalist ultra-lightweight Ethereum transaction generation library that can run on any device powerful enough to reasonably sign translations.
In parallel to bandwidth payments our local network DAO’s should be ready to collect payments very soon. Since we are using Aragon as a framework for storing the money it’s mostly audited already. Which should dramatically reduce our time to payments with real money.
Our latest release contains only minor networking fixes, at this point networking is stable enough that we will need an order of magnitude more users to really start running into new bugs.
Two of our own will be traveling to Colombia next week to help setup our first South American deployment.
Our goals right now are essentially payments and documentation ASAP.
We have new networks which will quadruple our number of active users in the next few weeks but without some form of real money billing these are all experiments. Not decentralized businesses.
We’re focusing on getting Network DAO payments online and integrated with Aragon. Not only is this simpler than bandwidth payments technically since the heavy lifting has already been done for us. But it’s also better suited to bootstrapping a network. Where bandwidth payments may start very small anyways.
The other side of this problem is that unless you know how to poke around github repos or talk to us how to get started with Althea is a difficult thing to figure out. Like I said in my last update we’re really riding on our website refresh to achieve that.
After significant research we found that the Parity Ethereum client is simply inappropriate for embedded environments. This left us in the awkward position of having to furnish our own lightweight transaction generation library.
After a detour of a couple of weeks Clarity is capable sending functional transactions from a variety of environments. Most importantly for us is support for the MIPS CPU architecture which is very popular in routers for it’s ease of manufacture and low cost.
There still needs to be some work done on documentation and sending transactions to contracts specifically, but I’m very happy with the progress.
Althea is transmission medium agnostic, meaning no matter what connections it is provided it will make the best use of them possible.
A connection that’s always been less useful than people seem to expect is meshing using internal omnidirectional radios. In general Althea deployments focus on high performance point to point antennas and leave the internal router radios to normal ‘home router’ tasks. Mainly home wifi.
It’s possible to use a internal wifi card for meshing with AdHoc mode but only if you give up on using it for your own Home wifi. Giving up either home radio sucks, routers obviously provide both frequencies because both are useful.
Earlier this week I decided to investigate MeshPoint (802.11s) a WiFi standard that attempts to codify those ‘whole home wifi’ setups for connection sharing by creating a group network that many access points can join and connect over.
This is of course perfect for Althea, which simply sees yet another connection to make use of.
The real surprise is that careful inspection of the driver capabilities using the iw tool reveal that with 802.11s we can have our cake and eat it to. By sharing the same device for multiple access points we can provide connectivity without sacrificing user radio functionality. At least on devices that have up to date WiFi hardware.
It remains to be seen if the contention of running two networks on a single WiFi card causes problems.
I’m very happy to say that since our last update we’ve had about 8 devices be put into real world use without any of the failures/crashes…
Last update we created a ‘stable’ release channel and rolled out our latest and greatest to the 7 devices we had in production.