BarDapp Functional Specs Requirements and architecture This document provides outline functional specifications and requirements for the BarDapp - a system that turns free booze into free software using blockchain technology. This is not a project plan. It is a guide for system architecture and development, not for phasing, timelines or deliverables. It also doesn’t explain why we are implementing it. You can read it here This document is divided into five sections: Overview Contract Clients (wallets) Database design UI Overview Goals, non goals, users, phases and tools. Goals Turn free booze into free software Make collaborations on opensource projects easier to start Make collaborations more long term Promote diversity of beer at hackathons Offer small local breweries meaningful sponsorship opportunities Non Goals Reward mechanism based on beer Beer payment system Tokenisation of help and beer Users Hackathon and conference guests (with or without tech skills) Local breweries Open source projects, either teams or individuals Phases Only phases 1 and 2 matter at this moment. Phases 2 and 3 will be modified In Phase 1 we release a prototype with basic functionalities and test it during the event in Berlin called DAppHack. Contract in this version requires no or very little tweaking, UI consists of paper wallets, and perhaps, in order to redeem tokens copy pasting of addresses is done manually. Database is also maintained manually. In Phase 2 we make some tweaks to the contract depending on how our test goes and develop a better UI. The paperwallets are now can be scanned at the bar without a need to copypaste each address to redeem tokens. Database is published on IPFS and the keys to particular entries are given to relevant participants. I.e, if I offer help to a particular person or a project, only this person will be able to see it, because this person will hold a key that decrypts only the entries associated with this particular project. In phase 3 guests will be able to receive beer tokens before the event by registering online and creating an offer of help entries themselves. In a phase 4 Instead of paperwallets they will be able to use a mobile client, either a not fully decentralised one, or a decentralised one provided a good customisable mobile light client is ready. Contract In the phase 1 we are using a Solidity contract HumanStandardTokenFactory.sol submitted to Github by @simondlr. It might require some tweaks. Requirements for the contract: Create tokens on an account (master account) Distribute tokens to account from a master account controlled by a trusted human who puts help offers into a database Withdraw tokens from accounts into a bar account controlled by bar staff when the tokens are redeemed for beer Clients (wallets) The system requires at least two types of clients. Master wallet Point of Sales (can be combined with master wallet) Guest wallet Master wallet corresponds to the account that can issue tokens to the guests. In the beta version it is operated manually and there is no automation between entries into a database and the issuance of tokens. In future versions we can create more complex web of trust system with guardians who validate database entries. I don’t think a link between the database and the wallet can or should be fully automated. Point of Sales wallet is a wallet that can withdraw tokens from the account when tokens are redeemed for beer. Requires a QR code scanner which is capable of scanning an unencrypted paper wallet and withdraw custom tokens from it (not just ether) Guest wallets correspond to the accounts of guests who receive tokens after they have registered an offer of help entry. As far as I understand In the beta version guests wallets can be paper wallets - QR codes of an unencrypted key. It’s not secure, but will do for the fun token. We can generate them in MyEtherWallet. Question is what do we use for the Point of Sales wallet to scan the QR code with unencrypted key on a beta guest wallet. Database Database is a list of accounts associated with offers of help that each account holder provided. Also information about whether this help is offered to a particular project or to any project participant of the BarDapp infrastructure. Offers of help are promises to help someone for an x number of hours, may be just one hour on a particular task or with a particular skill. In a beta version which will be used at DAppHack event in November database is done on paper by a human. Entries into a database done manually by a guest or by a dedicated database human. This human is basicaly someone who registers people at a hackathon or a conference. After the event this database is published on IPFS openly in unencrypted form and the hash is shared with all the participants so they can find it. However, contact details are not published on IPFS and are provided on demand by a dedicated human directly to the project participants. In later versions the database entries are published in an encrypted form and only people whom a particular offer of help concerns can see the entry. This way we will be able to publish contact details and won’t need a human to take care of it. UI The version with no custom UI is a bootstrap: Paper wallets used by the guests (associated with their token accounts and entries into the offer of help database Mist wallet can be used to distribute tokens Database interface: spreadsheet either on paper or stored locally on airlocked device. There is no QR code scanner for the Point of Sales, instead the addresses are copy pasted from the list to withdraw tokens from them. Beta version with custom UI Webapp to top up guest accounts from master account which can be run locally. A PoS which can scan unencrypted private keys on guest paper wallets and withdraw tokens when they are redeemed for beer. Later versions can have Mobile guest wallet which supports a custom token associated with the Bar token contract. A web interface which allows guests to register their offers of help and receive tokens in advance