# Glossary

## *<mark style="color:blue;">**A**</mark>*

### **Access Layer**

The entry point for dApps to send and receive encrypted messages via the SendingNetwork SDK.

***

## *<mark style="color:blue;">**C**</mark>*

### Client

A user-facing application that interfaces with client nodes, integrating end-to-end encryption for secure message transmission and reception.

### Client Node

Acts as intermediaries in the network, facilitating client-server model-based communication and securely storing encrypted communication history. There are three type of client nodes in the network, [Local node](#local-mode), [Delegation node](#delegation-mode) and [Private node](#private-node).

### **Consensus Layer**

Involves Guardian Nodes that manage a Layer 2 blockchain, verify work proofs, and assess Edge node performance based on data from WatchDog Nodes.

***

## *<mark style="color:blue;">**D**</mark>*

### Delegation Mode

Enables the application developer to host a node which the users can trust for login, messaging, and data storage.

### Decentralized Identifiers (DIDs)

Digital identities that allow users to manage their identities autonomously without centralized authority, enhancing security and verifiability in communications .

### DM Room

A DM room is a private room designed for a maximum of two members.

***

## *<mark style="color:blue;">**E**</mark>*

### **Edge Nodes**

Nodes that relay message via p2p protocol, incentivized by [Proof of Relay](#proof-of-relay) mechanism.

### End-to-end encryption

A method of securing data by encrypting it on the sender's side and only decrypting it on the recipient's side, preventing unauthorized access during transmission.

***

## *<mark style="color:blue;">**G**</mark>*

### **Guardian Nodes**

Verify work proofs from nodes, sequence transactions, and evaluate Edge nodes' performance via [Proof of Availability](#proof-of-availability). Also, they maintain the protocol-specific layer 2 blockchain.

***

## *<mark style="color:blue;">**L**</mark>*

### **Layer 2 Blockchain**

Maintained by Guardian Nodes to enhance transaction processing and validation off the main chain for improved scalability and efficiency.

***

## *<mark style="color:blue;">**P**</mark>*

### Private Mode

Supports developer-hosted private nodes specifically designed for exclusive use by whitelisted users.

### **Proof of Relay**

Validates Edge Nodes' message forwarding activities, ensuring authentication of each relay.

### **Proof of Availability**

Used by Guardian Nodes to evaluate Edge Nodes' performance and availability.

### Local Mode

A fully decentralized option where the users run P2P nodes on their client devices, storing messages locally.

### Public Room

Users can either join the chat room using the room ID on their own, or they can jump in with an invite.

### Private Node

Customized [Delegation node](#delegation-mode) that enables developers to incorporate tailored features and facilitate on-premise deployments.

### Private Room

By Invitation Only. Only admins can send out invites for people to join the chat room, and regular users can't just use the room ID to request to join.

***

## *<mark style="color:blue;">**R**</mark>*

### **Relay Layer**

Contains Edge Nodes that facilitate the relay of messages between the Access and Consensus layers, ensuring proper message delivery.

### Room ID

A unique identifier assigned to a specific room.

***

## *<mark style="color:blue;">**U**</mark>*

### User ID

A unique identifier assigned to a specific user.

***

## *<mark style="color:blue;">**W**</mark>*

### **WatchDog Nodes**

Nodes in SendingNetwork that monitor the performance and reliability of Edge Nodes, ensuring network integrity.

***

## *<mark style="color:blue;">**Z**</mark>*

### **Zero-Knowledge Proofs**

Cryptographic techniques that allow one party to prove the truth of a statement to another party without revealing any additional information beyond the validity of the statement itself. Edge Nodes uses zk proofs to prove their handling of messages without revealing content, saving gas fees and compressing the data size.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://sending-network.gitbook.io/sending.network/sdk-documentation/glossary.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.