The "Network" tab within the application is intended to display the dimensions of the DIVA network.

Wanted features

• Display the network, also as visible here: https://testnet.diva.exchange/ui/network
• Try to show the "activity" of the network participants. Examples: online or not, seen the last time, how often like when they have been online the last time, how active they are
• Keep in mind: activity stats can only be gathered as long as the local node is online.

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://github.com/diva-exchange/divachain). Example to load network list: http://127.19.72.21:17468/network
• SQLite database skills to store activity data as measured

Adding or deleting an order does not update the "Market" box. The nostro is properly updated.

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.

Migrated from https://codeberg.org/diva.exchange/diva/issues/7 and https://codeberg.org/diva.exchange/diva/issues/8

Footer:

1. The information about the Role, Karma, Connection and the option to change the language disappears for screens smaller than 1024px.

Order Box:

2. In small screens (width <= 970px) Overlapping Buy/Sell dropdown form element with the Contract logo

Panel orderbook ("My Orders & Trades"):

3. In small screens (width <= 900px) Overlapping Buy with Sell prices in the "Orders" Tab
4. In small screens (width <= 920px) Overlapping amount of the Sell column with the Bin icon
5. In small screens (width <= 810px) Overlapping Buy with Sell amounts in the "Orders" Tab

Panel market ("Market"):

6. In small screens (width <= 900px) Overlapping Buy with Sell prices in the "Orders" Tab

7. Extreme case: On Smartphone "Galaxy Fold" (width = 280px) the column Buy gets totally overlapped with the column Sell.

The language selection can be moved to the Config page. The rest of the information in the footer is not crucial and can be moved somewhere else or simply not get displayed on small devices. There is a compromise between info displayed and space available on the screen.

1. It's not cleat that in the "My Orders & Trades" panel that there are two tabs: "Orders" and "Trades" and that clicking on these words the user can move to the other tab.
2. From user perspective, the icons (the bin) should be very much at the side of the block.
3. In the "My Orders & Trades" panel is not clear that there is one Buy and one Sell columns and which is each. In the "Market" panel this has been temporarily fixed by adding the text "(Sell)" and "(Buy)" in each column's header.
4. Not clear what kind of information is displayed in the "Trades" tab in the "My Orders & Trades" panel. Currently hardcoded information is displayed. Only the time (and not the date) is displayed. --> The entire tab needs to be defined and then re-designed accordingly.
5. Is it wanted the the Asset panel floats right below the "My Orders & Trades" panel and shifts down the Market panel when the screen width forces to have only one column?