Hi *,
I worked today on the chat-with-rendezvous of go-libp2p-examples. I would like to share my experiences and problems.
-
At first, I struggled a bit with the
importhaving the IPFS references from more than onemake installexecutions (ipfs, libp2p, …). Finally, I removed all and installed IPFS only
.
BTW:-does split the import path as well and the appropriate word can be used in the code. -
For clarity and to loop over all peers to write to, I used two slices, one for read and one for write.
-
The part of the code which executes
kadDht.FindProviders, loops over the returned peers, and opening new streams for writing was moved into an endless loop inside a goroutine. The already existing peers and write connections, respectively, were ignored. -
The prompt was changed so that the sender is shown.
-
The default
rendezvousStringwas replaced by a UUID
Finally, it was close to a real chat 
e.g. my last test with nine running chats:
Having a fresh UUID and after some time (~3min) all nine chats, I had started, can send messages and seven do receive from all other. So two chats had lost nearly all of their read connections.
Here the problems or challenges:
-
Although, the
hosthas[]ma.Multiaddrand thekadDht.Providewas successfull, thekadDht.FindProvidersreturns the appropriate peer without addresses (Issue #23) -
If the chat is killed, new chats show errors related to the old peers, which are still returned from
kadDht.FindProvidersbut can not be found anymore (Issue #24).
I hope, if I spread into the internet and start the chats not only on my laptop locally, it still works, or I will be able to fix it.
Tomorrow, I plan to refactor the code and make it presentable.
Comments or tips are appreciated.
Cheers, Stefan
.