wiki:gsoc

Version 40 (modified by Mathiasdm, 11 years ago) (diff)

Organization application

  1. Link ID?
    i2p
  2. Group name?
    Invisible Internet Project
  3. Home Page URL?
    http://www.i2p2.de/
  4. Public email?
    press@…
  5. Describe your organization.
    The I2P development team is an international group (with both anonymous and known participants) looking to provide anonymity for internet users through an overlay network. To achieve this goal, I2P uses onion routing (an encryption layer is added for each router messages need to pass) for this goal, somewhat similar to Tor. Multiple applications work directly on the network (web browsing, e-mail, IRC, …), while others are available by integrating into the I2P API (eg. Bittorrent, iMule …).
  6. Why is your organization applying to participate in GSoC 2009? What do you hope to gain by participating?
    We wish to attract more developers to the project to increase our development speed. In addition, we wish to gain publicity for I2P to create a larger community (which also improves the anonymity of the users).
  7. Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.
    No.
  8. If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?
    Not applicable.
  9. What license(s) does your project use?
    I2P is a project containing multiple programs. As such, these are licensed under different licenses. All of the licenses are open source and detailed information is available at http://www.i2p2.de/licenses.html
  10. What is the URL for your ideas page?
    The official page can be found at http://trac.i2p2.i2p/wiki/gsoc inside the I2P network. It can also be reached without running I2P from the following links (warning: they may be slow): http://trac.i2p2.i2p.to/wiki/gsoc or http://trac.i2p2.i2p.tin0.de/wiki/gsoc
  11. What is the main public mailing list for your group?
    http://forum.i2p2.de/
  12. What is the main development mailing list or forum for your organization?
    http://zzz.i2p/ (or http://zzz.i2p.to/ for outside of I2P)
  13. Where is the main IRC channel for your group?
    freenode|irc2p|ein: #i2p Not many people are in the Freenode channel, most are on #i2p in irc2p (inside I2P).
  14. Does your organization have an application template you would like to see students use? If so, please provide it now.
    Yes. See below.
  15. Who will be your backup organization administrator? Please include Google Account information.
    echelon
  16. Who will your mentors be? Please include Google Account information.
    • welterde
    • echelon [ echelon@… ]
    • zzz
  17. What criteria did you use to select these individuals as mentors? Please be as specific as possible.
    • Experience with I2P code in general, and with the suggested project proposals in particular.
    • Knowledge of the I2P community.
    • People skills: getting along with others and resolving conflicts. This includes helping new users (which, according to us, indicates a willingness to help GSoC students as well)
  18. What is your plan for dealing with disappearing students?
    Try to contact them via mail(or even phone maybe?)
  19. What is your plan for dealing with disappearing mentors?
    Try to contact them? If necessary, another mentor might take over the work.
  20. What steps will you take to encourage students to interact with your project's community before, during and after the program?
    Communication on IRC and the forum to get to know people, setting up I2P and an I2P website (possibly with help on IRC).
  21. What will you do to ensure that your accepted students stick with the project after GSoC concludes?
    The interaction with the community, as well as interesting new project ideas being available.

Application template

  1. What idea would you like to work on? Please work out a general description. Also include a more detailed explanation, with the project broken down in different parts (if possible, include a timeline).
  2. Tell us about yourself. Who are you, what do you study, other information about yourself.
  3. Why did you choose I2P? What's your motivation, and why this specific idea?
  4. Do you intend to work full time on the project, or do you have other obligations? If possible, give us a timeline.
  5. Are there any additional reasons we should pick you to work on I2P?

Requirements and hints

  • Students are (in most cases) expected to use the Monotone revision control system.
  • Make yourself available: working on the GSoc will be a lot of work, keep this in mind.
  • Be sure to get to know the developers beforehand, since you will be working with them for over 2 months (and hopefully longer, as you can always continue to contribute to the project).
  • Related to the above: communicate often with the developers (specifically: your mentor). Ask questions if you don't understand something, say what your great new idea is and how you are implementing it …
  • Be motivated! If you like the idea you're applying for and would love to code on it, your experience will be much more enjoyable.

Ideas

The following ideas are only a few suggestions by developers and enthousiasts. Other ideas are possible, and even encouraged. I2P is an overlay network, which basically allows any online application to be adapted to I2P. This, as well as the option to develop a new feature for the overlay network, allows a whole range of ideas.

Distributed wiki on I2P (either porting or from scratch)

Websites on I2P are often shortlived, which causes information to get lost. Over the course of the years, there have been multiple wikis on i2p, but only one has been online for a considerable time: ugha.i2p . To remove the risk of losing valuable data, a distributed wiki would be extremely useful. It should be possible to host the wiki both on I2P websites (eepsites) as on regular ones (to allow people without I2P to contribute as well).

Required skills

  • Programming knowledge, both desktop programming and web programming (for a wiki frontend)

Dependencies

  • Distributed data storage on I2P (optional — if such a wiki is built on a distributed data storage system)
  • Distributed version control systems (optional — if such a wiki is built on top of a distributed version control system)

Inspiration

Distributed data storage on I2P

Providing files from an eepsite can be slow (a 20 kBps download can turn into a 2 kBps download or simply stop if too many visitors are interested), the eepsite can go offline for a while, and uploading files may take a lot of resources from the host. To remove these problems, a distributed data storage system could be built on top of I2P. Such a system could, amongst other things, be used to facilitate I2P upgrades inside of the network.

Required skills

  • Java

Notes

  • Inital work has been done on both Dijjer and Yafan.
  • Either Dijjer (which also needs improvements like SHA instead of MD5) or Yafan can be used for a data storage system.

IPv6 support for I2P

Currently I2P only supports IPv4 TCP and UDP. Adding IPv6 support would involve adding a new field in the NTCP/SSU routerInfo entries and possibly adding some restricted route functionality to support communication of IPv4-only peers with IPv6-only peers.

Required skills

  • Java

Notes

  • Some initial work has already been done in the i2p.i2p.ipv6 monotone branch.

Distributed Domain Name System (DNS)

The current DNS system (which goes by the name SusiDNS) is extremely simple. The routing through the network causes extra latency, so a traditional DNS system would not be possible/slow down I2P. This is why the current system uses a textfile on the local computer, containing the destinations of eepsites. Updates are retrieved by getting the textfiles from 'trusted' eepsites. As an alternative, there is a system using base32 hostnames, like in Tor. The idea for this task would be that the DNS system needs to turn into a distributed, easily updatable system.

Required skills

  • Java
  • Understanding of DNS

Revive Kademlia DHT

Peers in I2P currently 'discover' each other through a floodfill system (several high-traffic routers inform the other routers of each other). This system is not as scalable as a DHT system, and it's also less secure (because of the reliance on a limited number of nodes). Changing this system or replacing it, will be an interesting and challenging task.

Required skills

  • Java
  • Good knowledge of networking protocols, network routing …
  • Willingness to learn about different types of Distributed Hash Tables and research how well they would fit into the I2P network

Notes

  • There is already a Kademlia implementation in I2P that used to work, but it was abandoned for a floodfill implementation due to the Kademlia system not working efficiently enough.

I2P seeding for applications (so central reseed locations are no longer required)

A lot of I2P applications use their own reseed implementation (pointing to specific 'reseed nodes' to get information about other nodes using the application). Reseed functionality in the I2P network itself could avoid reinventing the wheel in the future.

Required skills

  • Java

Improving the Message Priority System and looking into QoS

Required skills

  • Java