[tahoe-dev] new project

[Nathan]

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