<div dir="ltr"><div dir="ltr">Hi Jean-Paul,<div><br></div><div>thank you for your feedback.</div><div><br></div><div>I agree the browser environment has to be utilized with a great amount of care. </div><div><br></div><div>I tried to follow the proposal of the "<a href="https://tahoe-lafs.readthedocs.io/en/latest/proposed/http-storage-node-protocol.html" target="_blank">Great Black Swamp</a>" as far as my knowledge would allow me to go. I agree the API would make it very simple to interact with a storage node and the security model also makes sense (as far as I understand it), however, it doesn't change the needs for the use case we are trying to cover.</div><div><br></div><div>In our scenario, Bob wants to securely store a file and ensure that only parties Bob trusts and gives expressed permission can retrieve the file. For this, I believe, the file needs to be :</div><div>- encrypted in order to be unreadable by people intercepting the whole file</div><div>- sharded to be unreadable by the storage nodes; and</div><div>- only Bob holds the capability to retrieve the required shards to avoid unwanted access</div><div><br></div><div>(Note: AAA on the storage nodes and secure storage of the capability are addressed elsewhere) </div><div><br></div><div>Therefore, to ensure Bob has full control, his client needs to </div><div>a) hold own the encryption key </div><div>b) manage the sharding; and</div><div>c) create the capability</div><div><br></div><div>Making the storage nodes really that, pure storage nodes.</div><div><br></div><div>It seems to me that the "<a href="https://tahoe-lafs.readthedocs.io/en/latest/proposed/http-storage-node-protocol.html" target="_blank">Great Black Swamp</a>" does allow for this scenario, but it does not address the need for a client that can work in any environment without the need to install additional software, which is the goal of us proposing a browser-based client.</div><div><br></div><div>Regards,</div><div>Mirko</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 3, 2019 at 12:03 AM Jean-Paul Calderone <<a href="mailto:jean-paul%2Btahoe-dev@leastauthority.com">jean-paul+tahoe-dev@leastauthority.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Apr 1, 2019 at 2:41 PM Mirko Lindner <<a href="mailto:mirko.lindner@deviz.io" target="_blank">mirko.lindner@deviz.io</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Tahoe LAFS dev community,<br></div><div><br></div><div>I found Tahoe LAFS and would love to use it as the basis for my company's projects.</div><div><br></div><div>In order to do so, I need a browser-based javascript client that can create, encrypt and erasure-encode text/json files, upload them to storage nodes and create the capabilities locally.</div><div><br></div><div>I was wondering if this or a similar feature is already on the roadmap or if it had been discarded before.</div><div><br></div><div>I do have some budget available and if this is of interest to others as well, I would love for this work to be done in the right way and ensure it will be open sourced once completed.</div></div></blockquote><div><br></div><div>Hi Mirko,</div><div><br></div><div>Here are a couple thoughts off the top of my head - no conclusions here by any means.</div><div><br></div><div>The browser is a dangerous environment. JavaScript itself is fraught but it seems like a lot of danger comes not from what <i>your</i> code does but from all of the other unsavory activity that may be going on in the same environment.</div><div><br></div><div>I have recently been trying to push forward something called "<a href="https://tahoe-lafs.readthedocs.io/en/latest/proposed/http-storage-node-protocol.html" target="_blank">Great Black Swamp</a>" which is an HTTP-based API for interacting with storage servers. Half of the idea here is that it is a lot easier to implement an HTTP-based API (particularly in other languages) than it is to implement the current Foolscap-based API. This isn't specifically about supporting browsers but I would imagine a JavaScript client should be able to deal with an HTTP-based storage server API fairly easily.</div><div><br></div><div>Jean-Paul</div><div><br></div></div></div>_______________________________________________<br>tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org" target="_blank">tahoe-dev@tahoe-lafs.org</a><br>
<a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" rel="noreferrer" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
</blockquote></div></div>