diff --git a/GSoCIdeas/Notes.md b/GSoCIdeas/Notes.md
index 1b7448d..e432d48 100644
--- a/GSoCIdeas/Notes.md
+++ b/GSoCIdeas/Notes.md
@@ -16,44 +16,7 @@ Here are notes that should be added to wikiGSoCIdeas in a format emulating [this
 
 ## 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. ===
 
-Difficulty: medium - hard
-
-When uploading a file to a grid, Tahoe-LAFS will make sure that the file is
-healthy (a good discussion of what healthy means is found in #778) before
-reporting that the file is uploaded successfully. Tools to effectively 
-maintain file health (or to adapt to new definitions of health) aren't
-quite complete, however -- our users have had several use cases that aren't
-easily addressed with what we have. Students taking this project would be
-building tools to address those use cases.
-
-A good starting point would be to become familiar with how files are placed on
-a grid. [architecture.txt](http://allmydata.org/trac/tahoe-lafs/browser/docs/architecture.txt),
-[file-encoding.txt](http://allmydata.org/trac/tahoe-lafs/browser/docs/specifications/file-encoding.txt),
-[mutable.txt](http://allmydata.org/trac/tahoe-lafs/browser/docs/specifications/mutable.txt),
-[the immutable file upload code](http://allmydata.org/trac/tahoe-lafs/browser/src/allmydata/immutable/upload.py), and
-[the mutable file upload code](http://allmydata.org/trac/tahoe-lafs/browser/src/allmydata/mutable/publish.py) are good
-places to do that.  Also, you might want to look at the
-[storage server code](http://allmydata.org/trac/tahoe-lafs/browser/src/allmydata/storage/server.py) to understand that
-better. Some good tickets to start looking at are #699, #543, and #232; you'll
-find that those link to other tickets.
-
-There are many ways to help address these issues. Some ideas:
-
-  * Alter the CLI and the WUI to give users the ability to rebalance
-    files that they've uploaded already. (#699)
-  * Build tools that allow node administrators to moves shares around
-    a grid (#543, #864) 
-  * Alter Tahoe-LAFS to rebalance mutable files when uploading a new version
-    of them. (#232)
-
-(it is doubtful that any one of these projects is enough to fill a summer, but, combined, they would be a big usability improvement for Tahoe-LAFS)
-
-Depending on how you address this, this is tightly integrated with ideas of
-file health and accounting, so prospective students would do well to explore
-those open issues, too. A good accounting jumping-off point is #666. A good
-jumping-off point for health is #778.
  * 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.com's assumption that the grid is a big collection of reliable machines in a colo under a single administrative jurisdiction. [Tickets labelled 'availability'](http://allmydata.org/trac/tahoe-lafs/query?status=!closed&order=priority&keywords=~availability)
  * Abstract out the server selection part of Tahoe-LAFS so that the projects in this category of "grid membership and server selection" can be mostly independent of the rest of Tahoe-LAFS.  See also [this note about standardization of LAFS](http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html#2009-02-06).