To get an idea of where we are in development, I figured it would make for a good first post the states of the application to make a summary of what can be done, and get a sense of what needs to be done next.
Here's the main screen for the application. On the left side we have the app drawer, which contains a list of folders for the invoice state. We start with the first state which is draft, which is the only place where the contents of the invoice can be edited.
The first thing that the user does is decide on a subject, and enter a contact to send to the user. In this case we are using the wsd user which is using the 192.168.1.125:3001 instance. We are sending the invoice to a hayashi user using a 192.168.1.125:3000 instance.
Once we have a contact selected, we then fill in the content of the invoice. To keep testing simple, we use one entry and short descriptions during development. We have a single entry labeled as "Description" which has a quatity of 1, with kg as the units, and a price of 1,000 Gwei.
For the purposes of testing, we figured that Gwei would make things easier. If we put the unit as ETH, it would make it easy to type in 1 or 10 ETH easily and run out of ETH, even if only using the test ETH provided by Ganache, or a testnet.
To provide the satsfaction of sending big-looking numbers, without actually using a lot of ETH, we decided to use Gwei as a unit for testing. And so far it's been fairly enjoyable to test this way. Once we have an invoice item to send, we can scroll down to the buttom of the invoice we we have two options.
The first option being Move to Trash, similar to mail where a draft is trashed without being sent. and Send Invoice. Once Send Invoice is clicked, right now this function exists over a standard web API. Our instance at 192.168.1.125:3001 sends an http request to 192.168.1.125:3000 with the contents of our invoice as JSON. The other instance will check to see if wsd from 192.168.1.125:3001 is in hayashi from 192.168.1.125:3000 list of contacts.
If the user contacts checkes out, then we check to see if the uuid for the invoice already exists. If there is a uuid collision then it's probably not a good thing, and the invoice will be rejected by the client. Otherwise the invoice will be received and stored as "sent", and hayashi's instance will send a 200 http response to wsd's instance. At this point the invoice is considdered "sent" and an identical copy exist on both instances.
At this point I'd be tempted to start focusing on where and how we will implement web3 into this process. But I think for now we can continue to describe the current behavior as-is, and save that for a different time as we continue development. The next blog post will be about confirming and making a payment on the invoice.
