update.

docs/immortal/code/database.md

@@ -10,10 +10,8 @@ Each nostr event kind has a different collection on mongo db database. This help
 
 ## Queries
 
-When immortal wants to query something from mongo db, its basically a filter. The immortal turns the normal filter and makes `n` mongo queries. `n` is the number of kind numbers in filter. it would attach the whole conditions of filter to each query and execute the queries. Currently queries are sent separately which is inefficient, we are working on it to support batch queries or increase the performance.
-
-> The special case is when someone requests a filter without kinds field, in this case immortal makes a request to some papular collections like reactions, short text notes, zaps and some more.
+When immortal wants to query something from mongo db, its basically a filter. The immortal turns the normal filter and makes `n` mongo queries. Then we use the mongo db aggregation pipeline and `$unionWith` stage to query all requested collections. If you kinds was provided it will query all tables.
 
 ## Deleting
 
-To delete some document for a NIP-09 request or Expiration or operator order from manager, we make ALL fields removed (not empty!) and we only keep the id of event. this helps us to prevent an deleted event be rewritten.
+To delete some document for a NIP-09 request or Expiration or operator order from manager, we set all fields `null` using `$unset` mongo command and we only keep the `id` of event. this helps us to prevent an deleted event be rewritten or returned to user.

docs/immortal/managment/apis.md

@@ -11,15 +11,15 @@ Here is a list of APIs between manager and immortals. All of these APIs are thro
 
 Here is a list of APIs which is provided by manager and relay calls them:
 
-###  registerService
+###  RegisterService
 
 The relays call this endpoint to receive an ID (a unique id between all relays in the same system for manager to identify them). 
 
 Here is an example of register request:
 
 ```proto
 // Request to register a service.
-message registerServiceRequest {
+message RegisterServiceRequest {
   string port = 1;                        // Service grpc port.
   uint32 heartbeat_duration_in_sec = 2;   // Heartbeat interval in seconds for calling Status endpoint of relay.
   ServiceTypeEnum type = 3;               // Type of the service. (e.g., RELAY)
@@ -31,7 +31,7 @@ Response example:
 
 ```proto
 // Response after registering a service.
-message registerServiceResponse {
+message RegisterServiceResponse {
   bool success = 1;                      // Indicates if registration was successful.
   optional string message = 2;           // Optional message with additional information.
   string token = 3;                      // Token assigned to the registered service.
@@ -40,22 +40,22 @@ message registerServiceResponse {
 
 > Relay will send the id in the header of `x-identifier` in each request to manager. this helps the manager to know who is talking with and take different actions for same request but different relays.
 
-### getConfig
+### GetParameters
 
 Relays will call this endpoint to get the parameters config from manager which requires the `x-identifier` header as well.
 
 Request example:
 
 ```proto
 // Empty request used for methods that do not require parameters.
-message EmptyRequest {}
+message GetParametersRequest {}
 ```
 
 Response example:
 
 ```proto
 // Response containing configuration details.
-message getConfigResponse {
+message GetParametersResponse {
   limitations limitations = 1;           // Configuration limitations.
   string url = 2;                        // Relay public URL.
 }
@@ -68,7 +68,6 @@ Types used:
 message limitations {
   int32 max_message_length = 1;          // Maximum allowed message length.
   int32 max_subscriptions = 2;           // Maximum number of subscriptions allowed.
-  int32 max_filters = 3;                 // Maximum number of filters allowed.
   int32 max_subid_length = 4;            // Maximum length of a subscription ID.
   int32 min_pow_difficulty = 5;          // Minimum proof-of-work difficulty.
   bool auth_required = 6;                // Indicates if authentication is required.
@@ -90,16 +89,27 @@ enum ServiceTypeEnum {
 }
 ```
 
+### AddLog
 
-### shutdown
+Relays may send system level logs to manager.
 
-> TODO.
+```proto
+message AddLogRequest {
+  string message = 1;                   
+  string stack = 2;                      
+}
+```
 
-### addLog
+Response example:
 
-> TODO.
+```proto
+message AddLogResponse {
+  bool success = 1;               
+  optional string message = 2;         
+}
+```
 
-## Relay to Manager
+## Manager to Relay
 
 Here is a list of APIs provided by relays which would be called by managers:
 
@@ -147,4 +157,14 @@ The manager can show the response in a monitoring system, make notifications, sh
 
 ### Shutdown
 
-> TODO.
+Manager can send a shutdown signal to each relay independently.
+
+```proto
+message ShutdownRequest {}
+```
+
+Response example:
+
+```proto
+message ShutdownResponse {}
+```

docs/immortal/managment/manager.md

@@ -4,7 +4,7 @@ sidebar_position: 2
 
 # Manager
 
-This section contains the information about the manager rules and responsibilities. To findout how relays interact with manager and vice versa you can check the [APIs](./apis.md) section.
+This section contains the information about the manager rules and responsibilities. To find out how relays interact with manager and vice versa you can check the [APIs](./apis.md) section.
 
 ## White/Black Listing
 

docs/immortal/nips/nip-09.md

@@ -5,3 +5,5 @@ sidebar_position: 2
 # NIP-09
 
 The NIP-09 follows normal NIP-09 from NIPs repository and also supports filter tag requests from this document: https://github.com/nostr-protocol/nips/pull/1509.
+
+> TODO: add its limitations.

docs/immortal/nips/nip-56.md

@@ -4,5 +4,4 @@ sidebar_position: 4
 
 # NIP-56
 
-Reports are supported on immortal but it won't be processed by relays code and relays only store and broadcast them. The manager will read the report events from database and list them for operator review. There is no support for trusted moderators at the moment.
-
+Reports are supported on immortal but it won't be processed by relays code and relays only store and broadcast them. The manager will receive them from immortal instances through gRPC calls. There is no support for trusted moderators at the moment.