tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

archive today's agenda, post next week's 

[Imported from Trac: page WeeklyMeeting, version 29]
zooko 2012-11-15 18:21:13 +00:00
parent e8e19ca720
commit 8bc828574d
1 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
WeeklyMeeting.md

@ -23,30 +23,30 @@ There is a weekly conference call using [Google Hangout](https://www.google.com/
## Agenda
URL: <https://plus.google.com/hangouts/_/748b6f70b1845e6bbede00fd399a7ce7f8ef3a7f>
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?