5 ms·

>approach to local first apps on IPFS with the Fission publishing platform and webnative SDK. >Our guiding principle for using IPFS is: Everything should work

>approach to local first apps on IPFS with the Fission publishing platform and webnative SDK. >Our guiding principle for using IPFS is: Everything should work in the browser, including on mobile, with no extensions required. I wonder how these two cope with one another. To me, you're either not local (must connect to be sure your data have persisted) or you need something more than just browser. Otherwise you're at the mercy of browser vendor not to destroy your in-browser data with borked update. Or do I incorrectly understand "local first"?

karlicoss 6y ago
In my understanding you still need an IPFS node running (and then browser connects to it via a websocket) https://talk.fission.codes/t/local-ipfs-connectivity/1535 https://talk.fission.codes/t/local-ipfs-connectivity/1535 So IPFS handles the actual 'local first' aspect in the sense that once your data is cached, you can access it, and once you regain connectivity, it syncs again
- expede 6y ago
  Hey, CTO of Fission here! It depends on what you're trying to do. We actually bootstrap a js-ipfs node directly in the browser, so you always have an IPFS node if your app uses our SDK. It's even set up to communicate across tabs, including handling the security for that use case. If you want to publish something that other people on the internet can see, then yes, you need a path off your machine, such as WebSockets. This can be a peer IPFS node, or to Fission's servers, or your own self-hosted node to provide availability. Part of presenting to the offline-fist SIG was to get more support for parts of this, like communicating between a desktop node (e.g. go-ipfs) and your in-browser js-ipfs instance, which doesn't work out of the box today.
diggan 6y ago
Browsers can do surprisingly much even if you don't have a internet connection. Couple local networks (even local-only networks) with browser being able to communicate them, and you can build local-first applications with just JS in the browser. In the case of IPFS, you can have a IPFS node running locally, have a browser client communicate with it and just store the latest hash of your state (that you can backup outside of the browser too). So if the local state (in the browser) gets lost, you can restore it from the hash. Often used content can be cached in the browser but still stored in your IPFS node.
expede 6y ago
CTO of Fission here! > Or do I incorrectly understand "local first"? I believe that the specific term "local-first" comes from Ink & Switch: https://www.inkandswitch.com/local-first.html https://www.inkandswitch.com/local-first.html > I wonder how these two cope with one another. To me, you're either not local (must connect to be sure your data have persisted) or you need something more than just browser. Otherwise you're at the mercy of browser vendor not to destroy your in-browser data with borked update. Maybe a clarifying one-liner would be "it's local-first, not local-only" ;) There is totally a tension there from not controlling the browser itself. You're absolutely right that the browser can clear it cache pretty much whenever. In practice, this appears to happen less than advertised (the extra caution is a good default!), but it totally does happen. It's something that we've spend a bunch of time trying to figure out the balance on. We also have to recognize that we live in an online world, so there's a bunch of additional work going into making things feel instant when connected. Fission is pushing on both sides of the problem to basically get as close to "your data everywhere all the time" as possible. The principle is that you should be able to show up to a web app and have it "just work" and not know that anything special is happening. Everything should work if you loose connectivity, or are on a plane (if we ever do that again). You should also be able to self-host your data, or have it cached in multiple places (which is a big advantage of IPFS). Fission provides one way to automatically keep a second encrypted-at-rest copy outside of the browser while you have connectivity. There's nothing special about our IPFS nodes; they're just set up to make that smooth for the kinds of thing that you'd want to do with the SDK, and add some niceties like DNS automation so you're not always fiddling with hashes. Part of us presenting to the SIG was to try to get better access to local desktop IPFS nodes, so that those who want to turn the dial to "fully offline" can go further with that.
- ComodoHacker 6y ago
  Thank you for clarification. I've made a note to myself to play with Fission when I have time.

karlicoss 6y ago

In my understanding you still need an IPFS node running (and then browser connects to it via a websocket) https://talk.fission.codes/t/local-ipfs-connectivity/1535 https://talk.fission.codes/t/local-ipfs-connectivity/1535 So IPFS handles the actual 'local first' aspect in the sense that once your data is cached, you can access it, and once you regain connectivity, it syncs again

expede 6y ago
Hey, CTO of Fission here! It depends on what you're trying to do. We actually bootstrap a js-ipfs node directly in the browser, so you always have an IPFS node if your app uses our SDK. It's even set up to communicate across tabs, including handling the security for that use case. If you want to publish something that other people on the internet can see, then yes, you need a path off your machine, such as WebSockets. This can be a peer IPFS node, or to Fission's servers, or your own self-hosted node to provide availability. Part of presenting to the offline-fist SIG was to get more support for parts of this, like communicating between a desktop node (e.g. go-ipfs) and your in-browser js-ipfs instance, which doesn't work out of the box today.

diggan 6y ago

Browsers can do surprisingly much even if you don't have a internet connection. Couple local networks (even local-only networks) with browser being able to communicate them, and you can build local-first applications with just JS in the browser. In the case of IPFS, you can have a IPFS node running locally, have a browser client communicate with it and just store the latest hash of your state (that you can backup outside of the browser too). So if the local state (in the browser) gets lost, you can restore it from the hash. Often used content can be cached in the browser but still stored in your IPFS node.

expede 6y ago

CTO of Fission here! > Or do I incorrectly understand "local first"? I believe that the specific term "local-first" comes from Ink & Switch: https://www.inkandswitch.com/local-first.html https://www.inkandswitch.com/local-first.html > I wonder how these two cope with one another. To me, you're either not local (must connect to be sure your data have persisted) or you need something more than just browser. Otherwise you're at the mercy of browser vendor not to destroy your in-browser data with borked update. Maybe a clarifying one-liner would be "it's local-first, not local-only" ;) There is totally a tension there from not controlling the browser itself. You're absolutely right that the browser can clear it cache pretty much whenever. In practice, this appears to happen less than advertised (the extra caution is a good default!), but it totally does happen. It's something that we've spend a bunch of time trying to figure out the balance on. We also have to recognize that we live in an online world, so there's a bunch of additional work going into making things feel instant when connected. Fission is pushing on both sides of the problem to basically get as close to "your data everywhere all the time" as possible. The principle is that you should be able to show up to a web app and have it "just work" and not know that anything special is happening. Everything should work if you loose connectivity, or are on a plane (if we ever do that again). You should also be able to self-host your data, or have it cached in multiple places (which is a big advantage of IPFS). Fission provides one way to automatically keep a second encrypted-at-rest copy outside of the browser while you have connectivity. There's nothing special about our IPFS nodes; they're just set up to make that smooth for the kinds of thing that you'd want to do with the SDK, and add some niceties like DNS automation so you're not always fiddling with hashes. Part of us presenting to the SIG was to try to get better access to local desktop IPFS nodes, so that those who want to turn the dial to "fully offline" can go further with that.

ComodoHacker 6y ago
Thank you for clarification. I've made a note to myself to play with Fission when I have time.