nchat

repository·master·Indexed 23 days ago

https://github.com/d99kris/nchat

A terminal-based multi-protocol messaging client supporting Telegram, WhatsApp, and Signal. The project includes Duchat, a dummy chat protocol for development and testing, and integrates several C++ libraries including Apathy for path manipulation, cereal for serialization, Clip for cross-platform clipboard interaction, and sqlite_modern_cpp for SQLite database management.

Tokens
41.6K
Snippets
80
Records
255
Agent score
84%

What's inside nchat

  1. Security policy for stb libraries

    master
    Security-relevant bugs in this project are discussed publicly via GitHub Issues and Pull Requests. Because fixes may take significant time to be implemented or merged, users should evaluate the risk to their own projects before using the stb libraries. If public disclosure of vulnerabilities poses an unreasonable risk to your project, do not use these libraries.
  2. Use the whatsmeow Go library for WhatsApp Web API

    master

    whatsmeow is a Go library designed to interface with the WhatsApp web multidevice API. It allows developers to automate WhatsApp interactions such as sending/receiving messages, managing groups, and handling app state.

    Core capabilities include:

    • Sending text and media messages to private chats and groups.
    • Receiving all incoming messages.
    • Group management (joining via invites, creating/using invite links, and receiving group change events).
    • Managing typing notifications, delivery receipts, and read receipts.
    • Reading and writing app state (e.g., contact lists, chat pin/mute status).
    • Handling retry receipts for failed message decryption.
    • Sending status messages (experimental).

    Note: Broadcast list messages and calls are currently not supported.

  3. What is Duchat and when to use it

    master

    Duchat is an implementation of a dummy chat protocol designed specifically for the development and testing of nchat. It allows developers to simulate chat interactions without needing to connect to real messaging services.

    Note that Duchat is disabled by default in standard nchat builds and must be explicitly enabled during the build process.

  4. Understand the Blockchain Implementation

    master

    The blockchain is a distributed ledger system used to maintain a consistent state across multiple participants. It manages three primary types of state:

    1. Key-Value Storage: A persistent trie for storing and retrieving data.
    2. Group State: Manages participants and their specific permissions (e.g., AddUsers, RemoveUsers).
    3. Shared Key Information: Manages encryption keys shared among participants.

    Security is enforced through cryptographic signatures, sequential block heights, and state proofs that validate the state after a block is applied.

  5. Use TDLib JSON interface with other languages

    master

    For most use cases involving languages other than C++, Java, or .NET, it is recommended to use the TDLib JSON interface. This interface is accessible via any language capable of executing C functions.

    The JSON interface follows semantic versioning: major versions are binary and backward compatible, but the underlying API may change between minor or patch versions. You can use the version option to ensure compatibility with specific TDLib versions.

  6. stb library licensing information

    master

    All stb libraries are dual-licensed as Public Domain or MIT.

    • Public Domain: You can use them for any purpose without legal obligation, though attribution is appreciated.
    • MIT: Available for those who prefer a standard open-source license.

    Because they are public domain, you can wrap these libraries in your own software and relicense your new library under any license you choose.

  7. Block Application Validation Rules

    master

    When applying a block, the system performs the following sequential checks. If any check fails, the entire block is rejected:

    1. Height Check: Block height must be exactly current_height + 1. Failure returns HEIGHT_MISMATCH.
    2. Hash Check: The prev_block_hash must match the hash of the last applied block. Failure returns PREVIOUS_BLOCK_HASH_MISMATCH.
    3. Permission Check: The signer's permissions are determined from the previous state (or external_permissions).
    4. Signature Check: The block signature must be valid. Failure returns INVALID_SIGNATURE.
    5. Change Application: Each change in the block is applied sequentially. Permissions are re-evaluated after each change within the same block to ensure consistency.
    6. State Proof Check: The state_proof must be valid for the resulting state. Failure returns INVALID_STATE_PROOF.

    Concurrency: If two blocks are built for the same height, only the first one applied succeeds; the second is rejected with HEIGHT_MISMATCH to prevent forks.

  8. How the nchat multi-threaded architecture works

    master

    nchat uses a multi-threaded architecture to handle different communication protocols (e.g., Telegram).

    1. Protocol Processing: Each protocol must implement a thread that processes RequestMessage objects received via its SendRequest() method.
    2. Communication to Main App: Protocols communicate information back to the main application by passing ServiceMessage objects to its message handler. These messages are then processed in a worker thread.
    3. Core Logic and UI: The central application logic resides in uimodel.cpp, while the user interface rendering is managed by the ui*view.cpp files.
  9. Platform-specific considerations for Clip Library

    master

    When developing with the Clip Library, keep the following platform constraints in mind:

    • General (32-bit vs 64-bit): If your application might run in both 32-bit and 64-bit versions simultaneously, avoid using platform-dependent data types (like size_t) within custom format data, as their size may change.
    • Windows: There is a limited number of available clipboard formats on Windows.
    • Linux: Requires libx11-dev/libX11-devel for text and libpng-dev/libpng-devel for images.
  10. Emoji Generation Protocol (Commit-Reveal)

    master

    To prevent block creators from brute-forcing emojis, a two-phase commit-reveal protocol is used to generate an unpredictable emoji_hash.

    Protocol Steps:

    1. Setup: Each participant generates a random 32-byte nonce and calculates nonce_hash = SHA256(nonce).
    2. Commit Phase: Participants broadcast their nonce_hash (signed). The system waits for all participants to commit.
    3. Reveal Phase: Participants broadcast their original nonce (signed). The system verifies SHA256(revealed_nonce) == committed_hash.
    4. Final Hash: emoji_hash = HMAC-SHA512(concatenated_sorted_nonces, blockchain_hash).

    Implementation Details: Participants should only apply messages (including their own) when received from the server to ensure all clients see the same state. This ensures emojis are only displayed once all clients with reasonable connectivity can view them.