Revert reason handling

.github/workflows/indy-besu.yml

@@ -2,7 +2,7 @@ name: CI
 
 on:
   pull_request:
-    paths: "indy-besu/**"
+    paths: "**"
 
   workflow_dispatch:
 
@@ -18,10 +18,10 @@ jobs:
           node-version: "20.x"
       - name: Install dependencies
         run: yarn install
-        working-directory: indy-besu/smart_contracts
+        working-directory: smart_contracts
       - name: Lint
         run: yarn lint-check
-        working-directory: indy-besu/smart_contracts
+        working-directory: smart_contracts
 
   test-contracts:
     needs: lint-contracts
@@ -35,16 +35,15 @@ jobs:
           node-version: "20.x"
       - name: Install dependencies
         run: yarn install
-        working-directory: indy-besu/smart_contracts
+        working-directory: smart_contracts
       - name: Unit tests
         run: yarn test
-        working-directory: indy-besu/smart_contracts
+        working-directory: smart_contracts
       - name: Run localnet
         run: ./network/scripts/run.sh && sleep 40
-        working-directory: indy-besu
       - name: Demos
         run: yarn demos
-        working-directory: indy-besu/smart_contracts
+        working-directory: smart_contracts
 
   lint-vdr:
     runs-on: ubuntu-latest
@@ -57,7 +56,7 @@ jobs:
           toolchain: stable
       - name: Lint
         run: cargo fmt --check
-        working-directory: indy-besu/vdr
+        working-directory: vdr
 
   store-artifacts:
     needs: lint-vdr
@@ -71,15 +70,15 @@ jobs:
           node-version: "20.x"
       - name: Install dependencies
         run: yarn add hardhat
-        working-directory: indy-besu/smart_contracts
+        working-directory: smart_contracts
       - name: Compile smart contracts
         run: yarn compile
-        working-directory: indy-besu/smart_contracts
+        working-directory: smart_contracts
       - name: Archive contract artifacts
         uses: actions/upload-artifact@v3
         with:
           name: smart-contracts-artifacts
-          path: indy-besu/smart_contracts/artifacts/**
+          path: smart_contracts/artifacts/**
           retention-days: 3
 
   test-vdr:
@@ -96,10 +95,9 @@ jobs:
         uses: actions/download-artifact@v3
         with:
           name: smart-contracts-artifacts
-          path: indy-besu/smart_contracts/artifacts
+          path: smart_contracts/artifacts
       - name: Run localnet
         run: ./network/scripts/run.sh && sleep 40
-        working-directory: indy-besu
       - name: Test
         run: cargo test --features=ledger_test -- --test-threads=1
-        working-directory: indy-besu/vdr
+        working-directory: vdr

CONTRIBUTING.md

@@ -0,0 +1,13 @@
+## How to contribute
+
+You are encouraged to contribute to the repository by **forking and submitting a pull request**.
+
+For significant changes, please open an issue first to discuss the proposed changes to avoid re-work.
+
+(If you are new to GitHub, you might start with a [basic tutorial](https://help.github.com/articles/set-up-git) and check out a more detailed guide to [pull requests](https://help.github.com/articles/using-pull-requests/).)
+
+Pull requests will be evaluated by the repository guardians on a schedule and if deemed beneficial will be committed to the master. Pull requests should have a descriptive name and include an summary of all changes made in the pull request description.
+
+If you would like to propose a significant change, please open an issue first to discuss the work with the community.
+
+All contributors retain the original copyright to their stuff, but by contributing to this project, you grant a world-wide, royalty-free, perpetual, irrevocable, non-exclusive, transferable license to all users **under the terms of the license under which this project is distributed.**

LICENSE

@@ -1,3 +1,4 @@
+
                                  Apache License
                            Version 2.0, January 2004
                         http://www.apache.org/licenses/
@@ -175,18 +176,8 @@
 
    END OF TERMS AND CONDITIONS
 
-   APPENDIX: How to apply the Apache License to your work.
-
-      To apply the Apache License to your work, attach the following
-      boilerplate notice, with the fields enclosed by brackets "[]"
-      replaced with your own identifying information. (Don't include
-      the brackets!)  The text should be enclosed in the appropriate
-      comment syntax for the file format. We also recommend that a
-      file or class name and description of purpose be included on the
-      same "printed page" as the copyright notice for easier
-      identification within third-party archives.
-
-   Copyright [yyyy] [name of copyright owner]
+   Copyright 2017 Sovrin Foundation
+   Copyright 2020 Province of British Columbia
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
@@ -198,4 +189,4 @@
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
-   limitations under the License.
+   limitations under the License.

MAINTAINERS.md

@@ -0,0 +1,99 @@
+# Maintainers
+
+<!-- Please keep all lists sorted alphabetically by github -->
+
+## Active Maintainers
+
+| Name                | Github             | LFID |
+|---------------------|--------------------|------|
+| Artem Ivanov        | Artemkaaas         |      |
+| Renata Toktar       | Toktar             |      |
+| Alexander Sherbakov | ashcherbakov       |      |
+| Wade Barnes         | WadeBarnes         |      |
+
+## Becoming a Maintainer
+
+Indy-Besu welcomes community contribution.
+Each community member may progress to become a maintainer.
+
+How to become a maintainer:
+
+- Contribute significantly to the code in this repository.
+
+### Maintainers contribution requirement
+
+The requirement to be able to be proposed as a maintainer is:
+
+- 5 significant changes on code have been authored in this repos by the proposed maintainer and accepted (merged PRs).
+
+### Maintainers approval process
+
+The following steps must occur for a contributor to be "upgraded" as a maintainer:
+
+- The proposed maintainer has the sponsorship of at least one other maintainer.
+    - This sponsoring maintainer will create a proposal PR modifying the list of
+      maintainers. (see [proposal PR template](#proposal-pr-template).)
+    - The proposed maintainer accepts the nomination and expresses a willingness
+      to be a long-term (more than 6 month) committer by adding a comment in the proposal PR.
+    - The PR will be communicated in all appropriate communication channels
+      including at least [indy-contributors channel on Hyperledger Discord](https://discord.gg/hyperledger),
+      the [mailing list](https://lists.hyperledger.org/g/indy)
+      and any maintainer/community call.
+- Approval by at least 3 current maintainers within two weeks of the proposal or
+  an absolute majority (half the total + 1) of current maintainers.
+    - Maintainers will vote by approving the proposal PR.
+- No veto raised by another maintainer within the voting timeframe.
+    - All vetoes must be accompanied by a public explanation as a comment in the
+      proposal PR.
+    - A veto can be retracted, in that case the voting timeframe is reset and all approvals are removed.
+    - It is bad form to veto, retract, and veto again.
+
+The proposed maintainer becomes a maintainer either:
+
+- when two weeks have passed without veto since the third approval of the proposal PR,
+- or an absolute majority of maintainers approved the proposal PR.
+
+In either case, no maintainer raised and stood by a veto.
+
+## Removing Maintainers
+
+Being a maintainer is not a status symbol or a title to be maintained indefinitely.
+
+It will occasionally be necessary and appropriate to move a maintainer to emeritus status.
+
+This can occur in the following situations:
+
+- Resignation of a maintainer.
+- Violation of the Code of Conduct warranting removal.
+- Inactivity.
+    - A general measure of inactivity will be no commits or code review comments
+      for two reporting quarters, although this will not be strictly enforced if
+      the maintainer expresses a reasonable intent to continue contributing.
+    - Reasonable exceptions to inactivity will be granted for known long term
+      leave such as parental leave and medical leave.
+- Other unspecified circumstances.
+
+As for adding a maintainer, the record and governance process for moving a
+maintainer to emeritus status is recorded using review approval in the PR making that change.
+
+Returning to active status from emeritus status uses the same steps as adding a
+new maintainer.
+
+Note that the emeritus maintainer always already has the required significant contributions.
+There is no contribution prescription delay.
+
+## Proposal PR template
+
+```markdown
+I propose to add [maintainer github handle] as a Indy-Besu project maintainer.
+
+[maintainer github handle] contributed with many high quality commits:
+
+- [list significant achievements]
+
+Here are [their past contributions on Indy-Besu project](https://github.com/hyperledger/indy-besu/commits?author=[user github handle]).
+
+Voting ends two weeks from today.
+
+For more information on this process see the Becoming a Maintainer section in the MAINTAINERS.md file.
+```

README.md

@@ -2,38 +2,40 @@
 
 ## Goals and ideas
 
-* Provide a replacement for [Hyperledger Indy](https://www.hyperledger.org/projects/hyperledger-indy) ecosystem that provides support for verifiable credentials:
-  * Components to replace:
-    * Distributed ledger: [Indy Node](https://github.com/hyperledger/indy-node) and [Indy Plenum](https://github.com/hyperledger/indy-plenum)
-    * Client library: [Indy SDK](https://github.com/hyperledger/indy-sdk/tree/main)
-  * Capability to migrate the data from the original Indy Ledger
+* Provide a replacement for [Hyperledger Indy](https://www.hyperledger.org/projects/hyperledger-indy) ecosystem that
+  provides support for verifiable credentials:
+    * Components to replace:
+        * Distributed ledger: [Indy Node](https://github.com/hyperledger/indy-node)
+          and [Indy Plenum](https://github.com/hyperledger/indy-plenum)
+        * Client library: [Indy SDK](https://github.com/hyperledger/indy-sdk/tree/main)
+    * Capability to migrate the data from the original Indy Ledger
 * Distributed ledger requirements:
-  * Public Permissioned Blockchain
-    * Control the validator nodes 
-    * Control the user permissions
-  * EVM compatible Blockchain
-    * Capability to deploy on different networks
-  * Based on existing open-source blockchain framework with a good performance, sufficient adoption, and wide community
-  * Capability to work without tokens and fees
-  * Stable consensus protocol
+    * Public Permissioned Blockchain
+        * Control the validator nodes
+        * Control the user permissions
+    * EVM compatible Blockchain
+        * Capability to deploy on different networks
+    * Based on existing open-source blockchain framework with a good performance, sufficient adoption, and wide
+      community
+    * Capability to work without tokens and fees
+    * Stable consensus protocol
 * Functional requirements:
-  * Interoperability:
-    * Capability to use existing DID's and identifiers:
-      * Support [indy](https://hyperledger.github.io/indy-did-method/) DID method  
-      * Support [sov](https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html) DID method
-      * Identifiers previously stored on the client side should be resolvable on the new Ledger
-    * Capability to use the ledger as an [AnonCreds Registry](https://hyperledger.github.io/anoncreds-methods-registry/)
-    * Compatibility with the latest [AnonCreds Specification](https://hyperledger.github.io/anoncreds-spec/)
-  * Extensibility: 
-    * Capability to integrate new pieces of functionality easily
-    * Capability to use [ETHR](https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md) DID method
-      * Integration with the [AnonCreds Registry](https://hyperledger.github.io/anoncreds-methods-registry/)
-      * Integration with `Permissioned` modules
-  * Data validity:
-    * Neglect `gas` efficiency in favour general validation of the stored data
-      * Basic [DID Documents](https://www.w3.org/TR/did-core/) validation
-      * Basic [AnonCreds entities](https://hyperledger.github.io/anoncreds-spec/#anoncreds-setup-data-flow) validation
-      * Basic state consistency validation
+    * Interoperability:
+        * Capability to use existing DID's and identifiers:
+            * Support [indy](https://hyperledger.github.io/indy-did-method/) DID method
+            * Support [sov](https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html) DID method
+            * Identifiers previously stored on the client side should be resolvable on the new Ledger
+        * Capability to use the ledger as
+          an [AnonCreds Registry](https://hyperledger.github.io/anoncreds-methods-registry/)
+        * Compatibility with the latest [AnonCreds Specification](https://hyperledger.github.io/anoncreds-spec/)
+    * Extensibility:
+        * Capability to integrate new pieces of functionality easily
+        * Capability to
+          use [ETHR](https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md) DID
+          method
+            * Integration with the [AnonCreds Registry](https://hyperledger.github.io/anoncreds-methods-registry/)
+            * Integration with `Permissioned` modules
+    * Do only basic state consistency validation
 
 ## Design documentation
 
@@ -45,7 +47,10 @@ See [design document](./docs/README.md) covering the main ledger aspects.
 
 - [Docker and Docker-compose](https://docs.docker.com/compose/install/) v2 or higher
 
-> ⚠️ **Note**: If on MacOS or Windows, please ensure that you allow docker to use upto 4G of memory under the _Resources_ section. The [Docker for Mac](https://docs.docker.com/docker-for-mac/) and [Docker Desktop](https://docs.docker.com/docker-for-windows/) sites have details on how to do this at the "Resources" heading
+> ⚠️ **Note**: If on MacOS or Windows, please ensure that you allow docker to use upto 4G of memory under the
+_Resources_ section. The [Docker for Mac](https://docs.docker.com/docker-for-mac/)
+> and [Docker Desktop](https://docs.docker.com/docker-for-windows/) sites have details on how to do this at the "
+> Resources" heading
 
 ### Commands
 
@@ -57,7 +62,7 @@ See [design document](./docs/README.md) covering the main ledger aspects.
     ```bash
     ./network/scripts/run.sh --blockscout
     ```
-    or
+  or
     ```bash
     ./network/scripts/run.sh -b
     ```
@@ -76,4 +81,20 @@ See [design document](./docs/README.md) covering the main ledger aspects.
 
 See [README.md](/smart_contracts/README.md).
 
+## Client library
 
+[Rust library](./vdr/README.md) representing a convenient client for connecting to an Indy-Besu node, building and
+executing transactions and queries.
+
+## Contributing
+
+Pull requests are welcome! Please read our [contributions guide](./CONTRIBUTING.md)
+and submit your PRs. We enforce [developer certificate of origin](https://developercertificate.org/) (DCO) commit
+signing. See guidance [here](https://github.com/apps/dco).
+
+We also welcome issues submitted about problems you encounter in using
+`Indy-Besu`, `VDR` or any of the VDR wrappers.
+
+## License
+
+[Apache License Version 2.0](./LICENSE)

SECURITY.md

@@ -0,0 +1,11 @@
+# Hyperledger Security Policy
+
+## Reporting a Security Bug
+
+If you think you have discovered a security issue in any of the Hyperledger projects, we'd love to hear from you. We will take all security bugs seriously and if confirmed upon investigation we will patch it within a reasonable amount of time and release a public security bulletin discussing the impact and credit the discoverer.
+
+There are two ways to report a security bug. The easiest is to email a description of the flaw and any related information (e.g. reproduction steps, version) to [security at hyperledger dot org](mailto:[email protected]).
+
+The other way is to file a confidential security bug in our [JIRA bug tracking system](https://jira.hyperledger.org). Be sure to set the “Security Level” to “Security issue”.
+
+The process by which the Hyperledger Security Team handles security bugs is documented further in our [Defect Response page](https://wiki.hyperledger.org/display/HYP/Defect+Response) on our [wiki](https://wiki.hyperledger.org).