XTRABYTES Development Update
May 21st, 2018
Frontend Development update
This is a development update, development updates won’t provide patent news.
That being out of the way, below is a summary of activities over the past month and an idea of where the frontend dev team will be focusing our efforts prior to the next update.
We’ve also included answers to a bunch of frequently asked questions regarding the SSS/DICOM API, hopefully they’ll help to make clear why we’re putting the time into it.
Highlights from the past month
Static Simulation System (SSS)
Progress on the XCITE desktop client was being more and more hindered by lack of access to the core code.
The SSS was suggested by Borzalom as a solution; the frontend team are adding functionality to SSS to allow XCITE to move forward.
The following functionality is complete:
- SSS protocol request/response implementation complete
- SSS Remote Procedure Call (RPC) wallet functionality complete
- This is an SSS solution to mimic on-chain events (sending coins, etc.)
- SSS will be talking to the testnet via a testnet wallet
- Testnet block-height has been increased to 250,000 to facilitate SSS
- SSS key-value store functionality implemented
- Reference DICOM client libraries in C#, NodeJS and PHP
- These libraries will change as we work out the shape of the DICOM API
- Useful as a reference for creating libraries in other languages
- Can ultimately be used by third party developers to build their own solutions on the XBY platform.
XTRABYTES Consolidated Interactive TErminal (XCITE)
As mentioned above development on the XCITE desktop client slowed the past month due to a focus shift toward SSS, but we’ve reached the point that the initial wallet functionality/UI is mostly in place.
No new build of XCITE desktop this month.
Work on the XCITE desktop client will resume as we wire it up to the SSS.
XCITE Mobile (iOS/Android)
Our initial goal was to build a minimalist light wallet for iOS and Android, the UI functionality of which is now complete.
XCITE Mobile utilizes the desktop codebase (with a mobile-optimized UI) so we’ll be able to wire it up to the SSS without too much additional work.
Check out the screenshots below of the current build running on Android.
Github Repository Reshuffle
All repositories have been moved over from Borzalom’s personal account to a new XTRABYTES Github organisation. Hopefully this helps give a clearer picture of the relevant projects and will make progress easier to track.
The frontend team has now been given commit access to the XTRABYTES repo.
Below is something of a short-term frontend roadmap. This is not in any order but development projects tend to have a critical path that dictates priority. Some items on the list may happen in parallel.
Since giving any sort of date is suicide in crypto we’ll simply say we’ll have these done as soon as we can, but we’re currently estimating weeks rather than months.
We’ll provide updates against this roadmap and expand it to include core functionality once the patent hits pending status.
User authentication workflow (XCITE/SSS)
Development of the signup and login workflows in both SSS and XCITE.
- Sign-up on desktop and mobile
- Login on desktop and mobile
Wire up XCITE wallet functionality to SSS
Provide wallet-like functionality within XCITE (mobile and desktop) without having to run a local testnet wallet. This should make XCITE feel more real.
- List transactions
Work on mobile XCITE to continue; tweaking UI for core functionality:
- View transactions
Other things we’re thinking about
STATIC node registration
We plan to offer STATIC node registration from within XCITE, with XCITE completing registration using the SSS.
More details as we have them but this is currently considered a high priority.
Before functionality can be ported from the SSS to the STATICs it needs to be thoroughly tested. Once XCITE is wired up to the SSS we’ll distribute a new build for the community to provide feedback/break.
While it’s still very early days with regard information about how XTRABYTES dapps will work, we’ve had some community interest about building on our platform.
As soon as XCITE is talking to the SSS we’d love to talk to you about your ideas and discuss the functionality that you’ll require of the SSS (i.e. STATIC) DICOM API to make them happen.
What is the SSS?
The SSS is intended as a drop-in replacement for the STATIC network.
Let’s look at a simple example:
XCITE: Hey STATIC network, send 100 XBY to chef
SSS: Cool, done, here’s your transaction ID
As far as XCITE (or any other third party app) is concerned, the SSS is the STATIC network.
While the SSS will look like the STATIC network, behind the scenes it will use simplified methods to mimic the same functionality. For example we’ll use a testnet wallet to provide for on-chain transactions, whereas the STATIC network will use the zoltchain.
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck. https://en.wikipedia.org/wiki/Duck_test
Why build the SSS?
We can use the SSS to iterate on both the DICOM API and to progress XCITE as if the STATIC network was already live.
Upon availability of the STATIC network, XCITE can simply be told to talk to it instead.
We plan to port much of the DICOM implementation over to the STATIC codebase which is written in C++, saving further time down the line.
What is the DICOM API?
The DICOM API describes how clients (XCITE, third party apps, etc) communicate with the STATIC network. It’s more of a description of how things should work than tangible code in and of itself.
Aren’t SSS and DICOM the same thing?
We’ve abstracted them into separate components on the network diagrams to show that clients and servers communicate via the DICOM API but in reality the SSS and STATIC network both provide a server-like implementation of the DICOM API.
XCITE is a client that knows how to talk to a server that implements the DICOM API (SSS, STATIC network)
Won’t the SSS be redundant after the mainnet code is released?
- Provides a simulation of the STATIC network that developers can use to build apps that utilise DICOM.
- Will be used by the core team to prototype and test new ideas without risk to the STATIC network.
- Much of the SSS code will be ported across to the STATIC codebase to form the basis of its DICOM implementation.
Why is Borzalom working on SSS instead of the patent?
He isn’t. Borzalom got involved just long enough to relay the idea and provide us with a starting point. Other than helping with any technical questions, he will not be involved with the initial development of SSS. His focus remains the patent.