Tue 5 Dec 2017 11:21PM

[meeting] 05/12/17 Developer meeting minutes

P peg Public Seen by 319

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.

mix irving Fri 15 Dec 2017 2:28AM

thanks for taking and posting notes @ameba23 (peg), as a person joining the team it's an invaluable reference, and is a perfect for a distributed team.


mix irving Fri 15 Dec 2017 2:37AM

The 'where to host it' conversation is a bit of a bike shed.

I think the answer to "where should we host it" should be ourselves - as in the hosting should be decentralised with the users.
Full-disclosure - I work with scuttlebutt, which is a decentralised database which doesn't require logins, and works offline. The major reason you wouldn't currently use it would be if people in the group only had smartphones (and didn't have computers), as that's still in dev.

We've already got a mutual credit library that works on the system, and there's a loving active community that would be amazing to ally with.
Aware there's already a bunch invested in a centralised solutoin here.

If there's any option of that, would love to talk more. I'm also happy to hear strong no


Kieran Mon 18 Dec 2017 12:03PM

@mixmix so to my understanding investment this far in the rails app (centralised solution) was a means of 'getting off the spreadsheet', and also coming to terms with what we're actually trying to do. Its also the most widely shared area of experience / skill for those of us working on development. Personally after looking into scuttlebutt I'd be very interesting in pursuing this approach as it seems like a really progressive use of the internet.


mix irving Tue 19 Dec 2017 12:26AM

yeah sorry I was writing as I was waiting for ruby 2.4.0 to install. I should read the code that's already been made. I see there's about 4 months of solid work here. Look forward to reading through it more.