Determine How Messaging Will Work

[jjeffryes]

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:

• Since the message from the browser is already in the offline format, the relay node doesn't have to communicate back to the browser to request an offline version of the message.
  Cons:
• A server is required to send messages.
• All messages to the browser are effectively offline, which is a lot more data. That data would have to be saved on the messaging node.

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:

• simpler to implement.
  Cons
• Communication is slow.
• Chat may not be viable.

[jjeffryes]

We concluded we would use the libp2p option.

[jjeffryes]

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.