From 8bc828574d4f167c127ba261f5cc7e621a03d38c Mon Sep 17 00:00:00 2001 From: zooko <> Date: Thu, 15 Nov 2012 18:21:13 +0000 Subject: [PATCH] archive today's agenda, post next week's [Imported from Trac: page WeeklyMeeting, version 29] --- WeeklyMeeting.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/WeeklyMeeting.md b/WeeklyMeeting.md index 8518d71..b2b5e2b 100644 --- a/WeeklyMeeting.md +++ b/WeeklyMeeting.md @@ -23,30 +23,30 @@ There is a weekly conference call using [Google Hangout](https://www.google.com/ ## Agenda -URL: +URL: -Upcoming: 2012-11-15 +Upcoming: 2012-11-22 This will be a *TESLA COILS AND CORPSES* meeting: science, big new features, writing papers about our work, etc. If you're more into *NUTS AND BOLTS* then stay tuned for a future meeting about engineering, debugging, making stable releases, etc. -Agenda: async notifications - -What a *lot* of people really want is an alternative to Dropbox — something that functions very like Dropbox but without exposing your plaintext to spying and corruption. David-Sarah implemented a part of this with the drop-upload feature. It seems to me that the blocker which prevents Tahoe-LAFS from doing the rest of it is that LAFS clients have no way to get an asynchronous notification that a file has changed (i.e., so that they don't have to poll to find out if the file has changed). So: could we add that? Why not just define a remote interface offered by LAFS clients to LAFS servers. The remove interface is "hey_you_this_file_has_changed(storageindex)". - -Another approach would be to embrace a standard mechanism like PubSubHubBub. That might help with our long-term goal of moving from foolscap to HTTP, and it might let us benefit from the work others do on issues around this such as DoS and scalability. +Agenda: Proof-of-Retrievability ## Proposed Future Topics * **Tahoe-LAFS v1.10** What can we do to move Tahoe-LAFS v1.10 along? Is David-Sarah too busy with LeastAuthority.com to be Release Manager for Tahoe-LAFS v1.10? Should Tahoe-LAFS v1.10 contain only patches that are already on trunk? -* **Proof-of-Retrievability** review of a paper draft Zooko will distribute. (was scheduled: ~~2012-10-30~~) - * **Rainhill design review** which David-Sarah will distribute; call for outside crypto expert reviewers. (was scheduled: ~~2012-11-06~~) ## Notes / Archives +### 2012-11-15 + +* async notifications + +What a *lot* of people really want is an alternative to Dropbox — something that functions very like Dropbox but without exposing your plaintext to spying and corruption. David-Sarah implemented a part of this with the drop-upload feature. It seems to me that the blocker which prevents Tahoe-LAFS from doing the rest of it is that LAFS clients have no way to get an asynchronous notification that a file has changed (i.e., so that they don't have to poll to find out if the file has changed). So: could we add that? Why not just define a remote interface offered by LAFS clients to LAFS servers. The remove interface is "hey_you_this_file_has_changed(storageindex)". + ### 2012-11-08 * #1240; Is it done? (I think it still needs fixed tests.) Can we commit it to trunk and be done with it? Do we need to merge it with #1679?