Prem Chaitanya Prathi

Another thought comes to my mind is since messages would anyways be sent/received from Filter node either via FilterPing or MessagePush. Can we somehow also use those messages RTT (from...

> @chaitanyaprem, I found something interesting in yamux!!: > > Looks like it measures RTT for all the open sessions: > > * https://github.com/libp2p/go-yamux/blob/48aa3a7bb46c354076969f5b3ac7f4b805744dcb/session.go#L164C1-L164C24 > > * https://github.com/libp2p/go-yamux/blob/48aa3a7bb46c354076969f5b3ac7f4b805744dcb/session.go#L340 > meaning...

Except statically added peers, all other peer addresses are expired after AddressTTL which is defaulted to 1 hour. I am not sure if this change fixes anything. Do we have...

> The reason why I think the peerstore is growing is because pprof's alloc_space is displaying this: Interesting that TTL and memory free are not getting captured by pprof. Could...

Not sure if this issue should be part of status-waku integration as this is for js-waku. cc @chair28980

Since Waku relay uses underlying libp2p gossipsub for communication, there is no way to know if a message sent by application has actually been sent out in the network to...

> I think your proposal re a short cache and using a store query to "resume" publishing after detecting a disconnect is a reasonable short term workaround. Yes, the idea...

> Would be keen to better understand what nimbus or other libp2p-gossipsub users do before going down the path of systematic light push usage considering the caveats. Per @arnetheduck,nimbus has...

> Please also include recommendation about messages not being received during connection is lost and it is realized that connection is lost. # Possible approach to handle messages not received...

> I would suggest also investigating the impact of always using lightpush as the publishing mechanism, even for relay nodes. Currently the impact might be: > > 1. the publishing...