Endpoint request contains a token. Server checks whether it has enough entropy to be secure (at least 128 bits and >0.7 shannon heterogeneity). Server hashes the token (once as of now) and derives nickname and robohash avatar (goes into static/assets/avatars). Nickname is limited to only adjectives, nouns and 3 digits, restricted to 18 characters long max. The corpus of nicknames is 20 billion big (maybe not enough? nick collision chance can happen, but server will just reply with 400 unless the token matches perfectly too)
Added the Order model with a rough approxiation to the fields needed. The field status can be read lineally as the progression trough the app pipeline. The view serves POSTs requests to enter new orders into the db.
- Motivation
1) It is widely recognized that one of the main attack vectors for the Bitcoin network is the ability of states to control the fiat on/off-ramps.
2) While there exists peer-to-peer alternatives to centralized exchanges, these are rather technical, slow and more costly.
3) Most users prefer the convenience of a centralized exchange at the cost of a difficult of the risk for their privacy and a difficult initial setup (ID, selfie-video, etc).
- Opportunities
Using the Lightning Network and hodl invoices it is possible to create a more user friendly, faster and cheaper peer-to-peer market. This vision was first enacted by @grunch on the p2plnbot telegam bot project.
- Challenges
1) Ideally the seller hodl invoice and the payment to the buyer invoice would be atomic. Given that this is not technically possible, the proposed concept relies on the need of trust on the service provider.
There are reasons to believe that challenging centralized solutions both in user experience and cost is possible.
This commit adds a rough concept for thefrontend, backend and design.
This project, tentatively named RoboSats (short for Robotic Satoshis) and licensed at launch under AGPL3.0.
