Ideas for IPFS UX #53
Comments
kyledrake
changed the title
kyledrake
changed the title
|
Fantastic write-up! My 3 cents: Limitations present right now in Firefox 53No ability to register schema without prefixSugar-coating on top of No Address Bar Control (and No Origin Control)No support right now, but there is an open ticket about adding more advanced WebExtension API for programmable protocol handler: https://bugzilla.mozilla.org/show_bug.cgi?id=1271553. This ticket is a good place for lobbying, if anyone has time and energy. 🙃 No support for DNS TXT lookups for DNSLINKThis one is quite a pain right now: DNSLINK lookup without browser API for reading Creating a new, separate bugzilla ticket with WebExtension API request for DNS TXT lookups may be a next step here (Ideally created by someone from Protocol Labs, as I failed 🙃 ) Possible approaches (How to move forward?)I'll continue my work on WebExtension, but releasing stable version will take time due to lacking APIs and Firefox release cycle itself. Until then, one can test alpha releases. I see real benefits of having functional PoC browser and would encourage future work on it. |
|
Thanks @lidel! Much better version with good links. I've seen your name all over the place in Mozilla tickets related to these issues. |
|
FYSA we are moving ideas from Kyle's post closer to reality.
|
|
UX updates:
|
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 <title>, otherwise the user can choose to name it.
Info: Load a screen showing information about the content, such as how many people are "seeding" it (ipfs dht findprovs), a graphical inspection of it's merkle tree, ect. No specific requirements here, just things that are interesting. Follow Pareto's law here, don't add the hard 20% to it for now.
NETWORK PARTICIPATION
The IPFS browser plugin should not participate in the network by default, except for purposes of retrieving data. The user must opt-in to help the network, either by clicking a checkbox in settings (or an on/off switch), or by pinning some content. I would focus on the IPFS daemons being the "full nodes" and the browser plugins being the "thin clients" for now.
PLUGIN DASHBOARD
Inspection and management of cached/pinned content.
Limitations preventing this interface
Right now there are some pretty fundamental problems with getting any of this to work with the current APIs provided by web browsers. The biggest hurdles currently are:
No navigator.registerProtocolHandler support for webextensions in Chrome
This functionality allows web sites to redirect traffic sent to schemas to URLs elsewhere. Chrome does not support this for webextensions at all. Firefox is providing support in an upcoming version of Firefox via the manifest file (https://bugzilla.mozilla.org/show_bug.cgi?id=1271553).
No ability to register schema without prefix
For registerProtocolHandler management, we are required to prefix web+ or ext+ to schemas in order to use them (ex in Firefox: ext+ipfs://HASH). This makes the URL schemes above not possible without a pretty ugly user experience.
No support for DNS TXT lookups for DNSLINK
The only people even talking about it are Mozilla, and they've slammed the door shut on the idea - see https://bugzilla.mozilla.org/show_bug.cgi?id=1343849#c2
A workaround could conceivably be made to resolve DNS records from the P2P network, or to use the gateway (https://ipfs.io), but perhaps not without introducing a central POF or adding a trust problem. There are proposals to do reader-privacy with DNS floating around, I don't think it's IPFS's responsibility to solve it.
No Address Bar Control
This is probably the most damning for getting this to work in browsers IMHO.
Web extensions do not provide any way to handle the address bar. The ideal situation would be that extensions could ask the user for permission to control a schema in the browser, and then have control over the address bar when it's related to their schema. But nobody's talking about it, there's likely a lot of opposition, and no API has ever been proposed to do it.
Possible approaches
Use @lidel's plugin
Lidel's plugin seems the most developed ATM, and seems as close to a good browser extension as is possible at the moment (once the webextension version is released). Try to figure out how we can get the browsers to improve support for the functionality needed.
Build an IPFS browser
I'm strongly leaning in this direction at the moment. History suggests to me that it's going to take years to convince the browsers to provide the functionality needed here, and it's not outside of the realm of possibility that they never will. I'm 100% preferring a browser integration to our own application, but why wait? We can build something on top of Electron that delivers the full UX experience IPFS wants for its users and interesting features that are specific to IPFS right now. js-ipfs can be implemented and run at the nodejs-level, which means we can take advantage of a full networking stack and not have to resort to a bunch of hacky solutions for various browser limitations related problems.
I have a rough POC that uses electron, where you can enter ipfs://HASH and get a response. It's probably not even good enough code base for a starting point, but it demonstrates the point that it would probably be a lot easier to build a browser/GUI based on Electron than it sounds: https://github.com/kyledrake/ipfs-browser-poc
I'll never pretend I'm a great JS developer, but I still managed that much progress in less than a day. What could a solid JS developer put together in a few months?
Thoughts and feedback welcome.
The text was updated successfully, but these errors were encountered: