Tech stack & Technical roadmap

Tech stack

https://github.com/xuset/peer-relay (requires websocket or WebRTC support in the browser - see browser compatibilities)

http://www.scs.stanford.edu/~dm/home/papers/kpos.pdf

https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto (ledger and checks )

DHT (distributed hash table) to maintain network of active peer but not for ledgers

Browser compatibilities

WebSocket, as an IETF standard, and with a W3C browser API, is fully supported by all modern browsers:

• Chrome 16 + (incl. Chrome for Android)

• Firefox 11 + (incl. Firefox for Android)

• Internet Explorer 10+ (incl. Internet Explorer Mobile on Windows Phone 8)

• Safari 6 +

• Opera 12.1 + (incl. Opera Mobile)

• iOS 6.0 +

• Blackberry 7 +

WebRTC is supported by the following browsers:

• Desktop PC. Microsoft Edge 12+ Google Chrome 28+ Mozilla Firefox 22+ Safari 11+ Opera 18+ Vivaldi 1.9+

• Android. Google Chrome 28+ (enabled by default since 29) Mozilla Firefox 24+ Opera Mobile 12+

• Chrome OS.

• Firefox OS.

• BlackBerry 10.

• iOS. MobileSafari/WebKit (iOS 11+)

• Tizen 3.0.

Roadmap

Hackaton

• Build a prototype with the following functionalities:

  • Allow monetary transfers between peers in the network.

Post-hackaton

• Build an MVP with the following additional functionalities

  • Determine initial parameters which minimise the risk of 'pre-saturation' inflation. These parameters will be dependant on the size of the 'SuMSy economy' in relationship with the 'Euro economy'.

  • Generate the UBI for every account on a monthly basis.

  • Calculate and subtract demurrage before depositing UBI.

  • Implement fraud detection when initiating a transaction. The person making the transfer to the recipient has the option to allow the transaction even when fraud has been detected but this will be recorded in his ledger and thus visible to the next person he does a transaction with.

• Build an alpha version with the following additional functionalities

  • Share accounts between multiple stakeholders.

  • 'Lend out' demurrage free buffer 'chunks' to other accounts. Control of the 'chunk' remains with the original 'owner'.

  • Implement identity control so that each user can only register with the system once. As with fraud control, this will be partially technical and partially social.

• Build a stable, usable version which can be scaled up. Determine additional functionality which needs to be implemented.

Remarks

The entire project needs to be executed in an agile way. Parametrisation of SuMSy can not be fixed beforehand since we need to observe people's behaviour when the system is launched with its initial parameters. Our current assumption is that these parameters can be fixed but we can only be sure of that after running and observing the system with a chosen set of parameters. It is not uncommon to change the parameters of a monetary system while it's running though. Our current monetary system is constantly affected by changes in monetary policies which determine the parameters of the system. An example of this are the interest rates which are set by central banks.

Reference documents

https://medium.com/tezos/a-functional-nomenclature-of-cryptographic-ledgers-e836cb0e6864