[tahoe-dev] new project

[Nathan]

Just a follow up:

Perhaps one of the "smoothest" user experiences for that particular
use case is to have a tahoe-lafs gateway embedded in the browser as a
plugin or extension.  The html payload I send Alice, when opened, will
say "You need the Tahoe-LAFS plugin/extension/add-on to view this
page".

This solves hurdle 1, where we both need LAFS installed, even when
Alice does not already have it (which would help a lot with adoption).

Hurdle 2 would also be solved, because we'd replace the
local-system-dependent part of URLs with a global identifier.

Hurdle 3 could be solved if all such gateways were on the same grid.

Furthermore, the same-origin issue *may* be addressable by an extension.


I recall that Warner was prototyping a kind of "Tahoe next gen" which
started from the browser UI and worked from there backwards toward the
platform level.  Warner, does this use case fit with your
prototype/vision at all?


Nathan


On Sat, Aug 18, 2012 at 3:24 PM, Nathan <nejucomo at gmail.com> wrote:
> Hi Miles,
>
>
> On Mon, Aug 13, 2012 at 11:03 AM, Miles Fidelman
> <mfidelman at meetinghouse.net> wrote:
>> Hi Folks,
>>
>> I'm building a new tool that might end up running on top of tahoe-lafs,  so
>> I figure I might as well let folks know about it, and maybe drum up some
>> support.
>>
>> Core idea is "smart documents that talk to each other via a peer-to-peer
>> protocol."
>> - start by writing and sending an HTML email to a group of people (say
>> everyone involved in working a trouble ticket)
>> - on receipt, the copies establish a peer-to-peer connection - updates to
>> one copy propagate to every other copy
>>
>> Synchronized copies of documents, rather than sharing one copy via Google
>> Docs.  Sort of like Git, but for things like action items, trouble tickets,
>> work plans, reference documents, rather than software - with all the code
>> pushed into JavaScript libraries embedded into the documents themselves.
>> (Maybe more like Fossil's embedded wiki - pushed into the browser).
>>
>> I'm looking at Atom as the serialization format, and thinking about using
>> tahoe-lafs files as a distributed publish-subscribe mechanism for pushing
>> Atom around (I seem to recall others posting about using tahoe-lafs in a
>> similar way - and would be interested in hearing if anybody has moved
>> forward along these lines!).
>>
>> If you're interested, take a look at:
>> http://www.kickstarter.com/projects/1947703258/smart-notebooks-keeping-on-the-same-page-across-th
>>
>> Comments, support, likes, tweets, +1s, reposts, blog postings, ... welcomed!
>>
>
> Please add my: support, like, and +1
>
> I'm very interested in building something like this on top of
> Tahoe-LAFS.  I don't have a lot of bandwidth right now, but I will
> certainly play with any examples, help improve documentation, test,
> and perhaps patch.  I've wanted this kind of thing for a while, but I
> haven't invested the time to bring my UI-in-browser skills up to the
> necessary level.
>
> Of course a Tahoe-LAFS-centric approach could be to use capabilities
> as both a document storage system *and* a peer-to-peer message channel
> for this kind of application.
>
> This appeals to me in many ways.  However, a major hurdle is getting
> users to install Tahoe just for this purpose.
>
> What is the ultimate super perfect use case?  I think it would be
> something like: I have a calendar / task list / map / mini blog
> thingy, and I want to share it with Alice.  I email her a single html
> file.  She opens it in her modern browser.  It magically uses new
> fangled browser apis to store her copy and some connection info to my
> instance of the calendartasklistmapminiblogthingy, both of which are
> as securely confidential and authenticated to me as the original
> email.
>
> Now I see her updates, she sees mine, and we have revision history,
> notes, etc...
>
> Where are the major hurdles?  I'm less interested in the "email is
> insecure hurdle".  I like to assume sending email is somehow already
> authenticated and confidential, and focus on maintaining those
> properties with the rest of the system.  (Someone else can and should
> please fix the email authn/confidentiality for us!  ;-)
>
> Ok, so now how can our browsers possibly interact with what new-fangled apis?
>
> If all of these difficult hurdles were overcome, this is one path that
> could work:  Alice and I both:
> 1. Have Tahoe-LAFS installed.
> 2. Have the same way to refer to "the local Tahoe-LAFS installation"
> in the browser (for example if it was always at localhost:3456 then
> urls could use that, but this is failure prone).
> 3. Have Tahoe-LAFS connected to the same grid.
>
> -then-
>
> The html file could include a LAFS read cap to my "publication
> channel", a write cap to a single use "invitation complete" cap, and
> read caps to my latest revision of the documents.  Alice loads the
> html/js, it uses cross domain requests to the Tahoe-LAFS webapi (not
> yet existent in lafs, not hard with modern tech, but safely sandboxing
> js is hard).
>
> Alice's agent creates her own publication channel, then sends the read
> cap of that over the one time invitation complete cap my agent
> included in the html file.
>
> The UI presented by the webpage then shows the document and the fact
> that we are connected.  We can send revisions, messages, etc... over
> our channels.  A single publication channel could be shared with many
> readers for group projects.
>
>
> In addition to the three assumptions about Tahoe-LAFS, there's the JS
> sandboxing and cross-origin API.  Now, can we address any of those
> concerns?
>
> If you think those hurdles are surmountable in the near to medium
> future, then one strategy is to start developing the actual js
> application now and we can pursue the hurdles independently, using
> feedback from the "application" project and the "platform project" to
> help drive the roadmap of each.
>
> If you'd like to start developing the application, I can help out with
> hooking it up to Tahoe-LAFS, and then advocating for changes to
> Tahoe-LAFS that would help this use case.
>
>
>> Miles Fidelman
>>
>
>
> Nathan
>
>
>
>> --
>> In theory, there is no difference between theory and practice.
>> In practice, there is.   .... Yogi Berra
>>
>> _______________________________________________
>> tahoe-dev mailing list
>> tahoe-dev at tahoe-lafs.org
>> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev