I have probably not done a very good job presenting a description of how the new hub-distributed libraries are supposed to work.
First of all, you would almost never want to use the "Download URL" option. Instead, you want to upload a zip package to the hub and let Dream Seeker handle the installation. Here's why: a package distributed directly through the hub can be included as a dependency in another hub distribution.
For example, the maze demo that I posted contains a file called include.txt, which has a single entry: Dan.maze. When Dream Seeker installs Dan.MazeDemo, it automatically checks to see if the library Dan.maze is installed and installs it if necessary. That is better than including the library verbatim in every project that uses it, because if the library gets updated, you don't have to re-upload all of the other projects that make use of it. That's especially important if some of the projects that depend on the library were written by other people.
Another thing I may have failed to mention previously is that the installation location of all libraries is now determined by their path in the hub. The library Dantom.CGI goes in lib/Dantom/CGI and must therefore be included as include<Dantom/CGI> rather than the old method which was include<html/CGI.dm>.
This scheme prevents filename conflicts between different library writers. When you supply a zip package to the hub, Dream Seeker automatically installs it in the correct location, so that is another reason to use that method of distribution.
Finally, I did not intend for the "long description" to be a full description of the library interface. It should list the functionality so that someone who is looking for a library can tell if it has the desired features.
For describing the interface, there are a number of options. You could do it in readme.html (or readme.txt). The advantage of doing that is that when the library gets installed by Dream Seeker (even if it is just a dependency of another project), the user will be presented with the option of viewing the readme file. That would be an appropriate place to stick copyright and licensing information.
You could also include the documentation in a separate file and just link to it from the readme file. For example, a library with a big revision history could publish recent changes in the readme and the full docs in a separate file.
We will also soon be adding the ability to add on to the built-in compiler language reference so that your library's own procedures and objects can be found there along with the core DM definitions.