-
Notifications
You must be signed in to change notification settings - Fork 409
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
Update gateways info #1531
Conversation
There was a problem hiding this 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.
|
||
## When not to use a gateway | ||
|
||
### Delay-sensitive applications |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
### Delay-sensitive applications | |
### Latency-sensitive applications |
Use latency, as that's the standard nomenclature.
Co-authored-by: Daniel Norman <1992255+2color@users.noreply.github.com>
@2color I think I addressed your comments in the updates |
There was a problem hiding this 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. |
There was a problem hiding this comment.
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?
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 |
|
||
|
||
|
||
## Avoiding centralization |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this 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.
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: