Gearing up for Alpha

This week has been a sprint to try to get a launch-able product out for the alpha release. This has been simplified considerably for our project because of the revelation we had about exactly how the block-chain will be utilized in the final product. Basically, I was thinking incorrectly and trying to have the team use it as a full-fledged database. This is strictly impossible because each block is immutable, so once something is written it can no longer be updated, thereby making it an impossibly poor general database. This correction of planning has made the overall application much simpler to figure out and implement for the alpha.

Moving into the alpha release, we are focusing on only the mobile application and the web-server. For the alpha, the only implemented section will be the user section of the application. This basically means that the server only needs to have read setup, because no winery side of the application is ready to write to the database. I have setup some sample data on the firebase side of the web-server for the application to access through the node server API. The front-end application has been redesigned according to the new UI guidelines the team came up with, but has roughly the same functionality that the demo had from last term. This time, however, the application will actually be pulling live data from the web-server instead of just accessing general data pre-implemented within the application itself.

Progress is coming along with the project, but I feel the team, including myself, are falling behind this term. We still need to implement several features to the user side of the application, and then add in the winery side. From there, there is the QR-code generation and block-chain tracking. Hopefully we can get most of this done by the end of the term, but I can tell already that it’s going to be an uphill battle.

Outside Blockers

This week has been particularly challenging for reasons out of the scope of this class. It can be frustrating to be limited in the time I can spend on this project due too other class and personal responsibilities. I am taking a 499 course, so I understand there is an experimental element to the class, but some professors do not put in as much effort as others. There is a clear difference between the teaching materials prepared by a more dedicated teacher and the teaching materials prepared by a research professor. The class I am taking, which I will be refraining from mentioning specific names, is clearly just copy and pasted from the resources of another college from several years ago. The lectures tend to be rambling and constantly go over time. Apparently this course was designed for a semester system, and so we are more pressed for time than the course was literally designed for.

Besides my misgivings about the general teaching materials, the real issue came to a head this week. We were given a homework assignment that required us to install a particular software. This software is, as has become apparent, extremely difficult to setup on a home system, and very particular about it’s settings. Too add to this, the information and tutorial we were directed to for setup was 8 years old. That’s 2 full builds of the software behind where it is now. Everything was a mess and the instructions were just outright incorrect. I brought this up to the teacher and was informed that normally they would give us a VM with the software on it, but because of Covid he decided not to do this incase someone’s computer couldn’t run the VM. In addition, he told me that he had not actually looked at the tutorial, only seen that one existed and linked it to us. This has been an extremely frustrating week.

Back From Break

Back from the winter break, and it was desperately needed. This term is looking to be much less busy overall, which hopefully will free me up more for the capstone class project. There are some worries of balance of work over this term, however, because I know that my other group members are going to be busier and I am more experienced with most of the technologies we will be using. Honestly, I think our group is  a little behind already because at the core of our project is the blockchain technology, but the members of the group responsible for that side hasn’t been able to get it up and running yet. So I’m kind of flying blind at the moment, trying to setup a webserver that doesn’t have a destination to write too, and I’m not even sure how that writing will be done. The logic of the webserver will continue to elude me until we figure out exactly how the backend is working. 

The mobile app is looking decent overall. I think there are several key areas that can be addressed while the backend is setup, at least to a certain extent. My current goal is to finish upgrading the UI to the specifications that Sam will be providing this week. Not really sure how long this will take, interface changes can be an issue, and I haven’t finished implementing the correct way of handling states throughout the app. So after the UI updates, I’ll move on to working on the state handling, and from there the communication with the webserver. The true challenge will be getting all 3 components talking, and more specifically, planning out exactly which component will be responsible for the bulk of the logistical work. This term will undoubtedly have its own challenges, but I’m looking forward to getting this project done so I can clear out the work and have a more relaxing final term of my college career.

Frankenstein’s Monster

So after some deliberation during our team meeting this week we came to a couple key decisions, namely about technology and architecture. We have decided to implement the server RESTful API as an in-between for the mobile application and the blockchain. We also decided with certainty that we will be using Flutter for the mobile application, Node.js for the server-side, and Hyperledger Sawtooth for the blockchain. Nobody else on the team has experience making a RESTful API, and I have taken a CS 493, where we deployed such a server using Node.js on the gcloud platform. So there will be an interesting dynamic early on in our project, namely creating Frankenstein’s monster. 

The current plan, from my understanding, is to take the code I have for a server API and bastardize it as we see fit to fit our needs. From there, I will be making the mobile application from scratch using Flutter libraries for anything too complicated, like the integration of QR-code reading and generation. This shouldn’t take too much effort, but it will probably be fairly unwieldy and unorganized to start, which I guess is somewhat natural. The server side will undoubtedly be extremely awkward for the first portion of the winter term, especially considering that the other group members will likely be working on that portion. The blockchain section will basically not be touched by me, which I’m fine with because I would rather focus on expanding the skills I already have. But this leaves the majority of the project in this really funny state of being put together out of bastardized code that I have written for other classes, just trying to get it to all fit together. While I’m sure there will be more to it than that, its still interesting to think about how all of my classes have come together to this point and how useful the skills I have picked up along the way are. 

Architecture Discussion

So, in my mind, one of the primary flaws, or rather a lack of consideration up until this point, is how exactly our application is going to talk to the blockchain backend. Throughout this process I had always pictured the application talking directly to the blockchain. I guess I had been considering the blockchains use as a simple database. However, this isn’t correct in either form or function. While it is true that the blockchain will hold the data and is a database in that sense, accessing the data is significantly more obtuse than accessing elements of a simple database. 

So I took this thought and looked at the Hyperledger Sawtooth API. The API shows that you can setup the blockchain implementations as a RESTful API server. This is near perfect for our group, but the issue remains that the specific calls you can make to the API are limited, and we will be unable to change those calls to more application specific ones. This would leave the bulk of the data accessing and storing in the hands of the application, and that’s a lot of heavy lifting for a mobile application, at least in my mind. So I think the secondary approach is what our team should consider.

Basically I would create a RESTful API webserver that would handle all calls from the application to access the data in the blockchain. This would keep a solid separation of responsibilities in my mind: the application as the the front end, the server as the controller and backend, and the blockchain as the database. In addition to the solid seperation, this would allow for ease of access for future development. If our project partner wished to later access the blockchain with a website or some other application, this RESTful API server would make the interactions a lot simpler and would still work just as well for our application. The only concern that our project partner brought up is the extra security risk, but we’ll discuss that another time.

A Deeper Look

This week I took the time to sit down and really take a hard look at Hyperledger Sawtooth, the blockchain technology our group will be using for the project. Hyperledger is the open source blockchain technology that is hosted by the Linux Foundation. Basically, Hyperledger is trying to create stable frameworks and tools so that the blockchain technology is accessible to businesses for any number of use-cases. Our group chose the Sawtooth at the request of our project partner.

Hyperledger Sawtooth is a blockchain system that was designed to be used by enterprises for creating and operating distributed ledger applications and networks. Sawtooth stands out from other Hyperledger systems because it allows for permissionless networks as well as permissioned ones. This allows for networks to be used for both private and public affairs. For our project, this works out well because we do not need to hide any information, so we would want to setup a permissionless network. This will allow anyone to hop on and view the data as they see fit. One of the key goals of our project from the start has been transparency of transactions, and a permissionless network allows us to do just that.

Sawtooth is currently one of the less represented technologies underneath the Hyperledger umbrella. One company that is using it similarly to our goal is Scan Trust. Scan Trust utilizes copy-proof QR codes to give different company supply chains traceability and transparency. They used Sawtooth to allow users to trace things using the blockchain technology so that there is a guarantee of no tampering and complete clarity of transactions. So after implementing the changes and using Sawtooth, users now log all data on the blockchain and the data is then accessible through the QR codes on each product. This is a near exact implementation that our group is looking for.

Narrowing Scope

After last weeks meeting and having done the project requirements documentation, there was a distinct issue with the application that I was beginning to see. To me, the scope of the project was not specific enough. We were trying to tackle and application that was explicitly for tracking expensive wines with incredible detail and accuracy. At the same time we wanted an application that could be widely used by wineries to provide the majority of their customers with general wine information. These two project end-goals were at direct odds with each other in my thinking. So I went to our project partner and expressed this dilema.

The project partner was clear: general and wide use is more important than specificity that helps only a small group. So we restructured the project requirements based on this feedback and I think we finally nailed the project on the head. Overall, wineries will be able to add wines that they have created and generate individual QR-codes for each bottle. There will be some general fraud detection based on some location data that is given whenever a QR-code is scanned by a phone, but the fraud detection takes a backseat to the general use case of “a consumer scans a QR-code and gets the information on the wine”.

There was some minor disagreement among the team; nothing to be concerned about, but some clarification was still in order. The general consensus that the team came to was if a user had location data enabled, they would be able to mark that they had bought the wine bottle, if they input their own information. The application would then check to see if the wine bottle was being “purchased” at the same location as the last time it had been purchased. If this was the case, the new data would overwrite the old data, and that data would never be officially added to the bottle’s history. This allows for people who truly care about the wine bottle’s transaction history to continue to keep track, while also being user friendly enough for the general customers.

Partner Meeting and Clarification

This week was our first “face-to-face” encounter with our project partner, Jim. He seems extremely motivated and enthusiastic, which is fantastic. Jim is a big proponent of blockchain technology and thinks it’s going to be utilized across many different industries, and I agree. Jim has found a niche market that can use this technology and really show it off. Thankfully we got a lot of clarification out of the way with our first meeting, and our fourth member has been confirmed to be alive and well.

Jim’s project is actually fairly straightforward and simple: create an application that can scan QR-codes on wine bottles, reach into the blockchain for data pertaining to the bottle, and display it to the user. Wineries would upload the data they want displayed. Consumers could get more information about the product they want to buy. It’s simple and usable.

The real fun comes in with making each bottle an individual QR-code. This allows the calls to the blockchain to also collect data from the application while it is in use. The most useful application being location tracking the scan and comparing it to any scan made on the same bottle within a set amount of time. If the bottle was scanned in multiple states within an hour, then the wine would be deemed fraudulent and any consumer that scanned that QR-code in the future would be warned.

Furthermore, with tracking where and when these scans are taking place, then it would be a simple matter to compile this data and provide it back to the wineries so they can judge where their product is selling best. More information with the wine makers will help to support their business, and the information provided to the consumer has the opportunity to allow for direct-to-consumer interactions from the wineries. While the product seems simple, it could have some profound and lasting effects on the industry. With being able to track potential fraud, as well as helping cultivate the relationship between creator and consumer, I cannot wait to see how this project shapes up.

Team Meeting and Initial Contact

So this week was the first we met our teams and sent out the initial email to our partner. Two of my teammates were on top of the ball so the three of us were able to hammer out some details and decided to move forward with project management via Trello and team communication via Discord. We all seem to get along together well and I’m excited to work with each of them. Unfortunately, we have yet to make contact with our fourth group member, and it is now the Sunday of week 2. Hopefully this member can seek out contact soon so that we can get them involved with the group work that needs to be done in the coming week.

An email was also sent to the partner who proposed this project. We asked some basic questions and have already heard back from him. There is a meeting setup for early next week so we can really get down to some brass-tacks and hammer out details of what exactly they are looking for. He suggested we watch the movie “Sour Grapes” to understand the issue in the wine industry. Basically, between 2003 and 2006, a man managed to defraud the wine industry for millions of dollars by making fake bottles of expensive wines with printed labels and concocting fake wines by mixing cheaper wines together.

Our project partner wants to attack this problem by creating a technology that allows end-users to scan a QR-code and see all of the information about an individual bottle of wine, including the entire shipping chain so that you know exactly who had possession of the wine between the winery and the store you are buying it at. I think there will need to be more involved within the app, for example a feature where a person can propose to buy the wine from the winery or provider and then scan a QR-code from the current owner of the wine so the transaction is logged in the blockchain that keeps all the information secure and up-to-date.

Overall, I am extremely excited to be working on this project and am really happy with my group. It’s going to be an exciting year.