Now that the backend infrastructure is starting to solidify and browser integration is being considered, I think it's a good time to start looking at the UX of IPFS, what the experience for most users should be. Most users aren't going to extract tarball and run CLI daemons. They need an simple click-button solution that Just Works and doesn't make them think before they start using IPFS.
With that in mind, here's what I would build for a browser integration, if I had complete control over the browser API and there were no limitations in what we could do with the browser. Really this is just personal ruminations on how to make the IPFS experience better for end users.
ITERATION 1 (bread and butter)
The user learns about IPFS and is interested in trying it. They visit https://ipfs.io, and there is immediately (after a short description) a button to install the IPFS plugin for their browser. User installs the extension for browser, which is a webextension so it works with both Firefox and Chrome. This is the majority user experience - most end users will not be running full nodes. The power users will have the option to download the daemon, which is essentially the server for people that want to do power lifting (serving and coding). But the daemon download is not the main track.
Installing the extension does not require any external dependencies of any kind. It uses a JS-based IPFS client to connect to peers on the bootstrap list (including at least one which is an anycast network to speed up the bootstrap and setup). After installing the plugin, the user is peered with the network and ready to access IPFS content. In a later version of the plugin, we could discuss having either-or support for the daemon or the in-browser JS version, but for the first iteration I would just focus on js-ipfs.
Immediately after installation, the browser connects to an IPFS "Thanks, you're now on the distributed web!" page that has a lot of getting started information and stuff for the users to try. It also has instructions on how they can make their own distributed web site should they choose to, IPFS news, ect (insert welcome page ideas here).
FUNCTIONALITY
The plugin, in RFC parlance, MUST enable these three things for Iteration 1:
IPFS immutable lookups: ipfs://MULTIHASH
IPNS mutable lookups: ipns://PUBKEYMULTIHASH
DNSLINK lookups: Schemaless lookup (ex: domain.name typed into the address bar with no provided schema) or ipfs://domain.name or ipns://domain.name.
FS lookups: /fs/ipfs/MULTIHASH
FS lookups should be considered for implementation only if it can safely handle cross-origin security issues. The "legacy" URI options will still be supported.
DNSLINK
I expect that the vast majority of all web IPFS user activity will actually involve DNSLINK, and should be considered to be the most frequently used. Both IPFS and IPNS protocol schemas typed in for a domain should work for the initial DNSLINK lookup, but the schema can be changed to reflect whatever the resulting content actually is.
When user looks up any domain name without a schema, the extension instructs browser to check for dnslink TXT record before proceeding to AAAA/A. Web browsers already do this with IPv6/IPv4 by starting with AAAA and falling back to A, which works well. We're just adding one more link to the chain. If a DNSLINK record is found, redirect to ipfs://domain or ipns://domain (depending on which is correct). Indicate strongly to the user by icon brightness, URL bar colors, ect. that the site is being powered by IPFS rather than HTTP.
PLUGIN DASHBOARD:
When the user clicks on the top-right icon, it goes to a very simple dashboard landing page. A better dashboard is for iteration 2, for iteration 1, just focusing on the core functionality.
ITERATION 2 (better dashboard)
PLUGIN DASHBOARD
When the user clicks on the IPFS icon on the top right in their browser after installing it, a much better dashboard loads that is full of getting started information, documentation, news, ect, complete with example sites/datasets to visit using IPFS. Very similar to the WebGUI for the daemon, but far cleaner and more end-user oriented.
At least some of the content may be an IPNS site, allowing IPFS to dynamically make changes to it.
ITERATION 3 (pinning and network assistance):
WHEN AN IPFS SITE IS LOADED
Additional icons on the right of the URL bar appear on the browser:
Pinning: Allows the user to pin the content, which is treated similarly to a bookmark. Upon click, a dialogue pops up asking the user to name the Pin. If the content is HTML, derive the name from the HTML
Now that the backend infrastructure is starting to solidify and browser integration is being considered, I think it's a good time to start looking at the UX of IPFS, what the experience for most users should be. Most users aren't going to extract tarball and run CLI daemons. They need an simple click-button solution that Just Works and doesn't make them think before they start using IPFS.
With that in mind, here's what I would build for a browser integration, if I had complete control over the browser API and there were no limitations in what we could do with the browser. Really this is just personal ruminations on how to make the IPFS experience better for end users.
ITERATION 1 (bread and butter)
The user learns about IPFS and is interested in trying it. They visit https://ipfs.io, and there is immediately (after a short description) a button to install the IPFS plugin for their browser. User installs the extension for browser, which is a webextension so it works with both Firefox and Chrome. This is the majority user experience - most end users will not be running full nodes. The power users will have the option to download the daemon, which is essentially the server for people that want to do power lifting (serving and coding). But the daemon download is not the main track.
Installing the extension does not require any external dependencies of any kind. It uses a JS-based IPFS client to connect to peers on the bootstrap list (including at least one which is an anycast network to speed up the bootstrap and setup). After installing the plugin, the user is peered with the network and ready to access IPFS content. In a later version of the plugin, we could discuss having either-or support for the daemon or the in-browser JS version, but for the first iteration I would just focus on js-ipfs.
Immediately after installation, the browser connects to an IPFS "Thanks, you're now on the distributed web!" page that has a lot of getting started information and stuff for the users to try. It also has instructions on how they can make their own distributed web site should they choose to, IPFS news, ect (insert welcome page ideas here).
FUNCTIONALITY
The plugin, in RFC parlance, MUST enable these three things for Iteration 1:
FS lookups should be considered for implementation only if it can safely handle cross-origin security issues. The "legacy" URI options will still be supported.
DNSLINK
I expect that the vast majority of all web IPFS user activity will actually involve DNSLINK, and should be considered to be the most frequently used. Both IPFS and IPNS protocol schemas typed in for a domain should work for the initial DNSLINK lookup, but the schema can be changed to reflect whatever the resulting content actually is.
When user looks up any domain name without a schema, the extension instructs browser to check for dnslink TXT record before proceeding to AAAA/A. Web browsers already do this with IPv6/IPv4 by starting with AAAA and falling back to A, which works well. We're just adding one more link to the chain. If a DNSLINK record is found, redirect to ipfs://domain or ipns://domain (depending on which is correct). Indicate strongly to the user by icon brightness, URL bar colors, ect. that the site is being powered by IPFS rather than HTTP.
PLUGIN DASHBOARD:
When the user clicks on the top-right icon, it goes to a very simple dashboard landing page. A better dashboard is for iteration 2, for iteration 1, just focusing on the core functionality.
ITERATION 2 (better dashboard)
PLUGIN DASHBOARD
When the user clicks on the IPFS icon on the top right in their browser after installing it, a much better dashboard loads that is full of getting started information, documentation, news, ect, complete with example sites/datasets to visit using IPFS. Very similar to the WebGUI for the daemon, but far cleaner and more end-user oriented.
At least some of the content may be an IPNS site, allowing IPFS to dynamically make changes to it.
ITERATION 3 (pinning and network assistance):
WHEN AN IPFS SITE IS LOADED
Additional icons on the right of the URL bar appear on the browser:
Pinning: Allows the user to pin the content, which is treated similarly to a bookmark. Upon click, a dialogue pops up asking the user to name the Pin. If the content is HTML, derive the name from the HTML