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

added GUI 

[Imported from Trac: page GSoCIdeas2010, version 40]
zooko 2009-03-17 05:48:21 +00:00
parent cfe79653e2
commit 451e1ded5c
1 changed files with 12 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
GSoCIdeas2010.md

@ -1,17 +1,22 @@
# Ideas
*What could a smart student do in one summer, if they didn't need to worry about getting a summer job to pay the bills?*
## Improvements to Tahoe
## Server Selection
*Which servers are connected to your client, and which of them have which shares of your files?*
* Dynamically migrate shares to maintain file health.
* Use Zeroconf or similar so nodes can find each other on a local network to enable quick local share migration.
* Deal with unreliable nodes and connections in general, getting away from allmydata's assumption that the grid is a big collection of reliable machines in a colo under a single administrative jurisdiction
* Abstract out the server selection part of Tahoe so that the projects in this category of "grid membership and server selection" can be mostly independent of the rest of Tahoe. See also [this note about standardization of LAFS](http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html#2009-02-06).
* Write a GUI to visualize and manipulate the set of servers connected and the set holding shares of files.
## Networking Improvements
* Dealing with NAT, ideally making it as easy to ignore as possible (taking advantage of upnp-igd and Zeroconf NAT-PMP).
* grid membership and server selection:
* Dynamically migrate shares to maintain file health.
* Use Zeroconf or similar so nodes can find each other on a local network to enable quick local share migration.
* Deal with unreliable nodes and connections in general, getting away from allmydata's assumption that the grid is a big collection of reliable machines in a colo under a single administrative jurisdiction
* Abstract out the server selection part of Tahoe so that the projects in this "grid membership and server selection" can be mostly independent of the rest of Tahoe. See also [this note about standardization of LAFS](http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html#2009-02-06).
* 'tahoe sync'. The proposed #601 bidirectional sync option would be great for using tahoe as we would with dropbox (<http://www.getdropbox.com/>). Like the latter, the user could have a daemon which keeps things in sync in pollings within a one or two seconds schedule (maybe using inotify for uploads). In practical terms an user could have many machines pointing to the same tahoe:dir, each machine mapping this resource to a local directory, and all these machines could then have their local copies in sync, via tahoe:dir. I think this is good when someone has many machines and alternates use between them, like a notebook, a home desktop and an office desktop, for instance.
* Optimize upload/download transfer speed.
* Implement storage server protocol over HTTP.
* Make the [Windows client](http://allmydata.org/trac/tahoe-w32-client) use only free open-source software
## Free The Windows Client
* Make the [Windows client](http://allmydata.org/trac/tahoe-w32-client) use only free open-source software.
## Deep Security Issues
*Want to implement strong security features which advance the state of the art? It isn't easy! To tackle these you'll need to think carefully and to integrate security and usability, which are two halves of the same coin. But you'll have excellent mentors and the support of a wide community of interested security hackers.*