minutes from developer meeting 5/12 -in london and via skype.

Firstly, sorry if you feel you werent invited to the meeting. The meeting was organised on keybase, and was quite spontaniously organised (originally planned to be a meeting of 2 people and then more joined)

@kyphae, @nikolai2, futurechimp/dave were present in real life and @williammoxdrossard and @ameba23 via skype.

Ive missed some stuff for sure and maybe these notes are not so clear -let me know if this is an issue and please add things if u were there.

the state of things/current issues

kieran explained a bit some concepts and the state of things now and we discussed a bit:
- each transfer is 2 things (credit and debit)
- everything must sum to zero (accounting)
- 2 kinds of dep alloc and widthdrawal
- possibility of member 'gifting' -transferral of liability of an asset from one member to another
- avoiding decimals -make user enter exactly what will be sent to server
using javascript to make decimals for display is fine, but what goes to server should be integer (eg: mBTC)
- caching of rates (eg. btc to usd)-is an issue. the rate can change very fast and this can cause problems

- which exchange to get value from?

widthdrawal of funds from the system

• user can request a widthdrawal which they will be give status update like 'pending' 'in progress' 'approved'
• with 'pending', 'in progress', user cannot cancel the widthdrawal at this point
• admin then recieves an email notification from the system that a user is requesting a widthdrawal. for security reasons, as little data as possible will be in the email, it is more a reminder to do something.
• people agreed to use a cloud service for sending email rather than do it ourselves.
• i asked: can people widthdraw in crypto? people said no reason why not
• how to validate account details or public addresses? the problem of different countries account numbers look different -one suggestion use keybase at this stage to validate.
• we went on to talk about how we could use keybase for notfications, and possibly for other things as well. It seems we all agree that keybase is a good system for validating identity. -futurechimp - debugging and testing can be done by the group rather than a dedicated test team.

how does mmt work?

futurechimp started a discussion on the extent to which the function of dans spreadsheet (the system as it is now) is taken over by this project

nikolai- we could, at some point, write more code, and have the spreadsheet system do less.

possibility of spreadsheet intergration. eg.dump spreadsheet to json... this has security implications.

i brought up the notion i was getting from loomio that there is conflicting opinions of what we are doing here. so i got nikolai to explain his understanding.

his opinion is that at this stage we are trying to make the software as simple as possible, by only replicating the current system that it actually in place. which is that dan has a spreadsheet and is the single administrator of the system. So when the web app goes live, dan will continue to control keys of all assets as well as the bank account. and the idea is basically that people can give dan money to look after.

nikolai stated that dan himself want to broaden this and make mmt do more different things. but nikolai's opinion is that what we are building now should be a simple as possible and do no more than be a database representing who is assigned which assets, but all assets will continue to be controlled by a single administrator.

(i was actually quite suprised about this. This wasnt really what i was imagining.)

operations and hosting

• mathieu has set up a server with jenkins and rancher, that we can use for testing. he explained this
• infrastructure ci/cd docker hosting
• docker containers are built automatically as commits are pushed to github.
• a different subdomain for each feature branch so we can test everything.
• mathieu will write a guide explaining the steps he took to provision his server.
• the jenkinsfile he is using can already be found on the feature/dockerize branch.
• it is not currently working on development branch because of some missing environment file. bit of confusion about this.
  
• tests -rspec giving errors. but might be the tests are not written correctly.
• i18n
• user acceptance testing
• I suggested we have a live demo so people can try it out. This might help to clarify some confusions within the group. We could do a roleplay with pretend money. Also for testing/debugging.

There was some discussion on how to host for production. This is something of a debate which we would like to open up to everyone on loomio.
The suggestion was to use a major cloud provider such as digital ocean or amazon ec1. Because of ease, security, reliability, and automated backups.
It seems mostly we agree that we'd rather not use amazon -but most said it was still the most realistic option. futurechimp is saddend by this but its true.
(we did not go into details about why one might not want to support amazon, such as the extremly bad conditions for their warehouse workers and the destruction of any attempts by workers to unionise)

i suggested we run a vps or dedicated server host it ourslves
nikolai against this- we cant build something secure and reliable. Robust more important than morals at this point.

There was some discussion about 'well we could first put on amazon and then when we sort out something better we'll change it'
but nikolai pointed out as soon as its up -peoples data is there- and moving it then somewhere else isnt gonna change that.

i suggested that we should minimalise the amount of personal data on the sever. not names but a unique id number, which refers to personal details kept offline on the spreadsheet.

Working together as a dev team

• we will continue to use github 'projects' for big todo list and github issues for smaller ones within a feature branch,
• talked a bit about how much time we all have for this and if we feel able to contribute/happy with what we are doing.
• publicoffice people are gonna work on frontend. they are ruby devs so no need for an external api, which everyone was happy about.
  
• Discussion of mathieu's work on the keybase api - everyone interested in this.