[darcs-users] Re: peer to peer darcs

S. Alexander Jacobson alex at alexjacobson.com
Thu Aug 5 17:34:50 UTC 2004


On Tue, 3 Aug 2004, Eric S. Johansson wrote:
> like I said: works for small number of users.  Personally I think that
> another one of my ideas from the tool bag would actually apply better
> than a strict listserver/mailing list.  If you are acquainted with how
> Usenet operates, imagine scaling that really far down to the individual
> PC.  In other words each user on the list would have a list of users to
> send e-mail to, the ability to detect and filter out duplicate messages,
> and the ability to operate on commands (e.g. users add/drop) from the
> list mom.
>
> this would allow the world to build mailing lists without requiring any
> central infrastructure and in fact have the ability to survive cratering
> of big chunks of the net.

That was the assumption behind my original
proposal for p2p darcs.  I figured that every
change would be broadcast to everyone in the
distribution list file that would be part of the
repos.

I actually assumed that the repos also contained a
list of who could send modifications to the dlist
so patches that included modifications to the
dlist from people without permission to do so
would be refused.

But the first step was to figure out what darcs
itself was capable of doing.

If you want to scale up so that every user doesn't
have to mail every other user every change, you
would switch the dlist to a network describing who
mails to whom and who relays for whom and you need
the ability to reject duplicates.

Verifying delivery in the whole network is O(n^3)
but I think there are ways to reduce it in the
case of e.g. explicitly small world networks....

> I also have other ideas for doing the same thing to caching and
> distributing load.  too many ideas, not enough life.

I don't know that you need caching and distributed
loading...  You just need a probability measure
that any node will be up enough to relay.  You
then use bayesian network algorithms to guarantee
that the probability that a patch will not reach a
given user is less than p.

I've been thinking about this project for a long
time.  The problem has always been the lack of a
serializable patch framework (unison is not
serializable).  darcs looks like it might provide
the infrastructure to make it a reality. YAY.

> the back to the notification process, I personally prefer a very
> lightweight notification mechanism either the form of very small mail
> messages or instant messenger tickler.  then once notified, the user can
> go to the actual repository to figure out WTF.

I don't understand this one.  If you receive the
whole patchset via email and you use POP or IMAP,
then you can use the retrieve-headers-only
functionality of both of those protocols to decide
whether or not you want to download that patch.

Or, if you autoamtically update a repos on some
server and that repos is also accessible via HTTP
than you can do If-Modified-Since polling....

Can you give a use case that is not covered by
either of these models?

-Alex-


______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com




More information about the darcs-users mailing list