If we start using a language file from the start it would be easier in a later stage to translate the messages to a different language and reuse specific words like 'Error'.

A benefit from implementing localization is that all spellings errors could be fixed easier; @linda-90 and @GerbenBosschieter have some knowledge about basic scripting in HTML/CSS and could help keeping the language file up-to-date.

Resources

laravel docs: https://laravel.com/docs/5.6/localization

example in code base:
https://github.com/teamforus/forus.io/blob/c8d696f58423f923aefdafe8e036fdf0465e7a87/backend-php/app/Rules/IdentityOldPinCode.php#L45

I discussed with Dan how to structure the repository for development. After more thought it is a better idea to seperate the base PHP code to a seperate repository to make it easier to deploy (otherwise you clone all documentation to test/production containers)

This has low priority because we don't need to deploy forus.io yet to any server.

Based on #4 and https://github.com/teamforus/implementation/issues/12

• Request
  • DigiD
  • Me
  • Activation code
  • Quick test
• login
  • Mail
  • Me
• search
  • search products
  • search list of shopkeepers
• select shop
• select product
• request product
• show product voucher
• view lists of funds available
  • general funds
  • select fund
    • view validation requests
      • criteria / value / validator
  • activated vouchers / funds
• create voucher

Request for comment:

The expectation is that the extensions will talk a lot to the services (oracle) (#14), and that the me app and later also forus.io (the generic webshop) will talk directly to the api (#7).

A lot of the extensions we already have for Zuidhorn, we just have to go over them one by one to redesign them to be generic enough to be scalable to other municipalities.

• Research AWS
• Research Docker

Add addresses fields in database for the following tables:

• identity
• proxy_identity
• vouchers
• tokens
• assets

field for each
address string[42]

The generation of addresses will happen in the blockchain service

• Deploy on a regular server
• Deploy on Docker & AWS

based on https://github.com/teamforus/implementation/issues/12 and #3

• manual validation @maxvisser
• validator types
• automated validation
• register organisation
• login to validator dashboard
• validate citizen information

was not in flowchart

• History validations

We're noticing some miscommunication about common terms like "account", "identity", "key" etc.

We should add a glossary to our documentation.

Based on: #2

Wireframe requirement list

create budget - out of scope
select validators - out of scope
set validation criteria - out of scope

• edit funding
  • select funding amount per request
  • Select total funding amount
• set criteria
• shopkeeper validation
  • list of providers to fund
  • list of products to fund
  • allocation of funds
• Financial dashboard
  • overview over shops
  • Debts
  • Fund allocation
• Secondary sponsor
  • add fund to existing fund
  • allocate to different category

based on flowchart #15

Establish connection between docker containers of the records repository and IPFS records service

#51

The question has repeatedly came up: “will every sponsor have to open their own bunq account?” Implementation wise this will be a challenge. Also on the tech side, this means we have to make, maintain, secure and support many API connections. This is will be quite cumbersome.

The alternative is to open a bunq account ourselves. Of course this presents a challenge as well, but it also presents benefits: we can simply give a municipality our bank account number and a code to put in the description of payments (like coinbase) so we can automate the tracking of incoming money. Municipalities can increase their budgets proactively, or we can invoice them, which is closest to their current way of working. We will still give them a financial overview dashboard where they can see their “saldo”. It will also make it possible to support donations from parties that don’t have a bunq account. They can simply add funds with ideal or wire transfer.

To learn how (and if) this can work its important to study the feasibility. The main hurdles are in our own financial administration. We need to check what are the exact requirements to do this. We would, of course, not be the first (foundation) to do something like this. We also have the benefit that we can use the API to automate a lot of the administrative burden.

Hosting the money ourselves will heighten the guarantee off the availability of funds (what would happen in our system if the api connection of one of the x sponsors would stop working? Or if they lower the budget?). If we do this, it will be one of the main services that our foundation can offer. It will be a strong USP, since it significantly lowers the barrier to sponsorship.

Design API endpoints that implement the functionality as described in #2, #3, #4 and #5

The api will be used as the main way to connect to the platform while it is not yet practical for frontends and applications to connect directly to a fully decentralised backend (see #6 for details).

The documentation: https://github.com/teamforus/forus.io/blob/dev/docs/api.forus.io.md

After setting up a development environment #11 create a "Hello, World!" that implements:

See https://github.com/teamforus/forus/tree/master/docs#architecture for an overview

**Priority

• choose what the hello world will do
• set up containers
• deploy to aws

Dashboard

Select how much to fund / add funds

• select total funding
• set incentives for collaborators: validating and providing

Select who to fund ["criteria" - "value"]

• select validators for criteria ["criteria" - "validator(addr)"]

Select what to fund

• the person [just giving money]
• providers [ability to shop at certain shop]
• products [product - provider (/shop validated by)]
  • set maximum product value
• select allocation of funds (%)

Crowdfunding (available to the public, cannot edit fund)

• select fund
• select what to fund
• select amount to fund

Research on the possibilities of using RabbitMQ for communication between services

Read the full (dutch) document here

• Design API structure.
• Decide what to be developed in services and what in API
• Decide if SERVICES should be on PHP or NodeJS?

Expand the API and add a route for receiving a message, handle it by sending to the IPFS and Blockchain containers (services), and display back the previous messages

Let's push all wireframes and flowcharts to the docs folder of this repo.

• sponsor v0.1
• validator v0.1
• requester v0.1
• provider v0.1

How do you guys feel about seperating all the screens from all the wireframes? because there are alot of the same screens in all the wireframes and its easier to finish seperate frames than all in one go.

• big flowchart v0.1

Problem statement:

@jastam, @martijndoornik and @dev-weget are able to add new resources to the forus AWS console.

Proposed solution:

They add their service to AWS and have a meeting to combine those services in a web front end / api

• api router
• ipfs service
• ethereum service

Develop a front-end for the hello world application.

• Send message to the API
• Display history of messages

Research on the service for push notifications.

RabbitMQ / Websockets / other implementations

Some directions for getting started

The version we use is the Comunity Edition (https://www.docker.com/community-edition).

Get it from the docker store (https://store.docker.com/search?type=edition&offering=community).

Create an account for downloading, you will use this account for pushing images to hub.docker.com as well

These steps from the installation manual are important before you continue:

• Run "docker version" to check the version.
• Run "docker run hello-world" to verify that Docker can pull and run images. (and docker is actually working)

If the installation is successful i would suggest going through the general getting started first (https://docs.docker.com/docker-for-windows/, https://docs.docker.com/docker-for-mac/)

For building containers, follow the tutorial on docker compose (https://docs.docker.com/compose/gettingstarted/).
Once you understand the principles the Dockerfile reference becomes really useful (https://docs.docker.com/engine/reference/builder/)

Respond to validation request

• view requester identifying credential
  • bsn number / validated by government / digid
  • customer service number / validated by company
  • student number / validated by school
• enter relevant information
• validate and sign

Proactively validate information

• get requester address
• customer physically reveals address (qr code)
• target customer from address dictionary [bsn / address]

• Storage of the records data via IPFS (similar to the PHP/MySQL model)

• Using flowcharts and wireframes, design a v0.1 database architecture
• Discuss database design with Jasper

The oracle is an API for all "traditional" functionality. See the architecture for more context.

Functionality examples:

• bunq API
• KVK API
• DB Connections
• DigiD
• Emails
• Managing user accounts for users without a me app

We should decide what technology to use for it. Since we already implemented a lot of this functionality in the current PHP system, is it a good idea to also implement the oracle in PHP as well?

Note: We are not planning on taking this part into production, but it will help with our thinking process and to help form a picture what forus.io will do. Also, it will be the basis for the webshop extensions v2. In the architecture #13 this is the forus.io part under the me app.

Update the mvp wireframes here: https://github.com/teamforus/forus/blob/master/docs/forus.io.md

Based on #5

• registration
• business registration
• share business details kvk number
  -[X] login to dashboard
• see list of available funds per product
  • select products that can be provided
    • select quantity or availability
  • select the upper limit price
  • check price limit compared to sponsor limit

there is a bug in this dependency that could let attackers crash the application (Denial Of service attack).

Resources:
hapijs/hoek@32ed5c9
https://hackerone.com/reports/310439

• set up development environment on AWS @maxvisser
• give developers access to development environment @maxvisser

Select what to request

Provide necessary personal information (according to fund criteria)

• Popup "do you want to reveal xxx to Forus?"
  • maybe we can skip this step when everything is securely and
    privately handled on blockchain

Take steps to get missing information validated

• request digitally - from validator database or manual entry
• make appointment: receive validator / go to validator

Funding

• add extra funds (iDeal) if budget is inadequate

Confirm request

• if delivery confirm delivery address
• if pickup, learn pickup location

Receive requested good

• rate service
• rate product (after 1 day and after 3 months)

Share details

• Chamber of commerce number
• Provider display name
• Operational area
• Main categories

Add products / services to the platform

• See what products / services are being sponsored in your operational area
• Select the products / services that can be provided
• Select the price upper limit for the products / services
  • user will see the sponsored amount
    • if user sets higher amount sponsor will see that this provider needs
      higher funding
    • if user sets lower amount they will show up as a higher recommendation
      (ratings also get taken into a count here)
• Set availability for products related to fund (/ api link to inventory)
  • available (bool)
  • quantity (int)
• Add other products / services that can provided
  • when sponsorship ends, the selection from the previous step will go here

Provide product / service- Scan requester QR voucher code

• See the sponsored product / service + maximum value
• Select amount that product / service was delivered for
• Confirm and sign

Build the v0.1 of the repositories:

• Identity repository
• Records repository

We have two options for the MVP. Only the the exchange of value between sponsor and the provider happen on blockchain or all transaction happen on blockchain.

Dan, Jamal and me are liking the first option more; We see multiple pro's for this option for the MVP. I can do a summarization:

first option

only the exchange of value between sponsor and provider

pros

• token do not need any restriction, it is a truely issued back token and therefore a freely exchangable currency
• Migrating to mainnet is alot closer; privacy issues are of no concern. Currently the eth dev community is not working on any of our privacy issues (only on scalability and security). Timeframe to mainnet is maybe 1 a 2 years
• More traditional back-end means more stability

cons

• requesters are not self-souvereign / own their own tokens

second option

all transaction happen on blockchain

pros

• requester owns tokens and is more self-sovereign

cons

• this option can't migrate to mainnet until privacy issues are solved and therefore we are stuck on privatechain for an estimate of 5 years

Will update the structure a bit, to separate all elements that left, so we will have a services architecture within the main application as well.

• #52

• Create a URL for the documentation
• Export the documentation from Apiary
• Put the URL in Readme

(api.forus.io-ethereum) for https://github.com/teamforus/forus/tree/master/ETH and add it as a submodule to https://github.com/teamforus/forus @maxvisser

Research on the usage of IPFS and closing ports / environment

• set up IPFS node in docker container
• test out private network experimental feature
• try out interplanetary TestBed