Social Tab: Implement Chat Feature

[diva-exchange]

Migrated from: https://codeberg.org/diva.exchange/diva/issues/10

---

The "Social" tab within the application is intended to allow communication between the users of the DIVA network.

"Users" are defined as "network participants" as visible here on the testnet: https://testnet.diva.exchange/ui/network

"Communication" is defined as sending messages between the participants back and forth.

Wanted features

• Users might set their local alias (a user name instead of their B32 address). A user name should have a reasonable length the front end (example: 16 chars max).
• The B32 address of the communication partner should be visible on request or by default if no alias is set
• Communication: text only as a first version.

Important

Current state (June 23 2022) of the code: not functional. It's just a rough idea. Those implementing the feature are free to choose the solution - it should be in line with the code style and philosphy of DIVA.

What's needed

• REST API communication to the local blockchain instance (divachain), by default running on http://127.19.72.21:17468/ (API doc, here: https://codeberg.org/diva.exchange/divachain). Example to load network list: http://127.19.72.21:17468/network
• I2P SAM communication: to send messages between Users, identified by B32 addresses. SAM library here: https://codeberg.org/diva.exchange/i2p-sam

---

I would like to work on this, my am not an experienced in network programming, there might be some inaccuracies. Correct me wherever required. Having strong requirement specifications can save us time and energy, so here are some requirements that I have elaborated based on my understanding. Please provider any useful resources that can help this development. Your suggestions are welcome.

Requirements elaborated :

• Use asymmetric encryption (public key cryptography) for encrypting and decrypting messages.
• Store sent and received message in Database in encrypted form.
• Persistence of private key should be maintained easily, example saving private key or use secret phrase to generate private key.
• Establish connection with the help of public key. The public key can be used to obtain destination address of peer directly (i.e, public key is the destination) or user will publish new destination on DHT and we use the public key to obtain the destination address from DHT, in this case user could change his destination address, thus providing more flexibility .
• User can set a local username (alias) which would be only saved on peer's node just for better user experience, this doesn't affect encryption or anonymity.
• Users should be able to block any peer they want.
• All communication should carried out through I2P SAM bridge.
• Use of (virtual )streams for communicating between peer's, as it is reliable and guaranteed delivery of message.
• Option to auto delete a message after specified time (disappearing messages) .

UI:

• Start new conversation (by B32 address or public key)
• Show users list
• Show previous messages stored in database
• Block user
• Delete messages/chat
• Show public key/B32 address
• Organize chats within folder
• Basic ability to modify theme (changing color, font size)
• Basic text formatting (italic, bold, strikethrough, link, emoji)

My knowledge may be incomplete or incorrect, please correct me if something is wrong.

Questions:

Should this be only limited to network participants ? Should B32 address (of network participants) be the only method to contact a user ? As we are using I2P, should we encrypt the messages at all ? Does any guidelines for code style exist for diva ? Any guidelines on commits and commit messages

My Opinion:

I think it would be best to keep this to text only chat for now and in future, and if user want's to send files, we can recommend them (or develop a feature) to use BitTorrent over I2P, for file sharing.

Resources (I found useful):

https://gist.github.com/gubatron/cd9cfa66839e18e49846

https://security.stackexchange.com/questions/126768/which-protocols-exist-for-end-to-end-encrypted-group-chat

https://signal.org/docs/

https://codethechange.stanford.edu/guides/guide_kademlia.html

---

Thank you. Great requirement specs - I agree mostly with them. Here is my feedback to the parts I see differently:

Use asymmetric encryption (public key cryptography) for encrypting and decrypting messages.

Possible, but would be double encryption. The transport layer (I2P) is already encrypting the data in transit. The I2P router is local, so as long as I2P has no encryption leaks/bugs, this chat feature would be secure.

Use of (virtual )streams for communicating between peer's, as it is reliable and guaranteed delivery of message.

Streams (TCP) might be not as censorship resistant as desired. UDP based messaging tends to be more censorship resistant since the traffic is more difficult to detect and to block. If UDP gets used, maybe the recipient(s) want to send kind of an ACK message back to signal that a specific message has been received.

---

Just an additional thought: It might make sense to have the possibility to store the own alias on the blockchain [divachain] (I believe you call it DHT in your specs above, which is kind of true too).

---

Feedback to Questions:

Should this be only limited to network participants ?

IMO, Yes. I also believe it is a good first starting point, since then the "address book" is kind of already solved (the network list as available through divachain/"DHT"). Might be extended in the future, though.

Should B32 address (of network participants) be the only method to contact a user ?

IMO: b32, public key and (maybe, see discussion above), alias.

As we are using I2P, should we encrypt the messages at all ?

See above.

Does any guidelines for code style exist for diva?

Kind of (as lint config). Please use just "npm run lint" before committing. If necessary, we'll have a chat as devs and we can adopt it to the needs.

Any guidelines on commits and commit messages?

Commit very often on develop - that's ok - even if unstable or experimental. Commit messages: short and as clear as possible. We'll mutually develop such guidelines as we process in the project. Sometimes branching might be appropriate - but devs can discuss this easily if it's necessary.