-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Determine How Messaging Will Work #2
Comments
We concluded we would use the libp2p option. |
13 tasks
We determined that the libp2p option would not work, due to it requiring wss, which requires nodes to have valid certs. We're proceeding with a POC for option 2. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
The web client will need a way to send and receive data (messages) to and from other nodes. It can use a special multi-user messaging node.
libp2p JS
This will allow the browser to send direct messages to another node that is reachable ("online"). If the recipient is not reachable, the message will be sent to a messaging node in the offline format and a pointer will be added to the DHT.
The browser can't receive incoming messages, it would need to listen to the messaging server for messages sent to it from other nodes.
The messaging node would need to be able to handle many clients connecting to it at the same time. It would likely index messages it receives for faster retrieval.
Initially offline messages would rely on push nodes like they do now. Eventually we would like to implement a pubsub system to allow messaging nodes to listen to an offline messages channel for messages that concern them.
https://github.com/libp2p/js-libp2p
Note: libp2p uses the WebCrypto package, which requires the site to be run on https (which we would do regardless). OpenBazaar nodes don't have certificates, so their socket connections are ws, which means the browser can't connect to them, as it will require a wss connection.
Possibly this could be resolved by sending the libp2p messages from the browser to a messaging node, but at that point it's effectively the same as the Offline Wrapper option, but with more complexity.
Offline Wrapper
This would wrap messages from the browser in the encrypted offline message format and send them to a relay server. The relay server would send the message directly if the recipient is reachable, or put a pointer to it in the DHT if they are not.
This would mean the browser would never be able to establish a direct connection to another node.
Offline messages would be retrieved from a messaging node in the same way they would in the first option.
Pros:
Cons:
Only Offline Messages
This would mean the browser sends messages to a relay node to be treated as offline messages, and listens to that relay node for offline messages it has received intended for the browser.
Pros:
Cons
The text was updated successfully, but these errors were encountered: