GnuForgeInitialDiscussion

==== Questions to answer

====

• Why embed in a P2P framework? Is that really a good idea?

• How do you push data in a P2P framework?

• • I also want to look into how messages got transferred between BBS' in those networks (FidoNet, etc).

• • Here's a novel idea, email. If you could send a signed email automatically to a host, it would be an indication of something new being available.

• • • There are lots of issues with this, the main one being how to you manage a list of everyone. And if you have the list, how do you distribute a message in a distributed manner and assure that everyone on the list has been reached?

• • • • This is basically a routing algorithm though, and I can see ways of dealing with the problem. There is really not a need to have a list if each host has a notion of a few neighbors. When it gets a message from one of them, it can forward it out to the others. If a message is recived twice, just let it drop so you won't create inginite loops. This is part of the point of P2P networks: you only need to know who your neighbors are in order to talk to everyone.

• • • • • This brings up the issue of how do you find neighbors. I think the first step in that process is finding a physical person that can varify your pgp sig, then just adding them to the verifier's list. There should probably be some sort of heuristic for getting a few other neighbors for the new guy to. There are many issues at with this....

• • • • • The other problem to this routing idea is that you need to find a way to prevent bottlenecks. Bottlenecks slow things down and make partitioning the network easier.

• • • • • • Bottlenecks to what? Getting messages to everyone?? As in you get sub-networks of hosts connected together by a single host?? Explain.

• • • • • • A solution to that would be to use an aging neighbor idea where you never keep a neighbor for too long. When one gets old, send out a request for a new neighbor, then hook up with a new node. I am babbling a lot, but I think the problems are definitely solvable.

• How about fixed nodes you sync with?

• • What I am thinking is that each node registers with N other nodes (say, N=3). Every so often a sync is done with the nodes you have registered with. If you have a small world network, data should propagate across the whole system quickly.

• • • I think you are re-inventing the wheel. Do research on network types and cellularization of the system.

• What is the best way to deal with the distributed namespace (user names, project names, etc)?

• • Example: "pet names" (ICQ basically uses this idea)

• • • I don't think this would work. The difference between ICQ and GnuForge is that ICQ is where you go to communicate with pre-existing parties. It is not really a place to meet new people. Sourceforge is a place where you want to get to know different peoples names, who the developers are, etc.

• • Naming should probably be done on an email like basis, then it would be very rare for there to be conflicts. email adresses are unique to people, and possibly project could have a standard of admin@project-domain. This assumes a project has a domain though, which is not cool. Sollutions for this?

• • • I don't like the idea of identity being tied to mail host. You should be identifiable by your handle. Don't you think? Or is this an unreasonable wish since we are dealing with a huge number of people. I just wouldn't want to be identified with a hotmail or yahoo account, which some people may use.

• • • email is completely unique though, and it basically is a no brainer solution to the problem. We would be relying on some other person to create a unique name for themselves. If they care about having a cool name, they can get their own domain.

• • • • The last issue with that is that we must be sure that the person with that address is who they say they are in the future. PGP signatures baby. I presume there are already facilities to manage that.

==== Research to do

====

• What would the optimal cellular structure be like? Centralized versus p2p.

• • Seems that the projects should be hosted on individual machines, and all aspects of the community should be p2p. Think of it as a real social network: individuals deal with there own crap, but the interconnection is something everyone shares.

• What sort of network structures would be good for keeping data synced between nodes?

• • The trick is that web pages are going to be dynamically located. If you go to a project page, then they should have links to community pages. The links on the project page should be determined by how stable a community host has been, and ditributed as a p2p list that is pasted around every so often.

• • • What do you mean by "community pages"? A core set of pages should be available on all nodes. Projects themselves have particular nodes they reside on . But even that may be non-obvious if the node you use to find info on a project is peering project info (in which case project links will point to your current node).

• • • • It seems like there are two general realms of data:

• • • • • Project data: code, mailing lists, website, etc. It seems like that data should be kept in one place, and managed by the group (or machine host).

• • • • • • Data like this should also be available via a peering system, if the project manager chooses to. I'm think you have something like DeCSS as a project. Files are stored locally as well as on FreeNET. All GnuForge nodes have a FreeNET <-> Web interface, so it's all transparent; on disk or on FreeNET, same thing. If the DeCSS projects has to get pulled from its permanent node, no biggie, files are distributed and on FreeNET. They have to tell every GnuForge node to stop linking to it (and it is unclear as to whether you can legally tell a site not to link: see the 2600 DeCSS case) and even after that, it's still around.

• • • • • • • It would be interesting to build a FreeNET/CVS tool. ':)'

• • • • • • • • CVS has the funcamental flaw that it believes there is one repository. I think it would be more interesting to create a new version control system that would automatically detect conflicts, resolve, them, then distribute them.

• • • • • • • Does a freeNet web system exist? I was under the impression that none of the files were accessable unless you knew their encrypted name. Is encrypting the name an option?

• • • • • Community data: cross references between projects, developer profiles, help wanted, new release notices, etc. This data should be hosted in a distributed manner. That includes managing the databases, hosting community webpages, and creating groups of software.

• • this might involve the link from the project page pinging a few web servers from the list before responding to the web viewers request for a community page.

---

Last edit: Sun, 23 Jul 2006 04:22:24 -0700
(IstoYlisirkka)
Revisions: 4