No gRPC address configured

[Tcll]

just updated jsipfs after numerous invalid address errors:

Error: The dial request has no addresses
    at Dialer.connectToPeer (/home/tcll/.nvm/versions/node/v14.8.0/lib/node_modules/ipfs/node_modules/libp2p/src/dialer/index.js:113:21)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async Libp2p.dialProtocol (/home/tcll/.nvm/versions/node/v14.8.0/lib/node_modules/ipfs/node_modules/libp2p/src/index.js:454:20) {
  code: 'ERR_NO_VALID_ADDRESSES'
}

and now the daemon fails to initialize:
No gRPC address configured, please set an Addresses.RPC key in your IPFS config

I have no idea what it's asking me to do specifically here (aside from "Addresses.RPC": {}), and I can't seem to find any relevant info from DDG other than grpc-ipfs-lite

[Tcll]

oh it looks like I misunderstood what it was asking
not "Addresses.RPC" but instead:

"Addresses":{
    "RPC":"???"
}

it's not made clear what I should put there
but a string is absolutely required because .split() is used on the value

it's a shame I can't use go-ipfs yet or I could roll back to a previous executable I've downloaded, since npm is not portable.

[Tcll]

sorry about multiple posts, but GitHub won't let me edit
possibly malicious 3rd-party domains being used in scripts (if so, then this was predicted long ago)

but yeah, this doesn't work either:

"Addresses":{
    "RPC":""
}

all this does is give me an error:

Error: listen EADDRINUSE: address already in use 0.0.0.0:4002
    at Server.setupListenHandle [as _listen2] (net.js:1316:16)
    at listenInCluster (net.js:1364:12)
    at doListen (net.js:1501:7)
    at processTicksAndRejections (internal/process/task_queues.js:81:21) {
  code: 'EADDRINUSE',
  errno: -98,
  syscall: 'listen',
  address: '0.0.0.0',
  port: 4002
}

also sorry it took so long to update on this
Nemo FM decided it was gonna delete my config when I went to delete an image from a flash drive
(had to finish restoring my workstation before I could restore my config from a backup on it)
apparently Nemo got stuck into thinking I was in my .jsipfs/ directory, and crashed shortly after
(Nemo has always crashed for me for various reasons, but getting stuck in a directory is relatively new, and this is a first it's ever cost me)
so yeah, I've been having a fun, totally not stressful, day all day :D

and this issue only compounds it
I wish I could roll back =3=

[Tcll]

just found this:
https://docs.ipfs.io/how-to/configure-node
I see the site still harms freedom with Google malware

but anyways, there's no mention of Addresses.RPC here
and my daemon has been offline since this issue was created
that's over 1000 images that aren't displaying for people because of this issue
and some forums may remove posts if this goes on any longer.

[Tcll]

just tried downgrading to npm i -g ipfs@0.54.0, where npm i -g ipfs@0.54.5 gave me the previous Cannot read property 'split' of undefined error but worked anyways
and that didn't want to work...
I even tried 0.53.2 and verified 0.54.X was what I was last using (not sure exactly which version I'd used)

so not only did the latest version refuse to work due to requiring an undocumented functionality
but I can't even downgrade to get my daemon back online.
this is shameful

also yep, I had to enable malware just to upload that image (and these images):

Amazon domains are malware, and there's also a lot of malware being used on this page: (not everything here)

this is also shameful
why are you guys complicit with a social credit system?? :D
EDIT: this is also backed by the fact you use google-analytics (you don't like freedom if you use any of this malware)
(yes I can edit now that I've temporarily enabled malware)

[Tcll]

well, at least for some good news out of this, it seems discovery is the only thing that's affected
I've reinstalled the latest version, and it actually does run, and I can list files and such:

$ jsipfs files ls /Pictures/electronicsDVI2VGA.png
PCIe
WIP_wii
Wii Compendium Images
components
dream PC
my_wii
s-l1000.jpg
wii

but hashes don't connect, and the WebUI still shows nothing

so my daemon runs, but nothing is accessible

[Tcll]

still down as of today

I can upload files to my daemon just fine, but can't distribute them
for verification, here's the reason I don't host my projects on GitHub:

^ this image won't load until my daemon is accessible again

[lidel]

@Tcll do you mind providing one-paragraph summary of the issue? It will make it easier/faster for the team to help/advise.

[Tcll]

to summarize, I don't even need a paragraph

as explained via this image:

the daemon runs just fine, and I can manage files and all via CLI
but ever since the update, the web UI has failed to connect to the daemon, as well as nobody has been able to see my content.

I have thousands of links in many viarious places and all of them have been down since the initial update.
for confirmation my daemon is currently running, so you should be able to see the image marked in the previous post.

[Tcll]

also, the malware mentioned in this image may have been a false positive:

apparently the wappalyzer extension was caching "technologies" from other pages, so what's shown may not be what's provided.
I apologize for wrongful assumption if so.

[achingbrain]

@Tcll please can you please upgrade to the latest version and try again? There was a bug around reading the gRPC address out of the config but it's since been fixed.

[Tcll]

thank you, that update restored the webui
though I'm still getting an unknown issue:

not currently sure what's causing that :/

EDIT:
another problem with the update:

tcll@tcll-compact:~$ jsipfs files stat /Pictures/info/Microsoft_GitHub.png
/Pictures/info/Microsoft_GitHub.png does not exist

where'd all my files go??

EDIT2:
that had me spooked
I just downgraded to the previous version, and they're still there:

[achingbrain]

though I'm still getting an unknown issue

Can you try starting the daemon with debugging enabled, it should show the stack trace:

$ DEBUG=ipfs* jsipfs daemon

[achingbrain]

Also, please update to ipfs@0.58.0, it'll fix the missing MFS files problem. Will backport the fix to ipfs@0.57.0 and ipfs@0.56.0 but it'll take a little while.

[Tcll]

alright so I've updated and backed everything up before running
(this'll probably be the last time I update for a while, unless I can actually port my repo over to go-ipfs with added mtime support since I'll have more control over that and can finally delete npm)

in any case, I ran the debug command, here's the line with the error:

HTTP API listening on /ip4/127.0.0.1/tcp/5002/http
  ipfs:cli TypeError: Cannot read property 'info' of undefined
  ipfs:cli     at Object.handler (/home/tcll/.nvm/versions/node/v14.8.0/lib/node_modules/ipfs/node_modules/ipfs-cli/src/commands/daemon.js:108:53) +0ms

unfortunately that's all that was given or I'd have more detail to give

also for verification, both MFS and the webui work ;)
(I should probably build an OpenGL UI whenever I have some free time as that would be more responsive and use far less resource)