Refactor Messages Rebroadcast

[Cabecinha84]

• Start caching the message together with the messageHash;
• After change goes live, when a flux app message is processed and it's ok to be rebroadcast we start sending "messageHashPresent" to the other peers, the peers receive this message and if they haven't received yet that message hash, they reply back with a "requestMessageHash" with the hash of the message they need, and the node when it receives this message, check on cache for the message and send it back;
  It's almost like a ping/pong on the websocket.
• This will reduce the bandwidth used on nodes, reducing largely the possibility of ISP router mark the data on the websockets as flooding and stopping block the data for some time;
• Goes live on block 1751250, 13th Octobor 2024;

[codecov]

Codecov Report

Attention: Patch coverage is 19.40299% with 54 lines in your changes missing coverage. Please review.

Project coverage is 48.68%. Comparing base (6b61e41) to head (7f71a30).
Report is 477 commits behind head on development.

Files with missing lines	Patch %	Lines
ZelBack/src/services/fluxCommunication.js	19.40%	54 Missing ⚠️

Additional details and impacted files

@@               Coverage Diff               @@
##           development    #1403      +/-   ##
===============================================
+ Coverage        47.84%   48.68%   +0.83%     
===============================================
  Files               50       60      +10     
  Lines            15622    17782    +2160     
===============================================
+ Hits              7475     8657    +1182     
- Misses            8147     9125     +978     

Flag	Coverage Δ
	48.68% <19.40%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[TheTrunk]

So we are now skipping the verification on these messages. It is more efficient. Can we think of some scenario of how this can be misused by malicious actor? If not I am fine with this faster approach. Seems like its highly difficult to get on the network, gain trust of the peer, try to spam it and overload some particular node with asking for a message

Might be good to conduct throughout testing, benchamrking of it this week

[TheTrunk]

Should there be some fallback to database?
We surely have the message and client requested it but it may not be in a cache?

[TheTrunk]

I think there must be a fallback to database, if not we would not be able to receive the message as thats the only way to sync up

[TheTrunk]

But we are only sending the dataObj which has just messageHashPresent

I think it needs to be proper message, formatted and signed like we have with

        const appRemovedMessage = {
          type: 'fluxappremoved',
          version: 1,
          appName,
          ip,
          broadcastedAt,
        };
        log.info('Broadcasting appremoved message to the network');
        // broadcast messages about app removed to all peers
        await fluxCommunicationMessagesSender.broadcastMessageToOutgoing(appRemovedMessage);
        ```

[TheTrunk]

is it always 40?
https://github.com/puleos/object-hash

[Cabecinha84]

All discussed in private chat :)!