-
Notifications
You must be signed in to change notification settings - Fork 412
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
feat: add /how-to/detect-ipfs-on-web #1295
base: main
Are you sure you want to change the base?
Conversation
|
docs/how-to/detect-ipfs-on-web.md
Outdated
@@ -0,0 +1,127 @@ | |||
# Detect IPFS on the Web |
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.
Title should probably be more general, because is not just about detection. eg "Handling IPFS Content in Web User Agents" or something in that direction.
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.
We already have "Addressing IPFS on the Web" so I went with similar title, but not feeling strong either way.
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.
It seems like this document helps to bridge the web2 -> web3 gap by showing web2 apps/services how to use ipfs.
Maybe "Discovering IPFS content from web2" or something?
|
||
```mermaid | ||
flowchart TD | ||
Start[Top-level navigation event] |
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.
If diagram only handles top-level navigation events, should add a note because policy there is typically different than other load points. Maybe point also to the test page.
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 path detection diagram is generic enough to be applied to subresource requests too – the usual limitations we experience are vendor specific (example: ipfs/ipfs-companion#1095).
TODO(note to self): think how to convey that. Probably change labels on diagram to be about all requests + add section explaining caveats around "top-level navigaton" and "subresource requests" on HTTP and ipfs://
.
- If "IPFS Gateway Redirect / Protocol Upgrade" feature is enabled, and the HTTP URL was a gateway one, redirect automatically to `ipfs://cid/path?query#hash` | ||
|
||
### Mutable `/ipns/key/..` | ||
- Display "Open via IPFS" button in UI | ||
- Clicking it should open `ipns://key/path?query#hash` (preserving any `?query` or `#hash` from the original HTTP URL) | ||
- If "IPFS Gateway Redirect / Protocol Upgrade" is enabled, and the original HTTP URL was a gateway one, redirect automatically to `ipns://dnslink/path?query#hash` |
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.
It's not clear what "IPFS Gateway Redirect / Protocol Upgrade" is exactly, nor how I enable/disable it. Is this a companion feature, or a pseudo-docs
feature that consumers of this document would want to implement? If necessary, can we link to more information?
IsCachedDNSLink ==>|YES| ValidDNSLink | ||
IsCachedDNSLink -->|NO| IsHeaderPresent |
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 feel like "IsCachedDNSLink" is an unnecessary addition to the large flowchart that could be removed to clean things up a little bit. Mentioning that the resolved DNSLink could be cached is something that could be clearer given a separate description. There are pros and cons for users caching the resolved DNSLinks that could be mentioned in that separate description (or separate DNSLinks doc?)
docs/how-to/detect-ipfs-on-web.md
Outdated
@@ -0,0 +1,127 @@ | |||
# Detect IPFS on the Web |
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.
It seems like this document helps to bridge the web2 -> web3 gap by showing web2 apps/services how to use ipfs.
Maybe "Discovering IPFS content from web2" or something?
|
||
- Display "Open via IPFS" button in UI | ||
- Clicking it should open `ipns://dnslink/path?query#hash` (preserving `?query` or `#hash` from the original HTTP URL) | ||
- If "DNSLink Website Redirect / Protocol Upgrade" is enabled, redirect automatically to `ipns://dnslink/path?query#hash` |
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.
ditto. it may be useful to mention a list of "barebones features" that builders reading this doc may want to implement, describe a brief functionality, and then link to those from these items.
It would also clean up these sub-bullet points by centralizing them
- It is a good practice to internally cache the fact that domain has a valid DNSLink. | ||
- TTL from TXT record can be used as a hint when to expire cache entry. | ||
- Performance can be improved further by using cached flag and revalidating it asynchronously, without blocking browser navigation. |
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.
we should put an asterisk in the flowchart when talking about getting DNSLink, and reference this part
@ElPaisano Yes, this is still needed, just had no bandwidth to land it :( FYSA had some related discussions during IPFS Thing and alternative long term home for things like this could be "Integrations" section at https://specs.ipfs.tech (to be added), where we would have this flow, and also have things like ipfs/specs#360. We could merge this as-is, so at least we have something, and then move to specs, once we have “integrations” section there, and only have a simplified diagram in docs. |
+1 on merging so we have something, and the moving to specs when it's ready to house it. Can you tackle this please @ElPaisano ? |
from @lidel: This is fine to merge, but also ok to keep as a draft until we have time to move this to the specs repo. |
This adds a page with some best practices around detecting IPFS resources on the web, based on recent discussions with Brave team and our effort to streamline implmenetation there.
3ed7743
to
5020d3b
Compare
@lidel this is ready for review. Made some adjustments Main thing that is not clear to me is this section https://bafybeiblvih4yq6cbkxd7tauokc6qaxvvsvraftj7wa6sza6qyt5ggdbha.on.fleek.co/how-to/detect-ipfs-on-web/#what-to-do-with-detected-paths (starting on line 88) Given that "The goal of this page is to provide some suggestions and best practices for Web 2 web browsers and other user agents that are interested in adding support for content-addressed resources.", do you mean that any browsers supporting IPFS should implement an "Open via IPFS" button that displays one of the various path types listed? I think SgtPooki had similar comments. Also, #1295 (comment) is still not clear to me |
This PR:
/how-to/detect-ipfs-on-web
page with some best practices around detecting IPFS resources on the web, based on recent discussions with Brave team and our effort to streamline implementation there.As per usual, apologies for any grammar errors ;-)
PR preview
👉️ https://github.com/ipfs/ipfs-docs/blob/feat/how-to-implement-support-in-a-web-browser.md/docs/how-to/detect-ipfs-on-web.md
Website preview (static)
👉️ https://bafybeicp2oota2okffb4u6ta6gzx46jnpyyzxdrrzpzivtbo4xv6sfefim.on.fleek.co/how-to/detect-ipfs-on-web/
To see how the final docs.ipfs.tech version would look, see Fleek preview link in the CI section below.