tribler/decentralized-mortgage-market

decentralized-mortgage-market's Issues

Sprint March management issues

General architecture of the application

We came up with the following architecture for the application:

Please use this issue as a discussion thread for the architecture.

Sprint March management issues

• ORM integration
• Protocol buffers integration
• Original BSc project code replaced with compacter, safer, and maintainable code
• Angular2 GUI
• Angular2 blockchain browser
• LibUTP evaluation for document transfer
• first step for IBAN payment integration
• bitcoin integrated payments
• decentral market stress test

Should we use TFTP or something else for file transfer between customers and banks?

Right now, we are using TFTP for file transfers between customers and banks but there might be some better alternatives for this.

Pros of using TFTP:
-UDP, more easy to puncture NAT
-No need for separate logic, everything can be contained inside one system

Cons of using TFTP:
-We have to implement our own cryptography operations
-TFTP might be a bit more unreliable than TCP-based solutions (HTTPS/FTP)

Think about a scenario file that we can use for an application test

We should think about a simple scenario that we can use to test our application in a bigger and more challenging environment. This could be something like this:

• bank X comes online
• customer A registers with the application and uploads the required files
• customer B registers with the application and uploads the required files
• bank X gives investor A a credit rating of x
• customer A creates an ask of 500.000 euro on the market
• investor C registers and creates a bid of 250.000 euro on the market
• ...

Think about demo data

We should have some valid demo data. This is related to issue #8.

Review the inputs that users provide in the application

Users provide various kinds of inputs during the customer journey, i.e. documents and personal information. We should make sure that these inputs are complete enough and if we are not missing critical information we need from users.

Use Firebase as our 'demo' backend

After a discussion, we found out that it is possible to use Firebase as a backend for demo purposes. This way, the demo backend is split from the main source code.

Sprint April management issues

Backlog to pick from:

• Pivot business model (away from crowsourcing to syndicated mortgages)
• income and payment monitoring
• Refactor original blockchain code
• Blockchain signed half-blocks
• churn resilience, live edges
• prepare live test of decentral market
• blockchain scalability, N-Hop-Sync
• notary test
• Transfer of ownership for investments
• global consensus on current owner without proof-of-work; checkpoint consensus

Separate the GUI from the core logic by providing a (RESTful) API

The core logic of the mortgage market should be separated from the GUI. In order to do so, we should build a RESTful API that the GUI can use to fetch data.

The same architecture is currently present in Tribler and some of the code can probably be reused for this purpose (i.e. https://github.com/Tribler/tribler/blob/devel/TriblerGUI/tribler_request_manager.py and https://github.com/Tribler/tribler/tree/devel/Tribler/Core/Modules/restapi).

Sprint February management issue

In this sprint, we focussed on the following items:

• remove bottlenecks in message handling between API and community.
• remove architectural violation by splitting the GUI and core process.
• resolve non-compatible tracker bootstrapping protocol.
• security scan result: remove Pickle mechanism that auto-executes any code exploit.
• complete cleanup and documentation of the data model.
• security scan result: broadcast of private IDs.
• integrated protocol buffers.
• make the data model ORM-ready.
• blockchain communication layer moving to Protocol Buffers.
• standardised fault and error logging.
• create documentation for the RESTful API.
• cleanup of the unreadable binary data transfer protocol.

Team Amsterdam:

• JavaScript professional GUI first screen.