Manuel D'Orso

We can leverage many existing decentralized applications to create organizations implementing models that can better us as producers and consumers under capitalism. A possible way to do so is what I am proposing here: this model aims to help implementing a reproducible decentralized organization for purchasing groups, that is a group of people cooperating to buy a variety of products directly from producers, both for economical and environmental reasons.

I am assuming the reader as familiar with decentralized applications, cryptocurrencies and the like so I can cut to the chase.

TL;DR: find a mindmap here

The system leverages a variety of components that can work in a decentralized manner as a way to avoid the burden of a formal cooperative or other organization and let users totally self-manage and self-operate. Let's find out what these components are and how they work together.

• Status is a modern chat application integrating an Ethereum wallet and a DApp-enabled browser. It comes in the form of an Android or iOS app, easy to configure and use. Those features themselves cover a big chunk of the capabilities needed for our kind of purchasing groups: group communication and a way for users to send and receive money. What else is great about Status? You can directly use DApps from it, like Aragon.

• Aragon is a platform to host DAOs on. The nice thing is that it enables to effortlessly create DAOs from templates, with very useful pre-installed features, called apps. For instance, we can use the Membership template to mint our very own tokens, and use them to identify the group members making them non-transferable. The Finance app allows the organizatoin to have a cryptocurrency fund to be used as our purchasing group's cooperative fund. While the Voting app lets token holders cast votes, a functionality that in our case can be used to let members confirm buying orders. Conveniently, a successful vote can also (via a smart contract) directly trigger a cryptocurrency payment.

• While the buying group can virtually buy anything, it is easier to deal in terms of digital goods, that can be directly accessed with the same devices we are using to intract with the purchasing group. To keep the whole system decentralized we can leverage IPFS (InterPlanetary FileSystem), that is a decentralized file storage protocol the group can use to collectively host files and even a static website.

• The last, but not less important, component is a marketplace that lets producers create listings for the products they want to offer to buying groups. This marketplace should enable buying and selling of digital assets in ETH, searching and filtering offers and everything we are used to in ecommerce. The perfect fit for the need is District0x, a DApp which has under the hood the same solid technologies we are considering here (Aragon, Ethereum and IPFS).

This model is easily implementable, since the only costs are a few ether cents in gas fees for the DApps and, if we want to, a small server to host an always-on IPFS node, even at home. Configuration is also easy since we are making use of basic functionalities of each of our components. The hardest part, let's face it, is always adoption: we have to bring producers and consumers, buyers and sellers on the cryptocurrency side. However is my firm belief that the best way to raise adoption is experimenting until something moves in the right direction for good.

Everything we saw has been briefly tested and will probably be converted in a PoC soon. The only exception is District0x's marketplaces, which are not ready to be directly brought up yet. I plan to update this post with a PoC and meanwhile AMA on my fediverse profile @cirku17@mastodon.bida.im .

This is a DevSecOps methodology to write down security requirements for an application in the form of a security.feature file, written in the Gherkin language. This way you can – update and version control SRs during development – check if SRs are met during CI/CD or visually during code reviews

A good framework to write security requirements to be consumed during development and/or testing is OWASP Application Security Verification Standard.

Example

Feature: Security Requirements

  # ASVS 2.1.1
  Rule: Verify that user set passwords are at least 12 characters in length.

    @Met
    Scenario: A user is registering
      Given the main registration form
      When a user fills the password field
      Then the validator should allow a minumum lenght of 12
  
    @Unmet
    Scenario: An administrator is creating a new guest user account
      Given the "New Guest User" form
      When a user fills the temporary password field
      Then the validator should allow a minumum lenght of 12

The methodology is simple: – Write requirements as Rules (refering to ASVS as comments when possible) – Provide at least an Example or Scenario for each requirement – Tag Scenarios or the whole Rule with the implementation status (Met, Unmet, UnderDevelopment etc)

It is easier to use a single file with multiple Rules or Scanarios, but you can write multiple files with one Feature each as well (i.e. for different software components).

Redact the security.feature file during design and then update it at each iteration and/or during code review. The methodology is flexible enough to fit every software security maturity level.

Checking SR status during CI/CD

A simple script involving the gherkin parser can read the feature file and list tags for each Scenario or even calculate the percentage of met SR compared to the total.