dappros / ethora

A 'super app' engine for your project. React Native (iOS, Android) and React.js (Web, desktop). Social Sign In 🄵, Messaging 💬 (chat, voice, push notifications), Web3 Wallet 🪪 (profile QR, documents, coins, NFT), DLT 🔐 (provenance, crypto signing), Gamification 🤩, Social Commerce and more.
https://ethora.com/
GNU Affero General Public License v3.0
441 stars 90 forks source link

Chat - server-wide systemUser for XMPP rooms #554

Closed phwizard closed 1 month ago

phwizard commented 4 months ago

Problem:

currently 'system' messages in Chats are sent by client applications which can lead to inconsistencies and security issues such as spoofing or phishing by malicious users.

Suggested solution:

Create a system bot user (a la Majordomo chat bot) that is going to be present in all MUC chats and will be triggered by our platform backend to send system messages.

This user can also be used for providing and managing additional functionalities or inviting other chat bots into chats by the chat members / admins.

Server initiation and App config need to be updated accordingly to support this system user.

Also as per your suggestion, the "transfer" route need to be extended to accept optional roomJid or chatJid parameter.

If specified, this will cause the system user to announce the transfer in the corresponding room. This will support our standard use cases of tipping coins or transferring coins between users in a chat room which is announced via system messages. Client apps going forward will verify that all system messages are only displayed when originated from the designated systemUser.

{ "tokenId": "ERC20", "tokenName": "string", "amount": 0, "toWallet": "string" "roomJid": "string" }

earlier discussion below for additional reference:


Потім коли юзер робитиме трансфер монет через чат, ми в handler для route POST /v1/tokens/transfer за допомогою app xmpp account будемо відправляти в чат повідомлення про успішну операцію. А клієнт додатку яким користуються юзери при завантаженні буде отримувати appConfig, де буде вказано що jid12345 це системні повідомлення і потім всі повідомлення від jid12345 буде показувати як системні.

Це буде краще ніж формувати системні повідомлення у юзерів, і показувати їх іншим юзерам як системні. v1/tokes/transfer може мати не обов'язкове поле roomJid крім тих полів що приймає зараз { "tokenId": "ERC20", "tokenName": "string", "amount": 0, "toWallet": "string" } щоб handler знав в яку кімнату публікувати повідомлення, а якщо roomJid буде відсутній то системне повідомлення не буде відправлене (для тих випадків якщо трансфер робили не через чат)