make our IPFS hosted sites more obvious?

[jbenet]

• The nice CNAME/A trick for our sites (ipfs.io, dist.ipfs.io, blog.ipfs.io, ...) is awesome
• We got it super clean and nice, but... it hides away the magic. so few people get it. it hides that it's going over IPFS.
• Maybe we should do that only to some? and have a doc explaining both.
• It may be really useful for now (2016, maybe early 2017) to redirect <project-domain> -> <gateway>/ipns/<project-domain> to make it OBVIOUS for now, and go back to clean later?

thoughts @lgierth @whyrusleeping @diasdavid ?

[Kubuxu]

We can setup nginx to do the general <domain> -> <gateway>/ipns/<domain> redirect but separate IPv4 would be needed.

@jbenet on another thread:

We probably should distinguish:

1. A global gateway that people CAN remap themselves in communities.
2. A definitive global gateway that we control ( (1) resolves via (2) by default )
3. The project's website.

It can still be all wrapped into one domain, but probably whatever we tell people to use as links should be (1).

Other:

• gateway.ipfs.io is too long
• i think we got ipfs.link, we could prefer that one going forward. (or even fs.link or fs.io)
• the original goal was to get the ipfs TLD, we can still do that eventually.

I agree the three roles should be separated, so that we encourage remapping/hijacking in a clean and safe way.
There's a trade-off here between which roles to move away from ipfs.io.

• move project website to e.g. ipfs-project.org
  • must move email addresses away
• move "definitive global gateway that we control" to ipfs.link
  • I have the feeling that http://ipfs.io/ipfs/ is pretty established,
    but I think we can do it if we make it really obvious how it's ipfs.link, not ipfs.io.
• move hijack-gateway to ipfs.link
  • if ipfs.io/ipfs/ is the widely used URL, a mesh-local gateway at ipfs.link will never get hit.

So maybe: ipfs.io stays with the IPFS team, ipfs.link is the canonical name.

• canonical IPFS-HTTP URL: http://ipfs.link/ipfs/hash
  • on the internet, it resolves to solarnet gateway (A/AAAA records to same hosts).
  • it contains no other records, subdomains, or zones.
    • except: CNAME _dnslink.ipfs.link to a small page explaining gateway and IPFS-HTTP URL semantics
  • anyone is encouraged to hijack this zone
    • must be A/AAAA/CNAME only
    • must preserve _dnslink.ipfs.link
• solarnet gateway run by IPFS team: http://ipfs.io
  • keeps email addresses
  • keeps old ipfs.io gateway URLs working
    • they just won't be hijackable
  • every website path redirects to http://ipfs.link/ipns/ipfs.io/*
    • makes the workings obvious
    • maybe do the same for every other page we host (dist, chat, etc.)

We should then also stop encouraging pointing CNAME to gateway.ipfs.io for "custom-domain pages",
and pointing it to ipfs.link instead. This would have the neat side-effect, that
any custom-domain page could be served by a mesh-local IPFS gateway
(except for the DNS lookups of course).

BTW, ipfs.link is taken -- we could try to get it, or get something like ipfs.web.

Sorry for maybe overloading the issue :) Yes we can definitely do the simple redirect of ipfs.io -> ipfs.io/ipns/ipfs.io

This might be confusing though without separating the canonical-URL-role from the project-website-role (see above).

[daviddias]

Why not start having a "Hosted and Served through IPFS" Ribbon, like:

An then we can even add the respective hash to the ribbon, so that people could click and load it through an ipfs.io/ipfs/HASH link

[RichardLitt]

I could add it to the os-protocol, and we could talk about that somewhere.

On a sidenote, the .web gTLD is auctioned on July 27th [1] so there's at least some movement in that regard.

[1] http://domainincite.com/20364-web-has-an-auction-date

[jbenet]

@lgierth captured all the things. Totally agreed.

• +1 to ipfs.link (I know who has it, I think we can get it)
• the ipfs.io prefix is http only and fairly new. We can remap what is
  canonical, like we did with gateway, we just need to make sure we always
  support it (redirect or proxy through)
• hijacking encouraged but we should stipulate that they must return the
  right content, and we need to encourage users of http links to verify the
  content where possible.
• ipfs.web maybe-- link I think is more obvious what's going on (gateways
  exist at .link, like onion.link)
  -1 on injecting ribbon, since that modifies people's stuff. We can have the
  ribbon on our own sites. An encouraging users to add it
  On Sun, Jul 10, 2016 at 19:45 Lars Gierth notifications@github.com wrote:

On a sidenote, the .web gTLD is auctioned on July 27th [1] so there's at
least some movement in that regard.

[1] http://domainincite.com/20364-web-has-an-auction-date

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#173 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAIcoZnNFFO3v4B8cW2j8mZYlVI5u32lks5qUYQtgaJpZM4JD87y
.

[Kubuxu]

For some time I am thinking about set of small js scripts for helping support ipfs. Like: web+fs redirection, pin-it iframe when API tokens come out, it could be a ribbon too.

[x5engine]

ipfs.link still no one?

[mkg20001]

hijacking encouraged but we should stipulate that they must return the
right content, and we need to encourage users of http links to verify the
content where possible.

I've got a nice idea: The ribbon could be opt-in via a DNS TXT record, so it wouldn't mess with sites that don't want to have it
For example TXT _ribbon.libp2p.io "v=1,enabled=true" would enable the ribbon on the libp2p.io site if it is retrieved through the gateway

It could be further extended with parameters like a pattern to tell it when it should trigger (so that certain pages the are embedded in others don't have it, though it should be fairly easy to detect iFrames by default) and possibly a color/theme option.

The code to inject and display it could also be part of the upstream ipfs and hidden under an option/flag

Opinions?