usage for git-p2p (was: git pack/unpack over bittorrent - works!)

On Sat, Sep 4, 2010 at 2:52 AM, Artur Skawina [off-list ref] wrote:

Hmm, taking a few steps back, what is the expected usage of git-p2p?
Note it's a bit of a trick question; what i'm really asking is what _else_,
other than pulling/tracking Linus' kernel tree will/can be done with it?

 i'm _so_ glad you asked :)  please note - for all of these i'm keenly
aware that GPG signing is required (and nicolas has pointed out that
you only need a 20-byte hash to be securely transferred by some OOB
mechanism)

 * distribution of large mailing lists and reduction of load on SMTP
servers by adding in a firebreak layer where the SMTP data goes into a
git repository first, then is extracted on the other side.  users may
choose to download the mailing list using git over a peer-to-peer
network and then use the exact same software that the mailing list
server is running, thus reducing the load on the web front-end.  if
you then choose also to allow users to GPG-sign commits to the same
git repository, you have the possibility of reducing the load on the
SMTP servers *as well*.  _and_ a group of users can operate in
"offline" mode whilst still being able to collaborate (by sharing the
git repo between themselves on an isolated LAN) _and_ when one of them
goes back "online", all their commits sync up, and the rest of the
world becomes aware of that group's offline discussion.

 * distributed wikis.  there are lots of wikis now using git: ikiwiki
is one, and moinmoin can also be configured to use git.  so, wikis
have already solved the "conflict" problem, in particular i know that
joey is a smart bunny and has solved conflict resolution in ikiwiki.
that makes it possible to simply turn an "ordinary" wiki into a
"peer-to-peer" wiki by merely inserting git-p2p underneath.

 * distributed bugtrackers.  the one that i know of which i believe
would work straight away is the ikiwiki "bug" plugin.  the rest i need
to investigate: i know of at least one that's based on git that i
haven't looked at for a loong while (ditrack) - but the principle is
very straightforward: create bugs by UUID, commit, distribute.  if you
want a "central" numbering scheme then all that's needed is for a
"central" service to allocate a "central" number - a symlink to the
UUID would do - and you're done.

 * of course there's source management for other projects other than
linux-2.6 :)

there's plenty more ideas out there, but the primary ones i'm
interested in are the ones where "traditional" software development
tools are being used which are utterly dependent on the client-server
paradigm.  for reasons i won't explain as it's not relevant to this
technical discussion list, this is making me feel a bit twitchy [free
software development being dependent on the client-server paradigm,
that is].

l.