Decentralized chatting method and system

Abstract

The invention provides a decentralized chatting method and system, and the method comprises the steps: designing a plurality of data nodes, and enabling the data nodes to manage corresponding clients respectively; for clients under different data nodes, messages are sent to a receiver from the data node of the receiver; and when clients with different data nodes exist in the group, after a group message is generated, all the corresponding data nodes receive the group message and forward the group message to all the corresponding clients belonging to the group. According to the decentralized chatting method and system provided by the invention, the client is independently managed by building the data node, and the information of the client is only stored in the data node, so that the security of the internal information is ensured; according to the method, friend addition and group establishment are limited, and smooth communication is ensured while a communication channel is established; in the invention, the information interaction among the clients under different data nodes is also forwarded by each data node, so that the information security is further ensured.

Description

Technical Field

[0001] The present invention relates to the field of Internet technology, and in particular to a decentralized chat method and system thereof. Background Art

[0002] After the development in the communications field in recent years, the functions of communication software have become more and more. However, many times companies worry about the leakage of chat content, so they need to manage it strictly. Although files can be encrypted internally and sent out, the edited text often contains key information and is also part of the need for management. This requires a confidential chat tool. Summary of the Invention

[0003] The purpose of the present invention is to overcome the shortcomings of the prior art and provide a decentralized chat method and system to solve the above problems.

[0004] The purpose of the present invention is achieved through the following technical solutions: In a first aspect, the present invention provides a decentralized chat method, comprising the following steps: S1. Design several data nodes, each of which manages the corresponding client; S2, message management step: The data node stores the corresponding client's information and helps the corresponding client store offline messages; S3. Message sending step: Messages between clients on the same data node are sent directly. For clients on different data nodes, the sender first sends the message to the recipient's data node, which then forwards the message to the recipient. S4. Group message sending step: When all clients in the group are clients of the same data node, the information is forwarded by the data node; when there are clients of different data nodes in the group, after the group message is generated, all corresponding data nodes will receive the group message, and the data nodes will forward the group message to all corresponding clients belonging to the group.

[0005] Furthermore, it also includes a client friend management step: clients on the same data node are automatically added as node friends; clients can also add basic friends. The initiator queries the ID of other clients and adds the other party to the basic friends in a unidirectional manner. Basic friends and node friends are listed in parallel friend columns.

[0006] Furthermore, it also includes a group building step: building a group between clients of the same data node does not require approval from the data node; building a group between clients of different data nodes requires approval from all corresponding data nodes.

[0007] Furthermore, an audit-free mechanism can be established between the data nodes, and no audit is required when the client creates a group.

[0008] Furthermore, it also includes a central server, which is used to register users and write the user's identity public key into the blockchain.

[0009] Furthermore, the client registration step is also included: T1. The client provides basic information and identity public key to the central server; T2. The central server assigns a UID to the client and asynchronously writes the UID and identity public key into the blockchain; T3. The central server returns the status to the client, and the data node and client can subsequently query it on the public blockchain.

[0010] Furthermore, the client login step is also included: R1. Data nodes register their own network information on the blockchain in advance; R2. The client selects a data node and accesses the data node pre-login interface to obtain the pre-login information issued by the data node; R3. Access the blockchain through a data node or web3 interface, generate a transaction, and use the transaction ID as a credential to log in to the selected data node.

[0011] Furthermore, the client can select any data node to log in through query.

[0012] Furthermore, after the client logs in to the data node, the data node maintains a long connection with the corresponding client. Second, a decentralized chat system, including: Blockchain: Provides a specific data storage, writing, and query interface, and subsequently provides authoritative user public keys for information verification and message decryption; Central server: assigns UID and writes the binding relationship between UID and user's identity public key into the blockchain; Data nodes issue and verify user login information, and provide users with message forwarding and offline message storage functions; Client: Register and bind the public key on the central server to obtain the UID; choose to log in to the data node and conduct related chat activities; The data node is used to manage all information of the corresponding client, and the central server does not store any client information.

[0013] Based on the above technical solution, the following technical effects can be produced: The present invention provides a decentralized chat method and system. Any individual or enterprise can build their own data nodes and independently manage the client. The client's information is only stored in its data node, ensuring the security of its internal information. The present invention limits both friend addition and group creation, which not only establishes communication channels but also ensures smooth communication. In the present invention, message interactions between clients under different data nodes are also forwarded by each data node, which further ensures the security of the information. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the structures shown in these drawings without paying any creative work.

[0015] Figure 1 It is a structural schematic diagram of the present invention; Figure 2 This is a data interaction diagram of clients under different data nodes in the present invention. DETAILED DESCRIPTION

[0016] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0017] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0018] First, a decentralized chat method and system, such as Figure 1 , including the following steps: S1. Design several data nodes: RelayA, RelayB, RelayC, ..., RelayX (X represents any number. After the single letter is used up, it can be a combination of multiple letters such as AA and AB. Of course, it can follow the logical order of the 26 letters). Each data node manages the corresponding client. RelayA manages UserA1, UserA2, UserA3, ..., UserAn (n is an arbitrary natural number); RelayB manages UserB1, UserB2, UserB3, ..., UseBn (n is an arbitrary natural number); and so on. S2. Message management step: The data node stores the corresponding client's information and helps the corresponding client store offline messages. The data node maintains a long connection with the corresponding client, that is, RelayA maintains a long connection with UserA1, UserA2, UserA3, ...; RelayB maintains a long connection with UserB1, UserB2, UserB3, .... The long connection between the data node and the client reduces delay in high-frequency communication.

[0019] S3, message sending step: Messages between clients on the same data node are sent directly; for clients on different data nodes, such as UserA1 sending a message to UserB1, UserA1's message is first sent to RelayB, which then forwards it to UserB1; S4, group message sending step: When all the clients in the group are clients of the same data node, the information is forwarded by the data node. When there are clients of different data nodes in the group, such as a group established by UserA1, UserA2, and UserB1, after UserA1 sends a group message, RelayA and RelayB will receive the group message. RelayA will then forward the group message to UserA2, and RelayB will forward the group message to UserB1.

[0020] The clients under the same data node are in an internal relationship, and the two are directly connected to send information; the two different clients are in an external relationship, and when sending information, it will be reviewed by the data node to ensure data security. Figure 2 That is, when UserA1 sends a message to UserB1, UserA1 directly sends the message to RelayB, which then forwards it to UserB1. Similarly, when UserB1 sends a message to UserA1, UserB1 directly sends the message to RelayA, which then forwards it to UserA1.

[0021] Similarly, group messages are all created by internal clients to ensure rapid information exchange and avoid delays. For groups with external clients participating, the security of the information needs to be considered, so it will be reviewed by the data node.

[0022] However, the review of data nodes generally only involves screening for sensitive information, and there is a set of automatic inspection software to avoid excessive delays in manual review.

[0023] Client friend management steps: Clients on the same data node are automatically added as node friends. Clients can also add basic friends. The initiator queries the ID of other clients and adds them to the basic friends column in a one-way manner. Basic friends and node friends are listed in parallel friend columns. Clients on the same data node are automatically added as node friends. Clients can also add basic friends using a one-way addition mechanism. For example, in a data node, if UserA1 adds UserA2 as a basic friend but does not add UserA3 as a basic friend, after UserA1 changes data nodes, UserA2, the basic friend, will still be in the basic friend column, while UserA3 will only be a node friend. If they are no longer on the same node, their connection will be lost. If UserA1 wants to chat with UserB1, they need to add UserB1 as a basic friend (they can still chat without adding node friends, but not on different nodes). After adding basic friends, they can send messages to UserB1. If they are on the same node, UserA1 and UserA2 can communicate with each other without verification. UserA1 sends a message to UserB1, RelayB will review the message and then push it to UserB1. UserB1 can directly reply to the message (sent to RelayA, which will review it), and can also add UserA1 as a basic friend later.

[0024] As mentioned previously, data nodes operate within distinct ecosystems and are generally isolated from each other. However, the same data node operates internally. Therefore, UserA1, UserA2, UserA3, and so on under RelayA will automatically become friends (node ​​friends). However, when UserA1 and UserB1 add each other as friends, RelayA and RelayB must review their addition. This review step can be omitted, for example, by establishing a review-free mechanism between RelayA and RelayB, creating a single ecosystem. Adding friends between clients under these two nodes eliminates the need for review. Even more, it can be configured to automatically become friends, meaning that UserA1, UserA2, UserA3, and so on, as well as UserB1, UserB2, UserB3, and so on, will automatically add each other as friends (this refers to node friends; basic friends still need to be added manually).

[0025] The group building steps of the present invention are as follows: when a group is built between clients of the same data node, it does not need to be reviewed by the data node; when a group is built between clients of different data nodes, it needs to be reviewed by all corresponding data nodes.

[0026] Internal clients can freely create groups without review; if external clients participate, review by all data nodes is required. Similarly, a review-free mechanism can be set up between data nodes. For example, a review-free mechanism can be established between RelayA and RelayB. UserA1, UserA2, UserA3, ... and UserB1, UserB2, UserB3, ... can freely create groups. Even after data nodes RelayA, RelayB and RelayA and RelayC establish a review-free mechanism for groups, all clients within the three nodes can freely create groups without review. Finally, it can be extended to more data nodes, and only the review mechanism needs to be established between two of them.

[0027] Design a central server, which is responsible for user registration, assigning UIDs and writing them into the blockchain.

[0028] Client registration steps: T1. The client provides basic information and identity public key to the central server; T2. The central server assigns a UID to the client and asynchronously writes the UID and identity public key into the blockchain; T3. The central server returns the status to the client, and the data node and client can subsequently query it on the public blockchain.

[0029] It also includes the client login steps: R1. Data nodes register their own network information on the blockchain in advance; R2. The client selects a data node and accesses the data node pre-login interface to obtain the pre-login information issued by the data node; R3. Access the blockchain through a data node or web3 interface, generate a transaction, and use the transaction ID as a credential to log in to the selected data node.

[0030] After the client is installed, when the client registers, basic information (including user name, ID number, etc.) is established. At this time, a public-private key pair is generated, and then the basic information and identity public key are sent to the central registration.

[0031] Data nodes forward messages, handle user login, message forwarding, offline storage, and cross-node communication (core service layer). Users can freely choose / build their own nodes, and nodes collaborate equally.

[0032] The central server assigns a UID to the client. This UID is a globally unique identifier generated according to specific rules (such as timestamp + random number) to ensure no duplication across the network. The central server is only responsible for initial registration and does not participate in subsequent communications. The blockchain stores the authoritative mapping between the UID and the user's public key, providing an unalterable binding relationship. Anyone can deploy a node, and data is open and transparent. The client holds a public and private key pair, verifies its identity through the blockchain, and interacts with data nodes to send and receive messages, fully controlling its own data and communication paths.

[0033] Traditional designs carry the risk of user identity public keys being modified, a drawback shared by both traditional centralized services and private deployments. However, blockchain ensures that user identity public keys cannot be replaced, and all modifications are publicly visible.

[0034] Based on the above, let's assume UserB1 sends a message to UserA1, with UserB1=>RelayA=>UserA1. RelayA then needs to verify that UserB1 is genuine and not a forged UserB1. The previous design, when UserB1 registered, had the association UserB1[uid]<=>UserB1[pubKey] written to the blockchain. Therefore, when UserB1 sends a message, it needs to sign the data with its private key. Upon receiving the message, the data node service RelayA accesses the public key UserB1[pubKey] associated with UserB1[uid] in the blockchain before forwarding it to UserA1. This public key verifies the signature, preventing UserB1's message from being forged.

[0035] If it is not forged, then check whether UserB1 is in UserA1's friend or blacklist. If not, or on the blacklist, the node-side message will be intercepted.

[0036] ECDH is used to negotiate the key. At this time, the user's public key is on the decentralized blockchain and not on any other server, ensuring its authority.

[0037] The center only registers the uid and writes the user's public key pubkey into the blockchain. Because anyone can access the blockchain and its modification history at any time, the uid<=>pubKey written into the center is secure and authoritative, and there is no risk of unauthorized centers modifying its value.

[0038] When in use, the enterprise can establish a data node to manage information. Employees hold clients, and internal employees can be directly added as friends. The data node stores all information sent or received by employees, and the software provider (central server) only registers the client and does not manage the client. In this scenario, employees obtain the client, and after successful registration, they scan the QR code associated with the data node (the enterprise issues a QR code to the employee) to log in to the data node. After the data node agrees, the client successfully logs in to the data node, automatically obtains other employees, and becomes node friends.

[0039] When in use, others can establish a data node to keep information confidential. The person who establishes it can share the QR code of the data node. Others can join this data node by scanning the code. After joining, internal members can directly become node friends and can chat and interact.

[0040] Of course, the above are not the same data nodes, and friends can also be added and chatted. The functions of the data nodes can be set (including whether to review the incoming and outgoing information, whether to control the addition of friends, etc.). However, when an enterprise establishes a data node, it generally conducts data control and needs to review the data node before adding friends (basic), and the incoming and outgoing information will be reviewed by the data node (the review is generally also a keyword review by the machine to avoid internal information leakage of the enterprise, and to avoid internal clients receiving virus files, affecting the enterprise network security). However, when others establish a data node, when the client scans the code to add it, there will be a corresponding prompt, prompting the content provided by the data node (including restrictions and services, the restriction is the above-mentioned review, and the service is to save data). If you feel that the restrictions are too large, you can just not enter the data node. The data node established by others can be set to not review information and not review the addition of friends, so that the client may enjoy the services of the data node.

[0041] Of course, the client can also select multiple data nodes. For example, a group enterprise can be a group company + several subsidiaries model. An employee under the group can log in to all companies through the client (of course, each data node needs to be reviewed and approved, and added to the whitelist. The employee client can log in through any company at will), so that it is very convenient for various personnel to communicate. This method speeds up communication and avoids information review between different data nodes (subsidiaries are often isolated from each other). In this way, this isolation is broken by adding the data node of the corresponding subsidiary.

[0042] Like ordinary data nodes (established by individuals or in partnership), clients can also select multiple data nodes. In this case, the data node acts as a chat system. The data node can have a network ID (such as **game collection, travel collection, etc.). After the client joins this data node, it will gain a large number of companions and can exchange experiences.

[0043] When a client replaces a data node, it will not affect the communication with existing contacts (friends and groups); many data node administrators can even design the data node to be open mode, so that any client can join through the data node and communicate. After joining the data node, the friend column is divided into two parts, including original friends and node friends. Node friends refer to all clients located in this node, which will be automatically added as node friends. After communicating in the node, both parties can add each other as basic friends again to avoid losing friends.

[0044] On the second aspect, a decentralized chat system, such as Figure 1 ,include: Blockchain: Provides a specific data storage, writing, and query interface, and subsequently provides authoritative user public keys for information verification and message encryption; Central server: assigns UID and writes the binding relationship between UID and user's identity public key into the blockchain; Data nodes issue and verify user login information, and provide users with message forwarding and offline message storage functions; Client: Register and bind the public key on the central server to obtain the UID; choose to log in to the data node and conduct related chat activities; The data node is used to manage all information of the corresponding client. The central server stores the authentication information of the data node, and the central server does not store any client information.

[0045] In this invention, the central server is established by the technology provider, the data nodes are set up by the client (typically an enterprise or organization), and the client is set up by the client's employees. The technology provider generally provides updates to the client and stores and authenticates registration information. The data node is a small server that stores all employee information.

[0046] It offers the following advantages: Trusted identity: The blockchain ensures the authority of public key binding. Decentralized communication: User data is stored on self-selected data nodes, avoiding single-center control. End-to-end encryption: Public-key encryption and signatures ensure message privacy and integrity. Censorship resistance: With no centralized server, governments and businesses cannot directly shut down services. Data autonomy: User data is stored on self-selected nodes, avoiding third-party surveillance. Elastic scalability: Adding new data nodes can expand system capacity.

Claims

1. A decentralized chat method, characterized by: The following steps are involved: S1. Design several data nodes, each of which manages the corresponding client; S2, message management step: The data node stores the corresponding client's information and helps the corresponding client store offline messages; S3, message sending step: the information between the client and the data node is sent directly; For clients on different data nodes, the sender will first send the message to the receiver's data node, and the receiver's data node will forward the message to the receiver; S4, group message sending step: When all the clients in the group are clients of the same data node, the information is forwarded by the data node; When there are clients with different data nodes in a group, after a group message is generated, all corresponding data nodes will receive the group message, and the data nodes will forward the group message to all corresponding clients belonging to the group.

2. A decentralized chat method according to claim 1, characterized in that: It also includes client friend management steps: clients on the same data node are automatically added as node friends; clients can also add basic friends. The initiator queries the ID of other clients and adds the other party to the basic friends in a unidirectional manner. Basic friends and node friends are listed in parallel friend columns.

3. A decentralized chat method according to claim 1, characterized in that: It also includes the steps of establishing a group: establishing a group between clients of the same data node does not require the review of the data node; establishing a group between clients of different data nodes requires the review of all corresponding data nodes.

4. A decentralized chat method according to claim 3, characterized in that: A review-free mechanism can be established between the data nodes, and no review is required when the client creates a group.

5. A decentralized chat method according to claim 1, characterized in that: It also includes a central server, which is used to register users and write the user's public key into the blockchain.

6. A decentralized chat method according to claim 5, characterized in that: It also includes the client registration steps: T1. The client provides basic information and identity public key to the central server; T2. The central server assigns a UID to the client and asynchronously writes the UID and identity public key into the blockchain; T3. The central server returns the status to the client, and the data node and client can subsequently query it on the public blockchain.

7. A decentralized chat method according to claim 5, characterized in that: It also includes the client login steps: R1. Data nodes register their own network information on the blockchain in advance; R2. The client selects a data node and accesses the data node pre-login interface to obtain the pre-login information issued by the data node; R3. The client accesses the blockchain through the data node, generates a transaction, and uses the transaction ID as a credential to log in to the selected data node.

8. A decentralized chat method according to claim 7, characterized in that: The client can select any data node to log in through query.

9. A decentralized chat method according to claim 8, characterized in that: After the client logs in to the data node, the data node maintains a long connection with the corresponding client.

10. A decentralized chat system, characterized by: include: Blockchain: Provides a specific data storage, writing, and query interface, and subsequently provides authoritative user public key queries for information verification and message decryption; Central server: assigns UID and writes the binding relationship between UID and user's identity public key into the blockchain; Data nodes issue and verify user login information, and provide users with message forwarding and offline message storage functions; Client: Register and bind the public key to the blockchain on the central server to obtain the UID; choose to log in to the data node and conduct related chat activities; The data node is used to manage all information of the corresponding client, and the central server does not store any client information.

Images