Changes for restructuring the repo

.github/workflows/ci.yml

@@ -21,18 +21,18 @@ jobs:
 
     - name: Run Go Tests and Generate Merged Coverage
       run: |
-          cd onix && go test -coverprofile=coverage.out -coverpkg=./... ./...
+          go test -coverprofile=coverage.out -coverpkg=./... ./...
 
 
     - name: Convert merged coverage to HTML
       run: |
-          cd onix && go tool cover -html=coverage.out -o coverage.html
+          go tool cover -html=coverage.out -o coverage.html
 
     - name: Upload Go coverage report
       uses: actions/upload-artifact@v4
       with:
           name: go-coverage
-          path: onix/coverage.html
+          path: coverage.html
 
   build-go-binaries:
     name: Build Go Binaries
@@ -52,7 +52,7 @@ jobs:
 
     - name: Build
       run: |
-        cd onix/cmd/${{ matrix.service }}
+        cd cmd/${{ matrix.service }}
         go build -v -o ../../build/${{ matrix.service }} .
 
   build-docker-images:
@@ -72,8 +72,8 @@ jobs:
     - name: Build Docker Image
       uses: docker/build-push-action@v4
       with:
-        context: ./onix
-        file: ./onix/Dockerfile.${{ matrix.service }}
+        context: .
+        file: ./Dockerfile.${{ matrix.service }}
         platforms: linux/amd64
         push: false
         tags: ${{ matrix.service }}:latest
@@ -94,23 +94,23 @@ jobs:
       run: |
           python -m pip install --upgrade pip
           pip install coverage
-          pip install -r onix/deploy/onix-installer/backend/requirements.txt --require-hashes
+          pip install -r deploy/onix-installer/backend/requirements.txt --require-hashes
 
     - name: Run Python Tests with Coverage
       run: |
-          cd onix/deploy/onix-installer/backend
+          cd deploy/onix-installer/backend
           coverage run -m unittest discover tests
 
     - name: Generate Python coverage report
       run: |
-          cd onix/deploy/onix-installer/backend
+          cd deploy/onix-installer/backend
           coverage html -d htmlcov
 
     - name: Upload Python coverage report
       uses: actions/upload-artifact@v4
       with:
           name: python-coverage
-          path: onix/deploy/onix-installer/backend/htmlcov
+          path: deploy/onix-installer/backend/htmlcov
 
   build-frontend-installer:
     name: Build Angular Installer Frontend
@@ -126,23 +126,23 @@ jobs:
 
     - name: Install Dependencies
       run: |
-        cd onix/deploy/onix-installer/frontend
+        cd deploy/onix-installer/frontend
         npm install
 
     - name: Run Tests with Coverage
       run: |
-        cd onix/deploy/onix-installer/frontend
+        cd deploy/onix-installer/frontend
         npm test -- --watch=false --browsers=ChromeHeadless --code-coverage
 
     - name: Upload Frontend coverage report
       uses: actions/upload-artifact@v4
       with:
           name: frontend-coverage
-          path: onix/deploy/onix-installer/frontend/coverage
+          path: deploy/onix-installer/frontend/coverage
 
     - name: Build Frontend
       run: |
-        cd onix/deploy/onix-installer/frontend
+        cd deploy/onix-installer/frontend
         npm run build -- --configuration production
 
   deploy-pages:
@@ -208,4 +208,4 @@ jobs:
 
       - name: 'Build and Run onixctl'
         run: |
-          cd onix && go build ./cmd/onixctl && cd .. && ./onix/onixctl --config onix/deploy/onix-installer/adapter_artifacts/source.yaml
+          go build ./cmd/onixctl && ./onixctl --config deploy/onix-installer/adapter_artifacts/source.yaml

README.md

@@ -1,10 +1,8 @@
-# DPI Accelerator
+# DPI Accelerator - BECKN-ONIX
 
 This suite of open-source software accelerates the adoption of Digital Public Infrastructure (DPI). It provides a "DPI-as-a-Service" (DaaS) model with pre-packaged, cloud-ready components that allow nations to rapidly launch DPI pilots and bypass lengthy and costly traditional procurement and build cycles. The suite includes products like the Beckn Onix open network accelerator (GA) and ADK-based conversational agents (in private preview). Each deployment is an application layer innovation built on GCP stack, driving consumption of core infrastructure, data services, and advanced AI capabilities.
 
-The primary project in this repository is **Onix**, an accelerator for building and deploying [Beckn](https://becknprotocol.io/)-compliant networks on Google Cloud.
-
-## Onix: A Beckn Network Accelerator
+This project contains the core components for setting up a Beckn-compliant network, including the Registry, Gateway, BAP Adapter and BPP Adapter. It provides a foundational framework to facilitate seamless interaction and data exchange within the Beckn Protocol ecosystem.
 
 Onix is a complete solution for deploying a Beckn network on Google Cloud. 
 Beckn is an open protocol that enables location-aware, local commerce across industries. It allows consumers and providers to discover each other and engage in transactions on a decentralized network. This project implements the core components needed to create such a network. For a deeper dive into the reference implementation, visit the [official beckn-onix repository](https://github.com/Beckn-One/beckn-onix/).
@@ -21,23 +19,159 @@ It consists following:
 -   **Extensible Architecture**: A plugin-based system for adapters allows for custom logic and integrations.
 -   **Cloud Native**: Designed to run on Google Cloud, leveraging services like GKE, Cloud SQL, and Pub/Sub.
 
-
-For a more detailed technical overview of the Onix components, see the **[Onix Project README](./onix/README.md)**.
-
 ## Getting Started
 
-The recommended way to deploy Onix is through the UI-based Onix installer. For detailed prerequisites and instructions, please refer to the **[Onix Installer README](./onix/deploy/onix-installer/README.md)**.
+The recommended way to deploy Onix is through the UI-based Onix installer. For detailed prerequisites and instructions, please refer to the **[Onix Installer README](./deploy/onix-installer/README.md)**.
 
 ## Repository Structure
 
--   `onix/`: Contains the core Onix project.
-    -   `cmd/`: Main applications for each microservice.
-    -   `deploy/onix-installer/`: The UI-based installer (Angular frontend, FastAPI backend, Terraform and Helm for deployments).
-    -   `internal/`: Shared business logic for the Onix services.
-    -   `plugins/`: Source code for the extensible plugins used by the adapters.
-    -   `configs/`: Detailed example configuration files for each service.
-    -   `onixctl/`: A command-line tool for building adapter/plugin artifacts.
+-   `cmd/`: Main applications for each microservice.
+-   `deploy/onix-installer/`: The UI-based installer (Angular frontend, FastAPI backend, Terraform and Helm for deployments).
+-   `internal/`: Shared business logic for the Onix services.
+-   `plugins/`: Source code for the extensible plugins used by the adapters.
+-   `configs/`: Detailed example configuration files for each service.
+-   `onixctl/`: A command-line tool for building adapter/plugin artifacts.
+
+## High-Level Architecture
+
+Beckn-Onix is a cloud-native, microservices-based implementation of the Beckn protocol, designed to run on Google Cloud. It provides a robust and scalable foundation for building and operating a decentralized network.
+
+The system is composed of several containerized Go microservices running on Google Kubernetes Engine (GKE), which are deployed using the [**Onix installer**](./deploy/onix-installer/README.md).
+
+-   **Services**: The core logic is implemented in a set of Go microservices (Gateway, Registry, etc.).
+-   **Communication**: Services communicate synchronously via RESTful APIs and asynchronously through Google Cloud Pub/Sub for event-driven workflows.
+-   **Data Persistence**: The Registry relies on a Cloud SQL database to store network participant data.
+-   **Caching**: Redis is used for caching cryptographic keys and other frequently accessed data to improve performance.
+
+### Onix Architecture Diagrams
+
+**1. Core Onix Network (Admin, Gateway, Registry, Subscriber)**
+
+<img src="./docs/images/onix.png" alt="Core Network Services Architecture" width="700"/>
+
+---
+
+**2. Network Participant**
+
+<img src="./docs/images/onix-adapter.png" alt="Adapter Architecture" width="700"/>
+
+---
+
+### Technology Stack
+
+-   **Backend Services**: Go
+-   **Installer**: FastAPI (Python) backend, Angular (TypeScript) frontend
+-   **Infrastructure as Code**: Terraform
+-   **Application Deployment**: Helm
+-   **Containerization**: Docker
+-   **Orchestration**: Google Kubernetes Engine (GKE)
+-   **Database**: Cloud SQL for PostgreSQL
+-   **Messaging**: Google Cloud Pub/Sub
+-   **Caching**: Google Cloud Memorystore for Redis
+
+---
+
+## Core Services & API Endpoints
+
+Below is a detailed description of each core service and its primary API endpoints.
+
+### 1. Gateway
+
+The Gateway acts as the network's central message router. It decouples BAPs and BPPs, handling the fan-out of requests (like `search`) and the routing of subsequent messages. It relies on the Registry to determine BPPs to send messages.
+
+The Gateway exposes endpoints for Beckn actions. The specific action is determined by the request body's `context.action` field.
+
+| Method | Path         | Description                                                                                                                                                           |
+| :----- | :----------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `POST` | `/search`    | Handles the initial discovery request from a BAP.                                                                                                                     |
+| `POST` | `/on_search` | Receives `on_search` responses from BPPs and forwards them to the originating BAP.                                                                                      |
+| `GET`  | `/health`    | Returns the health status of the service.                                                                                                                             |
+
+### 2. Registry
+
+The Registry is the authoritative directory for the network. It stores and serves information about all trusted participants. Its key responsibility include: 
+* Storing public keys and network addresses of registered entities.
+* Enabling discovery of network participants by other components.
+* Ensuring the authenticity and security of communication within the network through cryptographic verification.
+
+| Method | Path                           | Description                                                                                                |
+| :----- | :----------------------------- | :--------------------------------------------------------------------------------------------------------- |
+| `POST` | `/subscribe`                   | Submits a subscription request from a new network participant. This initiates an asynchronous approval flow. |
+| `PATCH`  | `/subscribe`                   | Submits an update request for an existing network participant's details.                                   |
+| `POST` | `/lookup`                      | Queries the registry to find network participants based on specified criteria (e.g., domain, type).          |
+| `GET`  | `/operations/{operation_id}` | Retrieves the status of a long-running operation, such as a subscription request (`SUBSCRIBED`, `PENDING`).  |
+| `GET`  | `/health`                      | Returns the health status of the service.                                                                  |
+
+
+### 3. Registry Admin
+
+This service is the brain behind the participant lifecycle management. It operates asynchronously, consuming events from a message queue to process subscription requests, issue cryptographic challenges to verify participants, and ultimately approve or reject them.
+
+| Method | Path                 | Description                                                                                                                                                              |
+| :----- | :------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `POST` | `/operations/action` | An internal-facing endpoint, triggered by a Pub/Sub event. It processes subscription LROs, sending challenges and updating participant status in the Registry.             |
+| `GET`  | `/health`            | Returns the health status of the service.                                                                                                                                |
+
+### 4. Subscriber
+
+The Subscriber service provides a standardized API for any network participant (BAP, BPP, Gateway) to join the network. It handles the complexities of generating keys, submitting subscription requests to the Registry, and managing the challenge-response verification process.
+
+| Method | Path             | Description                                                                                                                                                           |
+| :----- | :--------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `POST` | `/subscribe`     | Initiates a subscription request to the Beckn Registry on behalf of a network participant.                                                                            |
+| `PATCH`  | `/subscribe`     | Initiates an update to a participant's subscription details in the Registry.                                                                                          |
+| `POST` | `/updateStatus`  | Checks the status of a subscription request by polling the Registry.                                                                                                  |
+| `POST` | `/on_subscribe` | The callback endpoint that receives the encrypted challenge from the Registry Admin. It must decrypt the challenge and return the correct answer to be approved. |
+| `GET`  | `/health`        | Returns the health status of the service.                                                                                                                             |
+
+### 5. Adapter (BAP/BPP)
+
+The Adapter is the interface between a traditional client application and the Beckn network. It acts as a translator, converting standard API calls into Beckn-compliant messages and vice-versa. It also handles the cryptographic signing and verification required for all network communication.
+
+You can refer to its implementation here - [Beckn-Onix](https://github.com/Beckn-One/beckn-onix)
+
+#### The Onix Installer can also deploy these adapters (along with their configured plugins), which can be configured to act as a BAP (Buyer App), a BPP (Provider App), or both, depending on the user's needs during the installation process.
+
+---
+
+## Configuration
+
+All Onix services are configured using YAML files. These files control everything from server ports and logging levels to database connections and timeouts. For a detailed reference of all available parameters for each service, please see the **[Onix Configuration README](./configs/README.md)**.
+
+---
+
+## `onixctl`: The Build & Packaging Tool
+
+onixctl is a command-line utility that prepares the Onix services and plugins for deployment. It reads a `source.yaml` file to understand the project structure, then automates the build and packaging process. Its key functions are:
+
+-   **Building Go Plugins**: Compiles adapter plugins into shared object (`.so`) files.
+-   **Building Docker Images**: Builds and pushes the Docker images for all microservices.
+-   **Packaging Artifacts**: Zips the compiled plugins into a deployable bundle for the installer if adapter is being deployed.
+
+## Plugin Architecture
+
+The Onix adapter is designed to be extensible and is based on plugin framework. You can add custom functionality without modifying the core adapter code by creating/switching and configuring plugins. Refer to this - [BECKN-ONIX Plugin Framework](https://github.com/Beckn-One/beckn-onix/blob/main/pkg/plugin/README.md).
+
+The following plugins are included with the GCP Onix:
+
+-   [`cachingsecretskeymanager`](./plugins/cachingsecretskeymanager/README.md): Caches cryptographic keys in redis to reduce latency.
+-   [`inmemorysecretkeymanager`](./plugins/inmemorysecretkeymanager/README.md): Caches cryptographic keys in a local in-memory store.
+-   [`pubsubpublisher`](./plugins/pubsubpublisher/README.md): Publishes Beckn messages to a Google Cloud Pub/Sub topic for asynchronous processing.
+-   [`rediscache`](./plugins/rediscache/README.md): Provides a distributed caching layer using Cloud Memorystore Redis.
+-   [`secretskeymanager`](./plugins/secretskeymanager/README.md): Manages cryptographic keys using a secure secret store like Google Secret Manager.
+
+---
+
+## Deployment (BECKN Onix GCP Installer)
+
+The entire Onix suite is deployed using this UI-based installer that automates and abstracts the entire process. The installer handles:
+
+1.  **Infrastructure Provisioning**: Uses Terraform to create the necessary GCP resources (GKE clusters, Cloud SQL, etc.).
+2.  **Application Deployment**: Uses Helm to deploy the Onix microservices onto the GKE cluster.
+
+For detailed prerequisites and step-by-step instructions, please refer to the **[Installer README](./deploy/onix-installer/README.md)**.
+
 
 ## Licensing
 
-This project is licensed under the Apache 2.0 License. See the [LICENSE](./LICENSE) file for details.
+This project is licensed under the Apache 2.0 License. See the [LICENSE](./LICENSE) file for details.

onix/cmd/admin/main.go → cmd/admin/main.go

@@ -28,13 +28,13 @@ import (
 	"syscall"
 	"time"
 
-	"github.com/google/dpi-accelerator/beckn-onix/internal/api/admin"
-	"github.com/google/dpi-accelerator/beckn-onix/internal/api/admin/handler"
-	"github.com/google/dpi-accelerator/beckn-onix/internal/client"
-	"github.com/google/dpi-accelerator/beckn-onix/internal/event"
-	"github.com/google/dpi-accelerator/beckn-onix/internal/log"
-	"github.com/google/dpi-accelerator/beckn-onix/internal/repository"
-	"github.com/google/dpi-accelerator/beckn-onix/internal/service"
+	"github.com/google/dpi-accelerator-beckn-onix/internal/api/admin"
+	"github.com/google/dpi-accelerator-beckn-onix/internal/api/admin/handler"
+	"github.com/google/dpi-accelerator-beckn-onix/internal/client"
+	"github.com/google/dpi-accelerator-beckn-onix/internal/event"
+	"github.com/google/dpi-accelerator-beckn-onix/internal/log"
+	"github.com/google/dpi-accelerator-beckn-onix/internal/repository"
+	"github.com/google/dpi-accelerator-beckn-onix/internal/service"
 
 	secretmanager "cloud.google.com/go/secretmanager/apiv1"
 	"github.com/beckn/beckn-onix/pkg/plugin/definition"

onix/cmd/admin/main_test.go → cmd/admin/main_test.go

@@ -19,11 +19,11 @@ import (
 	"testing"
 	"time"
 
-	"github.com/google/dpi-accelerator/beckn-onix/internal/client"
-	"github.com/google/dpi-accelerator/beckn-onix/internal/event"
-	"github.com/google/dpi-accelerator/beckn-onix/internal/log"
-	"github.com/google/dpi-accelerator/beckn-onix/internal/repository"
-	"github.com/google/dpi-accelerator/beckn-onix/internal/service"
+	"github.com/google/dpi-accelerator-beckn-onix/internal/client"
+	"github.com/google/dpi-accelerator-beckn-onix/internal/event"
+	"github.com/google/dpi-accelerator-beckn-onix/internal/log"
+	"github.com/google/dpi-accelerator-beckn-onix/internal/repository"
+	"github.com/google/dpi-accelerator-beckn-onix/internal/service"
 )
 
 func TestConfig_Valid_Success(t *testing.T) {