An incremental update this week as we edge towards Wave 2. So not much new to report, just general improvements to key apps, testing and the back end. The long delay experienced on resetting Autonomi Node Launchpad and safenode-manager should be things of the past now. Replication has been tightened up to be less wasteful, we’re looking at reducing node bandwidth, and we’ve moved on to a new version of the DiscordBot ahead of Wave 2.
So lots going on, but not too much to see on the pitch this week (a familiar picture for fans of Scotland, England, France, Italy, Serbia…). Down in the dugout, though, it’s heads down and pencils out as we make fine adjustments and strategise for the next stage. Probably best end the 
analogy there.
Big shout out to @riddim, @neo, @mendrit and everyone else who has been helping people out over on Discord. Thanks for all your efforts guys.
A quick word from @roland for advanced users and devs who want to monitor the health of individual nodes. Rather than scraping the logs directly, you can use the metrics service for this.
Users of safenode-manager can monitor specific nodes by setting --enable-metrics-server during the add command and specifying the port or port range, e.g. --metrics-port 12000-12004, during the add process. You can then monitor the metrics from that port at, for example, http://127.0.0.1:12000/metrics. This feature is also enabled in the Launchpad by default, but you will have to scrape the logs to obtain the URL as you cannot manually set the ports. Look for something like this: ...INFO sn_networking::metrics_service] Metrics server on http://127.0.0.1:12000/metrics]
Performing GET on this URL ( http://127.0.0.1:12000/metrics) will return the node’s metrics in the OpenMetrics format. There are various clients that can parse and analyse this data, which can be used to build a dashboard.
General progress
@jimcollinson has been working on the coordination of an upcoming Network update, which should 
land early next week. It’ll require a reset of nodes, as we bounce over to an upgraded network. There are quite a few moving parts with this one (so thanks for bearing with us!) but the good news is the transition should be smooth, with little impact to the rewards program, and should improve performance all round!
@bochaco is back after a sabbatical, and he’s got straight to work debugging the self-encryption of small files.
@bzee has been tightening up spend edge cases, testing out scenarios where nodes don’t act as we expect them to. And to aid in all such endeavours, @shu has been steadily improving our dashboards and metrics so we can better see what’s running where.
@chriso has reworked the node registry refresh, which should hopefully fix issues with the node manager and launchpad hanging for long periods of time while refreshing the registry. Basically the refresh process was very slow. In tests it is now super-quick and working well with Linux and Windows. He has also rejigged the status command, which was similarly sluggish.
@joshuef has mostly been working on our internal alpha testing network. He’s also found some problems with the uploader clients, which were running out of space and having problems with wallets stalling.
Digging into that issue, @qi_ma raised a PR to identify and restore such wallets. He also investigated the high traffic we’ve observed over recent testnets. This is non-fatal but suboptimal and slightly mysterious. Qi raised another PR as a first attempt at traffic taming, reducing the frequency of identification communications and avoiding excessive replication.
Over in Discordville, @mazzi deployed a new version of the DiscordBot to improve performance, logging and error handling. We now have a service that grabs the information from the audit service hourly and saves the information into a database. He continued to work on supporting multiple DAGs on the snapshot collector, which is how we are building the leaderboard and rankings.
Meanwhile, @roland raised a PR to display version strings in the Launchpad, and also added some important tests for valid spends.
to script a test page which uploads to a network (local or public) and allows me to check the behaviour is as expected for page navigation and loading resources into pages using different custom protocols, with and without versioning. All that could pass did pass first time which was quite a surprise. 
