wiki:gsoc/ideas

Version 14 (modified by zzz, 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).
Difficulty: medium(depends on, which way you go)

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


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.
Difficulty: easy-medium

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.
Difficulty: medium

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.
Difficulty: difficult

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.
Difficulty: easy-medium

Required skills

  • Java

A website-uptime site

Currently most sites, which show the uptime of sites use HTTP->HEAD for checking if an site is up. I2Ping would allow to check non-http sites as well.
Difficulty: very easy(probably too easy)

Required skills

  • Java
  • JSP/Servlet/... maybe?

Inspiration


Implement I2NP level ping

Currently only the streaming lib provides the possibilty to ping a site if it is up. This won't work for non-streaming-lib dests obviously, so the goal would be to provide ping for those as well.
Difficulty: easy


Improve i2psnark UI

Currently the webui of i2psnark consists of only a single page, where all the torrents are listed. This should be improved somewhat.
Difficulty: very easy


implement i2psnark multitracker support

I2PSnark only supports torrent files with a single tracker url right now. And cannot create any with more than one as well. Difficulty: very easy


Improving the Message Priority System and looking into QoS

Required skills

  • Java

Finish uPnP Support

uPnP support is implemented but not merged into the main branch yet. There is no configuration in the UI yet. The uPnP status needs to be put on the configuration page. The IP address discovered from uPnP is not used by the router.
Difficulty: medium-hard

Required skills

  • Java

Port I2P to Android

Android support has been started but not merged into the main branch yet. Several memory hogs need to be tweaked or significantly modified to fit the router in the Android heap limit of 16MB. Dozens of places in the code use new File, new FileInputStream?, or new FileOutputStream?, these must be modified to meet the Android private file location requirement. Socket open calls must be modified. A new GUI must be designed from scratch, or the existing routerconsole must be completely reworked.
Difficulty: hard-very hard-impossible

Required skills

  • Java

Separate Code and Data for Easy Packaging

The java libs and the router data files are all in the same place, violating requirements for most Linux packages. Handle data files in the user's directory, or in a central location separate from the libraries. This affects the wrapper, the router, and all apps. Decide how to auto-update, and if the central code location is not writable, write to a separate user directory for the code. Must be compatible with the existing everything-in-one-place system.
Difficulty: medium-hard

Required skills

  • Java

Other Ideas and Further Information

See zzz's Todo lists http://zzz.i2p.to/forums/3