IPFS node doesn't connect on dApp start

[zseko]

Operation System

Ubuntu 20.04

TokelPlatform-1.2.0.AppImage

Bug

About 30 seconds later I get the following popup, see attachment.

[zseko]

Now I got this

[lenilsonjr]

Thanks. Those two seem unrelated. The first screenshot you attached is probably an error happening when starting the IPFS node.

If you can attach logs, that would greatly help us understand where the error is happening 😄

on Linux: ~/.config/{app name}/logs/{process type}.log 
on macOS: ~/Library/Logs/{app name}/{process type}.log
on Windows: %USERPROFILE%\AppData\Roaming\{app name}\logs\{process type}.log

[zseko]

I don't have any logs, but I think the error comes from the following file:

https://explorer.tokel.io/tokens/0b47a8488ca2e9797535397d3d5d866d7fda33fb61bad83db95172e834a47e59/transactions

Here I used a hash that the origin hash of IPFS redirects to.

ipfs://QmPgLWCmFW5Ajo21pWEVyVmmym3Ms7t6wHxw8J6Xisa8Hw

redirects to

ipfs://bafybeiat4236rpbyu254x5fjvic7arv7jmy6hxacj5m4kyqm6vkwc4jxi/

Probably, I can't say for sure, the IPFS node of the dApp can't handle it.

EDIT: That was definitely the reason why the image could not load. I have burned the token.

[zseko]

That is the only what I can find in Session Storage:

2021/12/15-10:38:46.813 258ca Reusing MANIFEST /home/ubuntu/.config/tokelPlatform/Session Storage/MANIFEST-000001
2021/12/15-10:38:46.814 258ca Recovering log #3
2021/12/15-10:38:46.814 258ca Reusing old log /home/ubuntu/.config/tokelPlatform/Session Storage/000003.log

[lenilsonjr]

So, far I've seen some reasons for the local node to not resolve IFPS hashes:

• The dApp IPFS node fails to initialize because there's an existing repo.lock in place, leftover from a previous non-graceful exit, or from another instance of IPFS currently running
• The dApp IPFS node fails to initialize because it can't setup the IPFS repo locally (maybe bad permissions?)
• The IPFS hash fails to resolve because there's not enough peers connected to find the file
• The IPFS hash fails to resolve because the local node can't fetch data, maybe due to firewall configuration or internet

It's important to note that due how IPFS works, some queries maybe just take very long to resolve, so I can imagine some folks don't wait enough for their content. We can improve this however by adding more relevant peers on initialization.

This commit has some exploratory work on connecting to more peers on initialization. I'm however facing some AbortController errors which I imagine are due to mismatching nodejs versions.

Going forward, I suggest we change our implementation of IPFS to be separated in two parts:

1. the node we already have in the main process, which should exit gracefully (🛠 Use ipfs.io as fallback to in-app IPFS node #255) and respect any other existing IPFS nodes in the machine.
2. an ipfs-http client in the renderer process, that will try to connect to our built-in node if possible, or other local nodes, but may as well connect to any other IPFS node specified in dApp settings (better than using an http gateway)

[NutellaLicka]

@lenilsonjr Has this issue been addressed in the latest releases, or is it still possible?