wiki:gsoc

Version 23 (modified by anonymous, 10 years ago) (diff)

Organization application

  1. 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 that uses onion routing, and specially modified applications on top of this network.
  2. 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 and grow our community.
  3. Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.
    No.
  4. If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?
    Not applicable.
  5. 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
  6. 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
  7. What is the main development mailing list or forum for your organization?
    http://forum.i2p2.de (inside I2P, forum.i2p links to the same server)
  8. What is the main IRC channel for your organization?
    #i2p on Freenode. Not many people are in the channel, most are on #i2p inside I2P. This anonymous IRC channel is connected to the Freenode channel through a changate (the bot goes under the name 'vulpine').
  9. Does your organization have an application template you would like to see students use? If so, please provide it now.
    No.
  10. Who will be your backup organization administrator? Please include Google Account information.
    echelon
  11. Who will your mentors be? Please include Google Account information.
    • welterde
    • echelon [ echelon@… ]
    • zzz
  12. 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)
  13. What is your plan for dealing with disappearing students?
    Try to contact them via mail(or even phone maybe?)
  14. What is your plan for dealing with disappearing mentors?
    Try to contact them? If necessary, another mentor might take over the work.
  15. 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).
  16. 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.

Mentor application

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 wiki's 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 go slow, 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 (also needs improvements like SHA instead of MD5) or Yafan can be used for a data storage system

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

Required skills

  • Java

Further development of streamr

Required skills

  • Java

Improving the Message Priority System and looking into QoS

Required skills

  • Java

IPv6 support for I2P

Required skills

  • Java

Notes

  • some inital work has already been done

Distributed Domain Name System (DNS)

The current DNS system 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

Notes

  • A replacement for the SusiDNS system.

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.