Hi everyone 👋 Happy Friday 😀

I have quite a long update for this week. As ever, there’s a lot happening at Edge HQ.

First up, the network bridge. The Web is 30 years old this month, the perfect milestone for the release of $EDGE and the opening of the network bridge. What the Web did for access to information, Edge is doing for wealth distribution from providing network services.

Our mission is to uphold the founding principles of the Web by democratising computational power. We want to give the ownership of the network to everyone that is connected to it, and to make them the beneficiaries of the revenue that comes from its use.

To this end, the opening of the network bridge will take place towards the end of this month (August, 2021).

This week the team has undertaken some refactoring work touching all of our apps so that a single interface handles all config, further streamlining this system.

Until now all network apps have included 'second-order' configurations, which means that we have some values hard-coded into our application binaries that are toggled based on a single config flag. There has also been some legacy reliance on "magic" configuration that isn't properly integrated with our configuration model. For example, EDGE_NETWORK=test will make apps connect to test.network services by setting 5-6 secondary values, while another will enable secure connections, even though it doesn't exist in our code. This is a result of Consul legacy code.

Sorting this out brings benefits including complete visibility of all config in a single location; 'flattened' config structure to remove indirection; the ability to read an envfile consistently; deprecating reliance on those 'magic' inputs; and removing unused values. The net effect is to improve engineering confidence around the network apps, as we now have complete clarity on all inputs, simpler workflows for local development and simpler build-deploy processes with clearer ownership of configuration (i.e. builders and runners must provide those values, with no assumptions made by the app code).

Long term, this is also a step towards being able to detach apps and services from specific networks and to be able to run a completely offline network, which will make it considerably easier to write/run tests and engineer experimental features.

Other updates include changes to Gateway to ensure that it now fails fast without a delayed panic when it can’t find a Stargate. Previously a missing Stargate would cause Gateway to attempt to recover, cycling over and over until it ran out of memory. Whilst we don’t expect this to have happened in production, mitigating against it is one less concern when identifying the cause of a CPU spike.