3 ms·
Now that we're talking about IPFS, here's a slightly more complicated question: Suppose a maintainer has a "legacy web" application consisting of two parts: 1)
by jancsika 9y ago
Now that we're talking about IPFS, here's a slightly more complicated question:
Suppose a maintainer has a "legacy web" application consisting of two parts: 1) the app proper with a publicly accessible interface, and 2) regular backups of the app database that also have a publicly accessible interface. Let's assume for the moment that 3rd parties have automated the process of pulling from the backups into well-seeded torrents to prevent data loss.
The app proper functions to add entries to the database.
What does IPFS bring to the table for such a legacy web app as the one I've described?
- lgierth 9y agoYou're not giving me much to work with :) It's all about the data, how you write/read it, and how you structure it. IPFS gives you a networked database for immutable graphs, IPNS for mutable links, and PubSub plus CRDTs for multi-writer scenarios.
- jancsika 9y agoTo be specific-- the legacy web app maintainer has to make sure that a) snapshots of the data are available and backed up, and b) the app proper is available to users who will add entries to the database. For the legacy web, once the maintainer makes the snapshots available they get scooped up and replicated by the general public. So while IPFS' immutable graph might be a design improvement on whatever set of scripts our hypothetical maintainer is using, it's an incremental improvement and not a paradigm shift. For the app proper-- what is the benefit of content-addressability over location-addressability? Let's assume both the identity and location of the maintainer is known. I think I know a vague answer to that, but I'd like to read what a dev has to say about it.