wiki:gsoc/ideas

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

--

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). We welcome your input on IRC (Freenode, #i2p, or irc2p (inside I2P), #i2p) and the forums ( forum.i2p2.de ).
  • Get to know I2P: install I2P, setup an I2P website (eepsite), try running IRC on top of I2P, ...
  • 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