peter-lawrey-admin / chronicle-accelerate Goto Github PK

Create a benchmark test for end to end transfers:

1,2,4 threads
100,000 messages

UI- add User Profile/Account creation page

The flow from "create an account" to "view the profile".

1. Registration Process

Name
Email

Country
Region

Password

Button : "Create Account"

a. if we don't verify Phone number then don't include it
b. if Country and Region are important for the data base please include it in this only screen.
c. If the system won't show multi account. The system shouldn't allow to choose a name for the account.

2. Top Menu should include link to Profile.

Profile page should have: None of this

Your Personal Details:
Name: Full Legal Name
Surname: Full Legal Surnames

Email: (Populate from the registration process)

Date of Birth:
Phone Number:

Your Legal Address:
Address: First Lane of Address
Country : (Populate from the registration process)
Region: (Populate from the registration process)
Postal Code:

Profile Links:

Twitter: (https://twitter.com/TwitterUser)
You can Earn 1XCL Follow us on Twitter Button: Follow

Here the information to connect the following action in the web: https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/post-friendships-create

The API will send you an event showing that the user follow us or not.

UI - User profile page - add/implement "Claim my reward" buttons for Twitter/Telegram/Github

The system will verify that the user has joined the releavant XCL: Twitter/Telegram/Github group and reward the user with x "free transactions" per week and/or 0.5 XCLs.

UI - implement rewards program for Twiter, Telegram and Github.
Get full detailed requirements from Lilia.

FIX vs XCL review - comparison report

Look into the Twitter API - verifying a Twitter account, etc

Look at how we could integrate the 0x protocol

When sending more that 10,000 transfers from a XclClient to XclServer we sometimes get this error:

java.lang.IllegalStateException: Marshallable class cash.xcl.api.dto.TransferValueCommand too long was 65625

FIX Gateway/Exchange - add an input message to the Exchange to request the list of all open orders

FIX has OrderStatusRequest message

Plan: Add a message to return the state of all open orders.
Maybe we should have a command to request a list of all the open orders. Maybe we can do this on reconnect. When you login you automatically are told what are all the open orders. Maybe we do this outside FIX for now. We make the command available directly from the Exchange ie not available on the FIX gateway.

can you please write some code that issues a lot of buy and sell orders to the Exchange repeatedly over a long period of time. We probably need 1 or 2 seconds delay in between buy/sell orders that match.

The purpose of this code is to issue lots of buy and sell orders that will match so that we can see how the Exchange prices move up or down every second or so.

This order issuing code should run in a loop forever.
We probably want to move the prices up and down within a reasonable range.

One option is to just run this order issuing code within the Exchange service JVM itself - maybe we could have a start up boolean system properly that tells the Exchange service to start in this "simulator" mode.

The other alternative option would be to run this order issuing code as a separate process.

FIX Gateway - convert Exchange's CommandFailedEvent rejecting an order into a FIX Order Cancel Reject message

UI - add/implement log out button - disconnect XclClient connections/keys on logging out

• calling XclClient unregister

add ServerJVM and MultipleClientsJVM to aid benchmark tests = so that we can run client and sever in different boxes.

UI - create 2 accounts and do a transfer

SWIFT - Review how we could use the SWIFT standard to implement transfers

FIX Gateway - write a basic first cut of the FIX Gateway - including the new maven module

• which runs a Chronicle FIX Engine and acts as a FIX server.

This first cut will NOT do any conversion from FIX to XCL and XCL to FIX formats. There are other GitHub Issues which cover FIX to XCL and XCL to FIX message conversions.

It will however provide the basic functionality to:

1. It should provide some basic wiring for receiving New Order Single messages from a FIX client.

2. It should send some basic messages to the blockchain over TCP/IP

3. It should sign the messages that it sends to the blockchain.

4. It should receive some basic messages from the blockchain

5. It should send back basic hard-coded FIX Execution Reports to the FIX client.

UI - fix cosmetic issues - web page title should say XCL DEMO, url, etc

1. change web page title from Welcome to XCH to XCL Demo

2. change the url to something really simple that people will be able to remember:
   for example:

www.xcl-demo.com

or something simple like that

Exchange Service

Convert the existing business type tests to yaml tests.

The existing business tests can be found under:

https://github.com/XCH-Cash/Sandbox/blob/master/ledger/src/test/resources/cash/exchange/cucumber/OrderBook.MarketOrder.Matching.feature
https://github.com/XCH-Cash/Sandbox/blob/master/ledger/src/test/resources/cash/exchange/cucumber/OrderBook.LimitOrder.Matching.feature
https://github.com/XCH-Cash/Sandbox/blob/master/ledger/src/test/resources/cash/exchange/cucumber/Exchange.Quote.feature

Sandbox to Chronicle-Accelerate-Enterprise migration

UI - User profile page - add/implement "Claim my reward" buttons for Twitter/Telegram/Github

The system will verify that the user has joined the releavant XCL: Twitter/Telegram/Github group and reward the user with x "free transactions" per week and/or 0.5 XCLs.

This can be validated in the Local fast path, and processed in the local post block chain processor.
It should produce a TransferValueEvent or CommandFailedEvent.

Add yaml unit tests for the fast path and post block chain processor.

UI - implement user verification via email.

Whenever a user register for the XCL platform, the system should send an email to the user with a link that the user can click to verify that it is, in fact, the user's email account.

FIX gateway -> XCL Exchange - Signing/verifying messages

This can be added to the local fast path and local post block chain.

Add a yaml test to show that

• it cannot be set more than once for an account.
• transfer fails before it is set but works after.

UI - database - encrypt columns holding user private data
Encrypt user private columns in the database using the Sodium encryption library - use the chacha20 encryption method.
Do not encrypt data that is needed for searches or data that is already publicly available in the blockchain.

we should encrypt everything that might identify a user eg a user's email address
we use the user's password to encrypt the data

the user provides the user email address and the password and then you encrypt the email address using the password as the key

it should be impossible to read the email address using simple SQL

we need to add an encrypted store to map sendCompId and password to the (an encrypted form of ) the secret key (encrypted using chacha20)

FIX Gateway - NewOrderSingle - convert FIX NOS message into Exchange's format

Facilitate Vaadin code review

FIX Gateway - Execution Report - convert Exchange's ER message into FIX format

UI - Chart exchange rates received from the Exchange service

For a given currency pair, eg XCL-USD chart the exchange rates over a period of time.

The script should do something like this:

stop tomcat
stop ServerJVM

do a git pull on:

Sandbox
Chronicle Accelerate
Chronicle Salt

Build the code - ie do a mvn package on all of it

Copy the war file to the appropriate tomcat directory

start tomcat
start ServerJVM

Check that the database and that ServerJVM are secure and not accessible from outside

We might want to run the Nmap tool and do a port scan and analyse security weaknesses

Only the ssh port and the Tomcat port (8080) should be available from outside

UI - implement list of "known" receivers - mapping addresses to a names
ie allow the user to assign a name of a person/company to an account address -that we often receive money from- so that from then on it will any transfers received from that account address will appear in the Transaction screen as being received from that person/company

The FIX gateway should handle all order related messages:

1. • New Order Single
2. • Execution Report
3. • Order Cancel ?
4. • Order Status Request ?

The FIX gateway should store information about a NewOrderSingle and enrich the ExecutionReport on the way back.

The FIX gateway should keep track of the Client Order Id and account - a field that a user supplies.

mapping of client order id to our id (source address and eventTime )
longer term we need persistence for this

longer term, if a client disconnects , we should cancel all their orders

The FIX gateway should translate fields into the fields the XCL Exchange uses.

The XCL Exchange might needs additional fields that are needed by the FIX protocol.

UI testing

Add tests which show that the local fast path and post block chain can consume this event.

• transactions on this account fail before it is received.
• transaction succedd after it has been processed.

Telegram API - verify that a user has joined a Telegram group