Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update gateways info #1531

Merged
merged 9 commits into from
Apr 11, 2023
Merged

Update gateways info #1531

merged 9 commits into from
Apr 11, 2023

Conversation

ElPaisano
Copy link
Contributor

@ElPaisano ElPaisano commented Mar 20, 2023

Incorporates some of the content from https://blog.ipfs.tech/2022-06-30-practical-explainer-ipfs-gateways-2/ into existing GW concepts and ref material

Since the blog + the existing https://docs.ipfs.tech/concepts/ipfs-gateway/ page both have alot of contents, this PR:

  • Prunes out best practice and troubleshooting type info from concepts/ipfs-gateway/
  • Puts some best practices in /how-to/gateway-best-practices/
  • Puts troubleshooting info in /how-to/gateway-troubleshooting/

@ElPaisano ElPaisano self-assigned this Mar 20, 2023
@ElPaisano ElPaisano marked this pull request as ready for review March 22, 2023 23:12
@ElPaisano ElPaisano changed the title (DRAFT) Update gateways info Update gateways info Mar 22, 2023
@ElPaisano ElPaisano requested a review from 2color March 22, 2023 23:19
@ElPaisano ElPaisano added the status/ready Ready to be worked label Mar 23, 2023
Copy link
Member

@2color 2color left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for bringing those into the docs. I left some comments on changes since the blog was published.

We should more strongly recommend using subdomain gateway resolution as it provides more security.

docs/concepts/ipfs-gateway.md Outdated Show resolved Hide resolved
docs/concepts/ipfs-gateway.md Outdated Show resolved Hide resolved

## When not to use a gateway

### Delay-sensitive applications
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Delay-sensitive applications
### Latency-sensitive applications

Use latency, as that's the standard nomenclature.

docs/how-to/gateway-best-practices.md Outdated Show resolved Hide resolved
docs/how-to/gateway-best-practices.md Outdated Show resolved Hide resolved
docs/how-to/gateway-best-practices.md Outdated Show resolved Hide resolved
docs/how-to/gateway-best-practices.md Outdated Show resolved Hide resolved
docs/how-to/gateway-troubleshooting.md Outdated Show resolved Hide resolved
docs/how-to/gateway-troubleshooting.md Outdated Show resolved Hide resolved
docs/how-to/gateway-troubleshooting.md Outdated Show resolved Hide resolved
@ipfs ipfs deleted a comment from azimanuar5874 Mar 23, 2023
@ipfs ipfs deleted a comment from azimanuar5874 Mar 23, 2023
ElPaisano and others added 3 commits March 23, 2023 12:46
Co-authored-by: Daniel Norman <1992255+2color@users.noreply.github.com>
@ElPaisano ElPaisano requested a review from 2color March 23, 2023 19:56
@BigLep
Copy link
Contributor

BigLep commented Mar 24, 2023

FYI @lidel or @hacdias if you have anything you want to add here.

@ElPaisano
Copy link
Contributor Author

Thanks for bringing those into the docs. I left some comments on changes since the blog was published.

We should more strongly recommend using subdomain gateway resolution as it provides more security.

@2color I think I addressed your comments in the updates

Copy link
Member

@hacdias hacdias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't have time yet to go over the whole document, but I noticed there aren't any mentions for the gateway specifications. I would add some mention that the specification for the different types and parts of the gateways are available at https://specs.ipfs.tech/http-gateways/ - that'd be great visibility with information for those who want to implement their own gateway.


IPFS deployment seeks to include native support of IPFS in all popular browsers and tools. Gateways provide workarounds for applications that do not yet support IPFS natively. For example, errors occur when a browser that does not support IPFS attempts access to IPFS content in the canonical form of `ipfs://{CID}/{optional path to resource}`. Other tools that rely solely on HTTP encounter similar errors in accessing IPFS content in canonical form, such as [Curl](https://curl.haxx.se/) and [Wget](https://www.gnu.org/software/wget/).
- **If the CID is not in the local cache**, the gateway will attempt to retrieve it from the network.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the gateway will attempt to retrieve it from the network

That is the default of Kubo. However, there might be gateways that only serve content that they have and/or want to provide. For example, a Kubo gateway with NoFetch enabled will not attempt to retrieve content from the network. I'm not sure if we should keep this, or remove it. Opinions?

ElPaisano and others added 2 commits April 3, 2023 17:05
Co-authored-by: Henrique Dias <hacdias@gmail.com>
@ElPaisano
Copy link
Contributor Author

ElPaisano commented Apr 3, 2023

I didn't have time yet to go over the whole document, but I noticed there aren't any mentions for the gateway specifications. I would add some mention that the specification for the different types and parts of the gateways are available at https://specs.ipfs.tech/http-gateways/ - that'd be great visibility with information for those who want to implement their own gateway.

Thanks for reviewing @hacdias , much appreciated

I added the spec link in a few place that made sense. RE your first comment #1531 (comment), I added a note at the beginning of the lifecycle section calling out your point, so readers are aware of these nuances. See bb394f2.

If we need to refine this section, I'd prefer to do it in future PRs, as this one has been sitting for awhile now.

Unless anyone reeeeeeeally has any issues with this

cc @2color

@ElPaisano ElPaisano requested a review from 2color April 3, 2023 23:26



## Avoiding centralization
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph is too convoluted.

The tile could be much more specific and direct: avoid hardcoding a gateway URL, e.g. ipfs.io/ipfs/CID in places where possible! It must also acknowledge that it's not feasible in some situations, e.g. embedding image from IPFS on web and that can be worked around by owning the domain and proxying.


Trusting a specific gateway, in turn, requires you to trust the gateway's issuing Certificate Authorities and the security of the public key infrastructure employed by that gateway. Compromised certificate authorities or public-key infrastructure implementations may undermine the trustworthiness of the gateway.

## Use subdomain gateway resolution for origin isolation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be the first one.


Similarly, the use of DNSLink resolution with `Alias` forces requests through the domain's chosen gateway, as specified in the `dnslink={value}` string within the DNS TXT record. If the specified gateway becomes overloaded, goes offline, or becomes compromised, all traffic with that content becomes deleted, disabled, or suspect.

## Misplaced trust
Copy link
Member

@2color 2color Apr 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not really a best practice.

I would remove or move to the bottom

Copy link
Member

@2color 2color left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great improvement. Wonderful to see the new specs page https://specs.ipfs.tech/http-gateways/ linked!

Besides some comments about the best practices, this is good to go.

@ElPaisano ElPaisano merged commit dfdab1d into ipfs:main Apr 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/ready Ready to be worked
Projects
No open projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Document the HTTP Gateway features and functionality for developer users
5 participants