- From: Nathan Rixham <nathan@webr3.org>
- Date: Mon, 17 May 2021 02:33:15 +0100
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Miles Fidelman <mfidelman@meetinghouse.net>, public-rww <public-rww@w3.org>
- Message-ID: <CANiy74wKPnkbs_KYO+uTmxRE0211PDFiYFd6v5kPvj2jqn-xmQ@mail.gmail.com>
On Sat, May 15, 2021 at 11:46 PM Melvin Carvalho <melvincarvalho@gmail.com> wrote: > On Sat, 15 May 2021 at 22:45, Miles Fidelman <mfidelman@meetinghouse.net> > wrote: > >> Hi Marvin, >> >> Melvin Carvalho wrote: >> >> IPFS files are by nature immutable so write once, but no subsequent >> writes, unless you're writing to a directory structure >> >> It's an interesting approach, but it is still tiny compared to the HTTP >> web, which we should also use as a build target >> >> The question is still, where to put the files if not on a server. There >> are http-IPFS gateways, and various approaches to managing mutability >> (personally, I'm looking at Orbit-db right now). And there are pinning >> services to provide archiving. >> > > Both approaches are fine. I think it doesnt have to be either/or? You > can put files in IPFS or you can put them on an http server, you just have > slightly different ways of finding them. http tends to make it harder to > deploy in a distributed way because http uris are definitive, tho there is > the .well-known trick and things like ni:/// URIs which can sort of offer > hybrid solution. So, yes to both, and there a bit of magical discovery > that would need to be specced out ... > A loosely coupled immutable timestamped record of state changes allows deployment of resources to be broadly tech and protocol agnostic. For example several previous states of a document could be stored on IPFS, with the stateless protocol HTTP providing the most recent state, and a chain exposing timestamped pointers to the previous states. >
Received on Monday, 17 May 2021 01:33:39 UTC