3 ms·

I have no idea what they are planing but my simple approach to the problem would be, to let browsers offer an API to store their users data in the cloud. That

by JepZ 9y ago

I have no idea what they are planing but my simple approach to the problem would be, to let browsers offer an API to store their users data in the cloud. That might sound a little abstract, so I will give an example: A year ago I built an PWA which had the ability to use a WebDAV server as a backend to store data and sync multiple clients. While some might argue that WebDAV is not the perfect protocol, most of its disadvantages can be worked around. The real issue is that the user has to enter his credentials to every app which wants to store some data for him. In my opinion, that is something browsers could make a lot easier and just let the user grant/refuse access to the 'cloud-storage'. That cloud storage would need a standardized protocol (e.g. WebDAV) to manage its access, but that way browsers could offer web apps a large storage and the user could select its own storage provider (in the browser settings). Most users would probably stay with Google Drive or Dropbox, but at least their data would not be stuck in the walled gardens of the various web app providers and some might even choose to store their data in a Nextcloud (at least that is what I do with my PWA).

fabrice_d 9y ago
This would have been possible with foreign fetch in Service Workers, but guess what... Google didn't like the idea.
- JepZ 9y ago
  Thanks for the hint. If someone else wonders why foreign fetch was canceled, this seems to be the relevant issue: https://github.com/w3c/ServiceWorker/issues/1188 https://github.com/w3c/ServiceWorker/issues/1188
djsumdog 9y ago
Really what we need is first-class IPFS support in Firefox/Chromium. Img tags should have an href and an ipfs option. The browser can than chose to pull from either source, depending on user preferences or which one is faster. Users can be prompted if they want to store/serve that data in their own ipfs cache. I think the FF59 plans for IPFS just make it easier to interface with your existing IPFS server (if it's running). Making it first class would be a game changer, but don't expect to see it in Chromium or Webkit any time soon.
- JepZ 9y ago
  Could you please elaborate on how IPFS would solve the problem? As far as I understand IPFS it is just like a public cloud. So either you run your own node (which would be similar to running your own server in terms of owning your data) or you upload to the network in which case you would not care on which server the data would live (similar to uploading an ?encrypted? file to Dropbox?). The real difference is how files are served as soon as you request one. So what I don't understand is how it would make app developers give you the control over your data? Regarding your img-tag remarks: what should href and ipfs attributes do? I mean href is an attribute used for linking, not for loading data like the src attribute and adding attributes for different protocols isn't a good idea either as for that use case we have URLs. So whats wrong with? <img src="ipfs://example.com/cat.jpg"> I never used IPFS so I might completely miss the point as I just read about it and saw a few videos, so please tell me if I misunderstood something.
  - djsumdog 9y ago
    I was thinking more of the lines of the first steps towards distributed assets. Maybe something like <img src="images/cat.jpg" some-new-attr="ipfs://mdgpreefl215jfeiwef2456/cat.jpg"> Or maybe `some-new-attr` could be a 2nd src? In any case, it's only to deal with asset distribution. One of the challenges with something like YouTube is simply the infrastructure to host all that content, as well as content/videos disappearing when YouTube decides they don't want to host it. With IPFS, you could reduce the server load on the content creator and also give the asset permanency if it's popular enough to be seen/rehosted by others. The img tag example isn't that great of an example I'll admit. But it could eventually be extended to permanence of the entire page/site. Although there are already better tools suited for that, like ZeroNet.
deleted 9y ago
[deleted]

by JepZ 9y ago

fabrice_d 9y ago

This would have been possible with foreign fetch in Service Workers, but guess what... Google didn't like the idea.

JepZ 9y ago
Thanks for the hint. If someone else wonders why foreign fetch was canceled, this seems to be the relevant issue: https://github.com/w3c/ServiceWorker/issues/1188 https://github.com/w3c/ServiceWorker/issues/1188

djsumdog 9y ago

Really what we need is first-class IPFS support in Firefox/Chromium. Img tags should have an href and an ipfs option. The browser can than chose to pull from either source, depending on user preferences or which one is faster. Users can be prompted if they want to store/serve that data in their own ipfs cache. I think the FF59 plans for IPFS just make it easier to interface with your existing IPFS server (if it's running). Making it first class would be a game changer, but don't expect to see it in Chromium or Webkit any time soon.

JepZ 9y ago
Could you please elaborate on how IPFS would solve the problem? As far as I understand IPFS it is just like a public cloud. So either you run your own node (which would be similar to running your own server in terms of owning your data) or you upload to the network in which case you would not care on which server the data would live (similar to uploading an ?encrypted? file to Dropbox?). The real difference is how files are served as soon as you request one. So what I don't understand is how it would make app developers give you the control over your data? Regarding your img-tag remarks: what should href and ipfs attributes do? I mean href is an attribute used for linking, not for loading data like the src attribute and adding attributes for different protocols isn't a good idea either as for that use case we have URLs. So whats wrong with? <img src="ipfs://example.com/cat.jpg"> I never used IPFS so I might completely miss the point as I just read about it and saw a few videos, so please tell me if I misunderstood something.
- djsumdog 9y ago
  I was thinking more of the lines of the first steps towards distributed assets. Maybe something like <img src="images/cat.jpg" some-new-attr="ipfs://mdgpreefl215jfeiwef2456/cat.jpg"> Or maybe `some-new-attr` could be a 2nd src? In any case, it's only to deal with asset distribution. One of the challenges with something like YouTube is simply the infrastructure to host all that content, as well as content/videos disappearing when YouTube decides they don't want to host it. With IPFS, you could reduce the server load on the content creator and also give the asset permanency if it's popular enough to be seen/rehosted by others. The img tag example isn't that great of an example I'll admit. But it could eventually be extended to permanence of the entire page/site. Although there are already better tools suited for that, like ZeroNet.

deleted 9y ago

[deleted]