Substratum Dev Team Show & Tell —7-Jun-19

Show & Tell weekly sessions are an excellent insight into the challenges and triumphs facing the Substratum development team. Each week a set of slides is released and a group conference is held with dialogue and examples of work completed, tabled and planned on the horizon!

This week revealed completed work on an exciting critical component for monetization — the integration of wallets securely into Node (with mnemonic phrases)

B.J. Allmon lead developer begins the meeting, as always, outlining the Strategic Goals of v1.0.0 Substratum Node:

Priority 1 — Make the Internet Free (as in Freedom) and Fair

Priority 2 — Earn Cryptocurrency. Change the World

Tactical Focus Items are outlined listed and briefly mentioned as Work-In-Progress

B.J. mentioned specifically that work has just started on node encryption in the last week or so, which is extremely important for a secure testnet and ultimately the first Release Candidate (RC1).

Also clarified at this point, was that before a ‘Version 1’ (v1) is finally released, team and community have to run the Release Candidates on testnets and identify things that are not on the planned scope, including defects, bugs and hardening.

Storymapping for Substratum Host has just begun, which is reliant on Node to even be possible.

Normally the ‘Show and Tell’ segment takes up the bulk of each weekly meeting, but this is the sparsest slide we have seen since these meetings have been broadcast!

The mnemonic phrase item actually took several weeks to finally finish — which is basically integrating how wallets will be connected into Node itself, both for earning and consuming by users.

But this goes to show how difficult the items are right now that need to be completed.

Outlined below are the two major items to digest this week!

Stop sending useless intros via Gossip — Dan Wiebe:

This card was identified by testers last week, and was moved forward because the issue itself could create further problems in future node-network building. When Node itself sends intro or passing Gossip (basically the function that says — “Hey Node B — contact this new Node C!”), the code has not been checking whether the new node was already known to the others.

This completed card now provisions that there should never be a node that has less than 2 neighbors (unless there is a true network problem)

This wasn’t prioritized for RC1, but since the testing community saw the issues this was creating, the team prioritized this to fix this.

SHOW — Generate BIP39 master seed demo — Steve Swing:

Steve demonstrated on screen the new functions integrated with blockchain wallets.

This can be considered one of the most critical and exciting components as this is the true core of monetization! — without it there is no way to earn and pay SUB tokens!

This card dealt with coding a number of command line (CLI) parameters, and allowing users to integrate wallets into the Node software.

The component is designed to allow both Hardware (think Ledger or Trezor) and Software based wallets (think Metamask or online MyEtherWallet) to be used while running a Node.

The code itself allows a BIP39 mnemonic phrase to be input, or to even generate a new mnemonic phrase from within the code (which is used to produce unique public wallet addresses).

The Testnet (Ropsten on ETH) will default to a 12 word-count for the mnemonic phrases, so it compatible with wallets like Metamask.

Mainnet will default to 24 word phrases.

“We knew early it would be a tough week.” — BJ

For the first time in 10 weeks, the forecasted weeks counter did not reduce.

It remains at 4 weeks.

The remaining cards are very tough and are complex — but the challenge also relates to the few number of cards left to work with.

Again this is a moving target!

All work was on the 2 ‘Planned’ cards this week, hence the 100% utilization in green.

There has been talk around the community about why the team seems focused on building all the components on the command line.

B.J. reinforced that these features are the underpinning functionality, so the GUI can even be built. So it has to be strategic, and have core features in place for Node on the system code side.

The team still very much cares about user friendliness and GUI development!

Now, the UI features can be built up including creating and selecting an earning/consuming wallet, user settings and more.

Overall it was an interesting week. B.J. did sound a little frustrated about week countdown remaining the same, but simultaneously proud that this has not happened in 10 weeks with the development! The critical component of the wallet integration, and parallel development with the blockchain services and referencing, really shows that monetization is being fleshed out successfully. It sounds like in the coming week a minor release could be expected, along with more work on encryption and blockchain integration.

Stay tuned for another week with the Substratum Developers!

For those who want more technical insight, I tried to capture some of the Guest Open Space chatter that was really interesting. If you don’t want to ‘geek out’, you can stop reading here!

If you don’t want to ‘geek out’, you can stop reading here!

Guest Questions/Comments during meeting (paraphrased!):

Steve: We have cards so that the GUI has the interface to prompt and recover the mnemonic phrases and generate them.

If you feel comfortable with your current wallet, you can import your recovery phrase you initialized your HD wallet with, into the node software and keep your SUB where it is to use in Node.

We (Node or dev team) don’t save your mnemonic phrase — We encrypt the resulting mnemonic seed produced by the phrase and your mnemonic passphrase (25th word if you have this)

Right now its fake encryption, so don’t use a real wallet yet if you are testing.

We will have an area where your initialized wallet is displayed in the future GUI

Brian: Couple things — great job on the critical fixes!

Have you upgraded to rust 1.35?

Steve: I think we are upgraded for the current builds

Brian: Are Port specifications in the UI?

The use-case is quite important, as users don’t want to open all the range of ports and use DMZ.

If I launch the UI, and it picks a port outside the range, it may not be able to do a full handshake into the network.

Port needs to be opened before initializing node

(so it’s almost a chicken vs egg dilemma)

Dan: Router should be able to be fully closed, and the entire handshake should work after you open the required port. If that is not the case, then we need to test for that.

Steve: if you are on a new machine that’s never used Node before, you can provide the clandestine port parameter in CLI, configure the script to use open port

Dan: it’s not in the UI now. But what might help you if you have used Node on CLI, it will have chosen a random port and stored it in the .db file. It will still use that port in future initializing every time Node is run. (unless you delete the database)

Brian: the challenge is we are rebuilding things frequently and having to wipe the .db file frequently when testing

BJ: no card yet for UI port assignment, but we will create one

Justin (developer): HTTPS traffic was not flowing through node. Routing was becoming sporadic. It was pulling different exit nodes — right now some HTTPS won’t work for TLS sessions (handshake). Team is fixing that, but it is a major challenge right now

BJ: Thing developers have noticed the most with current coding — ‘the fix is easy’ but ‘testing the fix’ is extremely difficult.

BJ made a NEW WORD! ‘Craftspersonship’ ?

Brian: Relating to HTTPS/TLS issues, thank you to Dan for writing up an explanation on how this should be working.

The current panics in testing community now are placeholder as some features aren’t implemented yet.

BJ: Panics are a problem, but we need to fix it. One is the blockchain url parameter not being specified.

Dan: Some issues still remain when blockchain url parameter isn’t provided. Even if you are serving-only, Node still will have to access blockchain services to verify blockchain info on your behalf. Blockchain info may be censored in your area, so the node network is leveraged to provide block info for payment verification etc.

NOTE: this is actually an aspect where users can earn more if their node is needed to fetch blockchain service data for other nodes who cannot access it, haven’t set it up in Node, or are restricted from those services in their country!

This is an aspect where your node may need to consume even though it is set to serving-only the network.

Steve: we need to explain — if you are serving-only and don’t have access to the blockchain data, you are trusting that other nodes have SUB to pay the services you are providing — if you can’t access blockchain, then you cannot verify if people can pay!

We don’t want that problem to exist! So we are writing the app so Node will have access one way or another.

If you don’t supply the URL it will check in time intervals due to blockchain API — we will design so it won’t crash/panic the node.

Andreas: A small request regarding public IPs — can Node recognize a node that may have a new or updated public IP, after it has already connected to the network?

Dan: Technically, the way Node is written now, it may not be necessary for Public IP to be a parameter. But we haven’t gotten around to addressing the fact that dynamic IP addresses will change and Node won’t adapt to this at this time.

Andreas: One idea to make it simpler — one solution some software have is to provide a DNS Entry instead of a static IP, so if we can just provide a DNS name for us, it can maybe be updated. But would need to write the code to update the database on the network

Steve: remember that the SQL database is not storing any data, just who and what you owe.

Dan: it also stores the port tables of delinquency, who owes what, and only stores wallet address. Not private keys.

Now stored in memory — there is hashmap of neighbourhood directory, IP addresses, neighbour lists, earning wallet addresses and a bunch of stuff about nodes, also that’s where we make the routes from.

When node goes down, that all goes away. Its ephemeral.

BJ: it was very intentional. All data we handle, we want to handle it with care. We want it to go away if a computer is stolen etc. What data we store is more ‘safe’ for storage from a safety perspective.

BJ: one thing tester noticed also, is that there is a performance boost by log filtering, and using log_level info instead of debug.

Disclaimer: I am not an official Substratum team member, just a community supporter. This write-up is interpretation of the Show & Tell meeting and data released from the team. None of this is to be taken or construed as investment-related or as financial advice.