tribler/decentralized-mortgage-market

Tribler

Towards making Bittorrent anonymous and impossible to shut down.

We use our own dedicated Tor-like network for anonymous torrent downloading. We implemented and enhanced the Tor protocol specifications. Tribler includes our own Tor-like onion routing network with hidden services based seeding and end-to-end encryption.

Tribler aims to give anonymous access to content. We are trying to make privacy, strong cryptography, and authentication the Internet norm.

For the past 11 years we have been building a very robust Peer-to-Peer system. Today Tribler is robust: "the only way to take Tribler down is to take The Internet down" (but a single software bug could end everything).

Obtaining the latest release

Just click here and download the latest package for your OS.

Obtaining support

If you found a bug or have a feature request, please make sure you read our contributing page and then open an issue. We will have a look at it ASAP.

Contributing

Contributions are very welcome! If you are interested in contributing code or otherwise, please have a look at our contributing page. Have a look at the issue tracker if you are looking for inspiration :).

Running Tribler from the repository

We support development on Linux, macOS and Windows. We have written documentation that guides you through installing the required packages when setting up a Tribler development environment.

• Linux
• Windows
• macOS

Packaging Tribler

We have written guides on how to package Tribler for distribution on various systems.

• Linux
• Windows
• macOS

Docker support

Dockerfile is provided with the source code which can be used to build the docker image.

To build the docker image:

docker build -t triblercore/triblercore:latest .

To run the built docker image:

docker run -p 20100:20100 --net="host" triblercore/triblercore:latest

Note that by default, the REST API is bound to localhost inside the container so to access the APIs, network needs to be set to host (--net="host").

To use the local state directory and downloads directory, the volumes can be mounted:

docker run -p 20100:20100 --net="host" -v ~/.Tribler:/state -v ~/downloads/TriblerDownloads:/downloads triblercore/triblercore:latest

The REST APIs are now accessible at: http://localhost:20100/docs

Docker Compose

Tribler core can also be started using Docker Compose. For that, a docker-compose.yml file is available on the project root directory.

To run via docker compose:

docker-compose up

To run in detached mode:

docker-compose up -d

To stop Tribler:

docker-compose down

Get in touch!

We like to hear your feedback and suggestions. To reach out to us, you can join our Discord server or create a post on our forums.

License

This file is part of Tribler, Copyright 2004-2023. Tribler is licensed under the GNU General Public License, version 3 (GPL-3.0), as published by the Free Software Foundation on 29 June 2007. Tribler is free software: you can redistribute it and/or modify it under the terms of this license. Tribler is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, see the full terms and conditions in the LICENSE.txt file at the root of this repository, or visit https://www.gnu.org/licenses/gpl-3.0.html.

decentralized-mortgage-market's Issues

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)

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

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.

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.

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.

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.

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
• ...

Sprint March management issues

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 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

Think about demo data

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