You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Build a Proof Of Concept (POC) to demonstrate our messaging implementation plan (see issue #2) will work. This should demonstrate the ability to store messages for multiple peerIDs and efficiently retrieve them.
Requirements
Client POC
It should have a text box to input text for chat messages.
The peerID for the recipient of the chat messages can be hard coded, or have an input field.
It should have a send live button.
Pressing the button would send an offline formatted message to a node, which would attempt to push it to the destination node. If the destination node was unreachable, it would be sent as an offline message.
Received messages from the other node should be displayed on the page. It's sufficient to just show the last received message.
The POC should demonstrate it can receive live and offline messages. It might be better to have a separate display area for received offline messages?
Server POC
This can be a branch of the existing node.
Sending Messages
It should be able to receive messages from the browser page.
The messages should be sent to the recipient node using the offline wrapper format.
If the message is not received, the message should instead be stored and a pointer added to the DHT.
How does the server know the message was not received? It seems like this requires an ACK.
Do we need to do something with the sending IP? Will the recipient see the messaging server's IP as the IP to respond to?
Receiving Messages
It should be able to find offline messages on the DHT intended for the browser page and store them in a database for later retrieval.
It should be able to store offline messages for multiple peerIDs. Three or so is enough for a POC.
The peerIDs to track should be established by a browser client sending a message to it to be sent to another node and initiating a relationship with the messaging server.
We can assume no one would send a message to a web buying node before it has sent a message to anyone else, since the purpose of those nodes is to only buy things.
When a web buying client requests messages, the server should send the requested unsent messages for that peerID.
The text was updated successfully, but these errors were encountered:
jjeffryes
changed the title
Build Messaging Proof Of Concept
Build Advanced Messaging Proof Of Concept
Jun 29, 2018
Description
Build a Proof Of Concept (POC) to demonstrate our messaging implementation plan (see issue #2) will work. This should demonstrate the ability to store messages for multiple peerIDs and efficiently retrieve them.
Requirements
Client POC
Server POC
This can be a branch of the existing node.
Sending Messages
Receiving Messages
The text was updated successfully, but these errors were encountered: