Rationale

Currently IPFS doesn't expose any way to know if a gateway is running and what it's URL is. One could opt to use the IPFS API to figure this out but that's quickly rather complicated to implement properly. Providing a file indicating that a gateway is running where the content of the file is the gateway URL would be a simple portable way for applications to detect a running IPFS gatew

• Version: 0.11.0
• Subsystem: ipfs-http-client

Severity: Very Low

Description:

I tried using an instance of the https client using TS just like how it's in the docs. When I did create the instance my IDE complained about type errors.

Steps to reproduce the error:

I created the instance like this by looking at the [README](https://github.com/ipfs/js-ipfs/blob/ma

In Settings : 'Add a new side account' button

Step #2 in Side account creation

(a very light & quick version of onboarding, with only nickname step)
![side account mode copy](https://user-images.githubusercontent.com/37345040/99953009-dd7db900-2d80-11eb-9f6f-e

The current downloads listed in the install section of the readme are version 0.17 while the current version is 0.18.1.

I think we should not link specific versions here, but link to the release list on Github.

Cooking Recipes - Around 50GB of formatted and unformatted cooking recipes. Source

This one does not seem to have any providers. ipfs dht findprovs QmTXo6GforwsuGAd8behjgvKCsMMBdG1xMZJF4qa9W7CHB doesn't print anything.

Siderus Orion - Easy to use IPFS desktop client for macOS, Windows and Linux Source

This project is no longer active and the maintainer has taken it down

There are multiple functions that return Result<T, ()> in the code, this is equivalent to Option<T>, however instead of changing those to optional types, these should return useful error messages/types so it's easier to debug.

Example: https://github.com/graphprotocol/graph-node/blob/79390c39a13f166999ceea8defc55eedd05265ab/graph/src/data/subgraph/mod.rs#L169

Some of them could just retu

This example
https://github.com/libp2p/js-libp2p/blob/master/examples/peer-and-content-routing
Involves running two scripts simultaneously; they then connect to each other. Each one does this before calling findPeers

// The DHT routing tables need a moment to populate
await delay(100)

This is fine for an example/test but is not good enough for production code. There's no indicat

Seems that Firefox (around version 96-97) changed somethign and is now way more aggresive when a gateway does not start returning response immediately.

For example, first load (empty ipfs repo) of http://dist.ipfs.io.ipns.localhost:8080/go-ipfs/v0.11.0 in Firefox 97 produces:

![2022-02-11_19-09](https://user-images.githubusercontent.com/157609/153646056-9bc942ec-bec7-4f0a-b61b-53db7bf6896

Describe the bug
When typing things like /ipns/k51..., /ipns/ipfs.io into the browse/inspect bar if you hit inspect it'll take you to the explore page and will error.

This bug might be related to explore.ipld.io more than here, but since we depend on similar components I'm filing here. Feel free to move or redirect.

There are a variety of errors depending on the mutable identifier t

This was cut from the v0.2.0 release for present time constraints however making ipfs-http more accessible as "the" ipfs binary would make the project more accessible to anyone just wanting to try it out. At the moment I see the following obstacles:

• http/README.md has no tutorial on how to try out ipfs-http
• ipfs-http supports only `i

Summary

This is the main tracking issue for Naming Providers support. Naming providers can be either DNS - for use with DNSLink - or even naming services such as ENS and IPNS.

Ideally even doing things like detecting the provider from the domain name and doing the right thing.

Status

Check whether same title and link by same user exists from frontend.

This is a very wellknown bug.. For example..