Publishing in iCity

I was giving thought to publishing content in iCity (formally now called nInformationCity).  Specifically, I'm trying to work up a particular use case for this.  The ones I've come by at this point are:

Use a WPF app to select files on your system for publishing.  You can then associate them with a particular community, select a package name (something to identify the files by), and select publish.  The system would then mark them as owned by you and assign it a version id (1 for a new package), and mark it as published.  Additionally, you can assign a taxonomy to the package to facilitate searching and location, as well as various other metadata fields such as a description.

What this allows is then for other users of iCity to query your system for packages.  Upon receipt of a query for packages, the system would return to the peer a summary of packages, and a further request could retrieve detail of any or all of the packages.  From that, a peer can request a transfer of a package which would be accomplished by using nDistribute.  This would then spin up a bittorrent tracker on your system (or on a dedicated tracker system) other clients can connect to in order to
transfer the content.

Even more interestingly, other peers can request a subscription to a package.  Upon changes to the package by yourself, iCity would inform peers in that community of new packages being deployed.  Or, upon subscribing to the community, all others in the community could be automatically pushed update messages to any packages published to the community.

The concept also becomes important for versioning and notification of new content.  If the "owner" of some data changes that content, others that already have the data must be able to be able to know if they do not have the most recent version, and when publishing data versions can be incremented, others notified, and content distributed.  Also, it can be used to hosting multiple versions of related data in the network if that is so desired.

I also think that it is probably important to be able to identify in the system a new package id for each version, as well as an id / version tree as if multiple people make changes to a single package, it would be good to be able to identify the history of changes for reconciliation.