Internal Module (Generic) Architecture

An Internal Module's generic architecture looks like this:

Its constituent parts are:

• NOSTR (optional) : the main asynchronous NOSTR interface via which to publish and subscribe to the main NOSTR backbone.
• Synchronous Nostr (optional) : a synchronous REST API that accepts a NOSTR event and synchronously acts upon it.
• Ad-Hoc REST API (optional) : a set of ad-hoc REST API endpoints to support non-NOSTR-based flows.
• Internal NOSTR Relay (optional) : an optional part of the Internal Module's architecture, its purpose is to act as a sort of "local read-only replica", so as to reduce the pressure on the main Local NOSTR Relay whilst at the same time providing all the required REQ subscriptions to the module's Business Logic.
• Resources (optional) : an Internal Module is free to declare and use as many resources as it sees fit, they're their sole responsibility and the System Architecture at large knows not about them.
• Business Logic: the Internal Module's business logic component realizes the module's purpose (it may contain an internal router, expose different sets of ports for different APIs, whatever the Internal Module's writer desires, so long as the API Gateway knows how to interact with it).

ALL Internal Modules are required to answer to (at least) one NOSTR Public Key. Furthermore, the API Gateway needs to know how to route HTTP requests to the appropriate internal module.

In what follows, we'll assume that all Internal Modules implicitly know the public keys every other internal module responds to; furthermore, we'll assume all internal modules implicitly know how to route HTTP requests to the appropriate internal modules.