Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 months ago.
Improve this question
In TON blockchain, when implementing my dapp smart contract in FunC, my contract can accept both internal messages handled by recv_internal() and external messages handled by recv_external().
Which type of messages should I handle? Internal or external?
What's the difference between them?
TLDR
When implementing dapps - always use internal messages only.
Never use external messages. You can safely ignore the fact that external messages exist.
Wallets on TON are smart contracts too
Unlike most blockchains, Ethereum included, when a user on TON downloads a wallet app, this wallet app will deploy a wallet smart contract for the user. This wallet smart contract holds the user's TON coin balance.
Every interaction that the user does takes place through this wallet smart contract. The wallet smart contract is what holds the user's TON coin balance, so any action like sending a transaction to a dapp contract must go through the wallet smart contract to pay for gas from this balance.
Read this to learn more about wallet smart contracts on TON.
Message and TON contracts
To communicate with a smart contract on TON, you must send it a message. Every transaction is essentially a message. The main entry point of a smart contract is the message handler.
Internal messages
These are messages sent by other smart contracts - particularly messages sent by wallet smart contracts. Since we said above that every user interaction with a dapp would go through their wallet smart contract (to pay for gas), this means every user interaction with a dapp will come in the form on an internal message.
External messages
To understand why these messages exist we must ask ourselves how are wallet smart contracts implemented. You can actually implement a wallet smart contract by yourself! Here is an example of the latest code today for the default wallet. You would normally never have to do this though! This task is normally reserved to the TON core team or projects explicitly developing wallets.
As you probably guessed, users communicate with their wallet smart contracts using an external message. These messages are designed for external entities that are not smart contracts, like a wallet app. But.. since every such action must go through a wallet contract to pay for gas, your dapp will eventually receive its messages from a smart contract as internal messages.
The standard message flow
Let's assume that the user is trying to transfer a jetton token to another user. This interaction requires sending a transaction to the jetton smart contract (a dapp). The flow would be:
user ---(external msg)---> user's wallet smart contract ---(internal msg)---> jetton smart contract
If the user is using TonKeeper wallet for example, the external message would be encoded by the TonKeeper mobile app.
Why did I see some dapps handling external messages?
It is possible for a dapp contract to handle external messages. I saw some developers are using this approach for deployment and some developers are using this for admin role actions like upgrades.
In both cases though, the best practice is to use internal messages and not external messages. An admin role can be a multi-sig contract too, by using an external message they've broken the abstraction and will not be able to support multi-sig.
Related
Background
I have a monolith Node.js + PostgreSQL app that, besides other things, needs to provide real-time in-app notifications to end users.
It is currently implemented in the following way:
there's a db table notifications which has state (pending/sent), userid (id of the notification receiver), isRead (did a user read the notification), type and body - notification data.
once specific resources get created or specific events occur, a various number of users should receive in-app notifications. When a notification is created, it gets persisted to the db and gets sent to the user using WebSockets. Notifications can also get created by a cron job.
when a user receives N number of notifications of the same type, they get collapsed into one single notification. This is done via db trigger by deleting repeated notifications and inserting a new one.
usually it works fine. But when the number of receivers exceeds several thousands, the app lags or other requests get blocked or not all notifications get sent via WebSockets.
Examples of notifications
Article published
A user is awarded with points
A user logged in multiple times but didn't perform some action
One user sends a friend request to another
One user sent a message to another
if a user receives 3+ Article published notifications, they get collapsed into the N articles published notification (N gets updated if new same notifications get received).
What I currently have doesn't seem to work very well. For example, for the Article created event the api endpoint that handles the creation, also handles notifications send-outs (which is maybe not a good approach - it creates ~5-6k notifications and sends them to users via websockets).
Question
How to correctly design such functionality?
Should I stay with a node.js + db approach or add a queuing service? Redis Pub/Sub? RabbitMQ?
We deploy to the k8s cluster, so adding another service is not a problem. More important question - is it really needed in my case?
I would love some general advice or resources to read on this topic.
I've read several articles on messaging/queuing/notifications system design but still don't quite get if this fits my case.
Should the queue store the notifications or should they be in the db? What's the correct way to notify thousands of users in real-time (websockets? SSE?)?
Also, the more I read about queues and message brokers, the more it feels like I'm overcomplicating things and getting more confused.
Consider using the Temporal open source project. It would allow modeling each user lifecycle as a separate program. The Temporal makes the code fully fault tolerant and preserves its full state (including local variables and blocking await calls) across process restarts.
I'm building an application in which we have worked on Payment gateway named flutterwave.
And now the scenario is on every success or failure of a payment, I receive a webhook and then we take further actions such as sending emails, SMS and updating the statuses of the payment in the DB.
For now, we have implemented polling in the client side and for a particular time span if the client receives a status (success or fail) we show it otherwise they can check later it in the payment history page.
Now we want to remove this polling and update users in real time about the success or failure of a payment.
What are the ways by which we can achieve this?
The questions are how we will notify a specific user about the same as we have a multiplatform app and the same user can be logged in different platforms.
What you are looking for is a real-time communication pattern with WebSockets a layer 7 protocol in the OSI model which offers bi-directional communication.
This means that you can establish communication between your servers and your user's browser (client). As a result, you can send notification data to the client and consume and react to the notification, by showing visual cues in your UI for the user to see.
Some examples of implementing WebSockets with Socket.io and Nodejs: https://dev.to/novu/sending-real-time-notifications-with-socketio-in-nodejs-1l5j
There are also paid services that can offer this functionality like Pusher, and I would actually recommend that route at the beginning so you can avoid spending too much time implementing this and focus more on the stuff that matters and is part of your roadmap.
Additionally, you can use Push Notifications as another way to notify your users even when they are not using the app.
Using Node.JS and the Twilio API I can easily see when a transfer initiated by my Twilio code is answered using Call Status Events. But, what if the person I am calling transfers my call?
Is there anything in the Twilio API that will tell me the call is being transferred, is currently on hold, and when that transfer is answered?
Desired Flow:
Twilio Bot calls Number
Receptionist answers
Twilio Bot asks to speak with a salesperson
Receptionist says they will transfer the call, and begins the transfer
Twilio Bot is put on hold and hears Silence/Ringing/Music/Automated "pease wait. You are # in the que" messages
Salesperson answers
Twilio Bot greets and continues the conversation with Salesperson
This is not possible.
The information is hidden behind the receptionists PBX, and not exposed outside that platform. The transfer is basically invisible to Twilio or any external parties from a signaling perspective.
I am new to developing Dapps with Hyperledger Fabric using Composer. I would like to know the purposes and use cases of Events in Hyperledger Fabric. On the Hyperledger Composer website it states:
Events can be emitted by Hyperledger Composer and subscribed to by external applications. Events are defined in the model file of a business network definition, and are emitted by transaction JavaScript in the transaction processor functions file.
So do Events act like triggers for the Composer Web Service that can be used in external applications such as notifications? What are the potential use cases of Events and the significance of Events in the overall blockchain landscape?
Yes, events basically are triggers that can be used in external applications such as notifications. My favourite example is that you can use events to signal a printer to print something.
Events provide a way to interact with external system , like you need to notify external system when transaction submitted.
also events can be used to identify transaction details to retrieve history of transaction over a specific asset like
https://github.com/hyperledger/composer/issues/2458
Yes, Events act like triggers for the Composer Web Service that can be used in external applications such as notifications. Use cases like Bidding Application, Voting Application on the Hyperledger Composer and using events, we can see live changes of a bid on bidding App. And also using events we can see transaction history of asset or participant also.
Events are emitted by transaction JavaScript in the transaction processor functions file.
That means, when you call any transaction in Hyperledger, It will generate some events, which contains the data, that changed by you in the blockchain.
So, on front-end side you can view live changes in data. This can be done by in JavaScript by using Web Socket. So, user can get run time notification.
Here is an tutorial for Events generation.
Demo for events is here.
In this SuperUser.com question and elsewhere, I've read that Skype doesn't store your historical chat messages on their servers in a way that's user-accessible. (Of course, what they do for internal archival and analytical purposes is a different story -- as reflected by their privacy policy).
But the user experience for group chats is: when you've been offline and you sign back into Skype... all the messages you missed appear. Even if it's been a while and there are a lot of messages. (I don't know if there are limits on how long or how many.)
So: how is this UX implemented if the messages don't come from Skype servers?
I've read this offhand description which states:
Syncing of group chats ("More than 2 people in a chat") is done by chat sync partners in those chats, and not provided by Skype servers.
If that's correct, I'd love more details about how this works, like:
Has the protocol been specified or reverse-engineered?
Is it available through an API?
Are requests routed through Skype, or is it direcly peer-to-peer?
If peer-to-peer, how are requests authenticated?
My experience is I can only "see" history back to the time when I joined a chat; can a client request or receive messages farther back in the history?
I understand some of of the protocols are currently in flux -- so, bonus points if you can explain whether/how these details are changing.
When you login your client has the last recieved id of that conversation.
Sends it to the other clients. The client who recieves the id looks up all messages after that one, and then sends it back to you.
That way they don't have to store the messages on their servers.