Althea Development Update #60: Teaching people to setup real gear

Althea founding team in front of the off grid tower

Globetrotting and training

This update is coming a little late; it’s been a travel filled couple of weeks.

We held Altheapalooza, a small conference in Portland featuring the Althea team and Graham from startyourownisp.com.

I also presented at the Nashville Blockchain Developers meetup

The goal of Altheapalooza was to create video content about every detail of setting up an Althea network, from antenna selection to spectrum planning. This is also our first experience trying to teach all of this in a more formal setting rather than ad-hoc lessons in the field.

This was a great opportunity to get the team together, visit the network in Clatskanie and start to tackle one of the fundamental challenges of setting up an Althea network, can we effectively train people to setup real world wireless gear?

Where on the sliding scale of a two day in person course all the way down to a 15 minute video clip do we need to be?

Althea can automate every other part of the process, but point to point wireless gear is the only way to provide incumbent ISP competitive (and often superior) performance at a low cost. We need to be very effective at teaching people to use it.

We’ll let you know how this experiment progresses and once the videos of Altheapalooza are ready.

Visiting the tower in town, it’s not even fully extended yet!

Update on bandwidth payment experiments

As expected once we started paying close attention to bandwidth payment amounts we found a few bugs. Now fixed in Alpha 11, rolling out over the next few days.

What’s New in Alpha 11

• Separate default WiFi names to prevent issues with client devices being dumb about frequency selection
• New logarithm based route selection weighting prevents realistic prices (hundreds of thousands of Wei per byte) from causing routing issues
• Tools in Rita for price setting and quality adjustment, updated to work with more realistic price values
• Fixes to client and exit billing to properly account for nat traffic
• Crash watchdog for Rita should restart Rita on crash automatically
• more robust automated update script to handle some common failures we’ve seen

Our next major step is to figure out how to very prominently show people info about how much they are spending. People we’ve talked to so far are universally confused about how much data they use and the lack of certainty is a problem.

What we’re trying right now is presenting them with weekly or daily updates on their usage and integrating this info into the front page of the Althea router dashboard.

Technical progress update

Network DAO Payments

As you may have noticed Aragon is live on mainnet, this changes our previous timeline. Which involved figuring out how to deploy Aragon ourselves.

Right now we’re working on pretty minor integration issues, trying to get our Network DAO app and it’s assets to show up on the Aragon web interface. We have contacts on the Aragon team helping us out.

1. Aragon deployed on mainnet
2. Possible to install the Althea app into an official Aragon DAO
3. Althea Network DAO app shows assets and is generally usable < =
4. Billing integration with the rest of the router functions, to provide more seamless payment.

After 3 the DAO is usable, if clunky, so we’re getting really close.

Bandwidth Payments

The past few weeks have been spent almost entirely on specification. As we started to try and integrate accounting and billing we found that the process was simply too complicated to work without making precise specifications for each component.

We’ve finished specifying channel flow, documenting various operation details and coming to an agreement on how all the components should work. Leaving us back where we ‘started’ 3 weeks ago, hopefully ready to really finish the integration this time.

1. Create light client that works on routers and embedded devices.
2. Create a bidirectional payment channel and deploy it.
3. Integrate the light client and existing billing code.
4. Integrate the #3 with the payment channel.
5. Spec out channel flow in detail < = forgot to do this
6. Integrate billing code with existing accounting code. < = back here now
7. Comprehensively test this entire stack.