In this blog post, I’ll be taking the community on a tour on how the development team produced XCITE, including the struggles we had and where we are now.
In November 2017, Zoltan and I first started discussing the need for a global application that could be used as a control center for the platform we were creating. However, the only reference I had was the existing wallet written in QT. Aside from that, we had nothing to fall back on.
Clearly, we had a bumpy road ahead. During November, we outlined the basic requirements for the development platform on paper. We wanted a cross-platform development environment that allowed us to compile one source code compatible with multiple devices and operating systems.
After testing several platforms, we selected QT and Visual Studio as potential platforms for our project. Reviewing all the criteria, we later narrowed it down to QT. Since most other blockchain developers are familiar with QT, we believe it will help us recruit experienced developers
Once we selected the platform, we began development of XCITE in earnest. Since we sought cross-platform functionality, we had to resize all screen sizes. This meant creating some very simple grids as shown below.
We eventually made these grids resizable, making it the very first code written for XCITE.
We soon realized the development task ahead of us was far larger than we anticipated. As a result, we rapidly expanded the number of developers and designers on our team. Since the community was growing, we were able to create partnerships with several community members (who later became new team members).
After extensive brainstorming, we produced several designs based on the initial needs and requirements set by Zoltan. We struggled to create our first version, as none of us actually knew what we were building. All we had were some vaguely-descriptive guidelines to follow.
One of the First Designs
Due to the experience of our designers, we eventually came up with several worthwhile mockups. However, the developers found that creating an actual GUI from these designs was somewhat challenging Using Adobe and Figma software, we found a platform that facilitated collaboration between the designers and the developers.
In February 2018, we actually began coding the GUI and testing it on desktop devices. This is also when we started creating the first needed variables/parameters for the backend code.
The screenshot below is an example of how we mapped GUI screens to variables on the backend.
By March, the first GUI-only version was nearly final and contained all the features requested by Zoltan. Unfortunately, we were unable to write backend functions because we lacked an actual backend to talk to due the constraints coming along with the patents.
Consequently, we decided to introduce our Static Simulation System (SSS). Using SSS, the development team could finally create code that would talk to a simulated backend. Its creation was a tremendous leap forward for the project.
Although we continued work on the desktop client, our progress remained limited until we received more in-depth information about the technology. At the time, the founders could not disclose any more information than they already had.
As a result, we’re focusing our efforts on completing the mobile application. By doing so, we’re able to keep our work ongoing until the actual backend is linked.
We definitely believed it would be easier to build the mobile application than it turned out to be. Many more variables come into play with a mobile application than with a desktop application. Developers must choose between several different screen sizes, processor architectures, and operating systems as options.
After exploring several mobile GUI designs, our designers came up with a mobile design compatible with all device types. Some of the designs that didn’t make the cut can be seen below.
Working on a new application built from scratch required me to employ all of my skills and even extend them (gaining several new skills along the way). In the end, we created a new application that is well-suited to serve as the portal to our platform. I’m very proud of our results and the people who have helped us create it. As stated in this blog-post, a lot of effort has been put forth to make this new application just right.
Working on XCITE Mobile for the past few months has been both exciting and challenging. First, we ensured that our mobile wallet was functionally secure by fully protecting all data communication between the frontend and backend. Not only is every transaction to and from the server encrypted, but both the frontend and backend have an extra layer of encryption as well. Next, we made sure that the programming languages used (C++ in the frontend and Python in the backend) could encrypt and decrypt data without any data loss (using RSA-AES hybrid encryption). Resolving this problem and seeing the wallet come together has made all my late night work well-worth it.
As a member of the XCITE development team, I spent the majority of my time creating a proof-of-concept for secure data storage. This pursuit required learning Python so that I could implement server-side functionalities in suitable way. In addition, I spent time implementing a system that retrieved market values from various sources (in a non-intrusive way that was also iPhone-compatible). During my many months working on XCITE, I learned a lot about the QT platform and modern mobile development (despite already having 10 years previous experience building mobile games – although mobile app development has changed a lot since then).
For me, getting involved with the XCITE team has been a never-ending learning process. Many tasks involved compiling libraries for use in frontend and backend development. Since Android, Linux, Windows, macOS, and iOS use different sets of files, we had to find a way to integrate them into a unified XCITE platform. Ensuring that the libraries communicate correctly with the XCITE code was a major challenge. Another challenge involved converting library files in a way that did not present a security risk. In the end, we created all the library packages from the source code.
My desire to join the XCITE development team was motivated by a desire to help out with the GUI design. After I provided my designs to the devs, they used them as the basis for creating different user interface screens. However, the development team quickly concluded that I should code the interfaces myself. Doing so would allow them to focus on the GUI’s underlying connections. Consequently, I took it upon myself to learn QML, the language we use to create all graphical user interfaces for our applications.
Once we decided how the interface should look and act, we had to determine what operations would go on behind the scene. We knew from the beginning what we wanted with a portable account. An account that would let you log in and access all your user info regardless of what device or operating system you were using. So we chose to set up an account server that would host all the accounts.
Unfortunately, hosting all the accounts and the user data on a server brought with it a certain amount of security risk that couldn’t be neglected. First, we had to ensure that all the data stored on the server was encrypted in a way that only the user could decrypt. Second, we had to make sure that this encrypted data was only sent to the right person. Lastly, we had to prevent others from overwriting this data. Since the current way in which user-account security is handled appears inadequate, we began brainstorming to find alternative solutions. After carefully analyzing various proposals, we came up with a secure process for creating accounts, logging in, and saving data.
Our devs went to work and quickly built the account security system we envisioned. After rigorous testing, we were very pleased with the end result. Once we determined that we could safely store all relevant data, we decided on which account information we wanted to store. As time went by, we added additional elements designed to improve the user experience. In the end, we produced a mobile wallet capable of much more than just checking your balance and sending coins.
After completing the GUI, we had to connect the backend, update all interface values, and ensure that all functions could execute as expected. While our initial idea was to handle most wallet elements locally, we soon realized that we had to implement additional dependencies to make everything work (like most clones of the QT wallets). So we asked ourselves, why centralize everything in the app and deal with all these inconveniences? It would be far better to decentralise and rely less on such dependencies. So we set up an API server that would handle several different tasks for us and that we could query from the application.
And then came the most important part of the backend – the connection to our SSS. This would allow us to talk to the chain and perform various actions on it as well. While this was new to us, Zoltan helped walk us through its operation. Although some parts needed redundancies built in, we were able to get everything working after a collective effort. And it starting working just as we had envisioned the first version of XCITE mobile would.
As result, the application was ready to be handed over to our test group. They could start abusing it in order to find any bugs that escaped our attention. Their feedback will be invaluable to us as we iron out the last glitches and imperfections before its release to the public.
With the current beta release being out there we were able to build in some features:
- Monitor your wallet balances for XBY, XFUEL, BTC & ETH
- Live updates of all your balances
- No syncing time required
- Share your addresses for XBY, XFUEL, BTC & ETH
- Create new addresses for XBY, XFUEL & XTEST (our testnet token)
- Import existing private keys for XBY, XFUEL & XTEST
- Store your wallet keys locally or in your account
- Consult the transaction history for XBY & XFUEL
- Make transaction with XFUEL
- Order your contacts and their addresses
- Scan QR codes of both addresses and private keys
- Access your phone app directly from XCITE
- Access your text app directly from XCITE
- Access your mail app directly from XCITE
- Select your favorite fiat currency: USD, EUR or GBP
- Limit access to critical features with a pin code
- Backup your private keys
- Receive in-app notifications when your wallet balance changes
As stated above, we took some time setting up a secure way of creating accounts, logging-in, and saving data.
We sought to produce a wallet that doesn’t store passwords for accounts as it prevents others from stealing your account information. As we also sought to avoid visibly linking any personal information in your account, you’ll see no email address, facebook account, google account or any other account info asked by us. The second measure we took was to encrypt all the data stored on the server with an encryption key known only to the user. We came up with this idea after contemplating our inability to provide you with your password or let you set a new one in case you lose it. Thus, you will need to safely store your username and password so as not to lose all access to your account. This possibility is also why users should backup their private keys.
You may be wondering, how it is possible to gain access to your account using your password without us storing it or even ever letting us know what your password is?
What happens when you log in:
Everytime you login, you create a new key-pair (public key & private key). The public key and your username are sent to the account server. The server uses the public key to encrypt a new encryption key for this session. It then sends this newly-created encrypted key (with a string that is encrypted with the user’s password from the previous login) back to the user. The user then decrypts the encryption key (created by the server) with the private key (the one that goes with the public key previously used for the encryption). The user also decrypts the encrypted string and re-encrypts it with the encryption received from the server. The user then sends the newly encrypted string back to the server. By doing so, he is able to prove he has the password to decrypt the password-encrypted string already sent to him.
The server verifies the string with the answer he has from the previous login session. If the result matches up, the server sends the user-data (which is encrypted with the user’s password) and a unique sessionID (encrypted with the encryption key for the session created by the server) back to the user. This allows the user to decrypt and access his user data.
The user also creates a new random string to encrypt, once with his password and once with the encryption key created for the session. Both instances of this encrypted string are sent to the server. The server overwrites the old encrypted string and stores it for the next login attempt. Now, each time the user wants to save new data to his account, he will need to send the session ID alongside to prove he is verified to save data to his account. Thus, all data that is sent between the user and the server is either encrypted with the user’s password or the encryption key created for the session by the server.
And that is how we achieve identity verification without needing to know the password.