Use Waku in a Bandwidth Efficient Way

[fryorcraken]

Thank you for the detailed review. Great work.

@kaichao

Message Retransmission in MVDS

Would be good to back this up with some data so we can understand the expect gain of rolling out MVDS. I don’t expect that now, but more work we will need to plan once e2e reliability protocol is rolled out.

@kaichao

Disable MVDS retransmission for recipients that are not online/active.

Indeed, we know when a user was previously online, even if “offline” status, they do broadcast their X3DH bundle on a regular basis. If the bundle is not seen for a while, then it would make sense to stop rebroadcasting because we know they are offline.

There would be some edge cases:

1. Alice sends message to Bob
2. No ack, Alice check Bob’s most recent x3DH bundle: older than 5 days
3. Alice stops retransmission and goes offline
4. Bob goes online, emit message
5. Alice goes online, sees recent X3DH bundle, retransmit.

The issue is that if both Alice and Bob are sporadic users, then they may miss each other. But the message should be in store. I think it may be interesting further studying this option.

@kaichao

The interval can be increased by adjusting the constant factor (30) to a higher value, e.g., 60 or 90

is that in seconds?

@kaichao

Regular queries to store nodes can create additional network traffic.

When doing a hash query, do we end up redownloading our message (ie store replies with full message)? Could we update the store hash query to only return message presence to save download bandwidth?

@kaichao

Device Synchronization

This seems to be a big chunk of work. I think it may make sense to have an iterative approach and deploy a solution for the biggest culprit (Community Description?), and then move other messages to the same solution if it makes sense.

@kaichao

User Data Backup

This is back to Optimizing Community Description - #18 by fryorcraken

Are the requirements for user data backup and community description similar enough so that we could develop one solution to solve both problems?

The main issue I see is that all community members are interested in the community description, whereas only one user (several devices) is interested in backup data.

In the case of community description, it could be sent to IPFS and all community members could pin the message to ensure it’s accessible even if community noide owner is offline.

But it does not really make sense to do that for backups. Also, need to think long term: who is going to pay for those backups? using Waku is unlikely to be the most cost efficient way for a user.

I think this needs to be reviewed from a product pov first, and then the right technology can be selected/designed for this problem.

@kaichao

User sends status update

What is that? how frequent and how big?

@kaichao

I have been thinking about the autosharding, pubsub and content Topic recently, the current protocol seems restricted to fix the mapping between content topic to pubsub topic

This is enough to solve the problem here. Alice receives her messages on contentopiv1 that is autosharded to shardA.
Alice can subscrive to this shard.
Bob is also on shardA, alice can sends messages to Bob
Charlie on shardB, Alice uses light push to send a message to Charlie.

@kaichao

a store node may only want to store the messages from contentTopic-1 but not contentTopic-2.

Yes, this is something we have in mind, we are just waiting to have a clear demand to plan the work for it.

@kaichao

but for sync process, use may expect a real time experience when all the devices are online, there is always a request interval using store node.

I think I don’t undestand enough the sync process, back to some of my previous questions. when devices are paired, do they still need to communicate?

If so, then indeed it would make sense to investigate direct connections and ad hoc networks.