Changes between Version 6 and Version 7 of gsoc/ideas


Ignore:
Timestamp:
Mar 11, 2009 2:40:30 PM (11 years ago)
Author:
anonymous
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • gsoc/ideas

    v6 v7  
    2121
    2222== Distributed wiki on I2P (either porting or from scratch) ==
    23 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).
     23Websites 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).[[BR]]
    2424'''Difficulty:''' medium(depends on, which way you go)
    2525=== Required skills ===
     
    3434
    3535== Distributed data storage on I2P ==
    36 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.
     36Providing 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.[[BR]]
    3737'''Difficulty:''' difficult
    3838=== Required skills ===
     
    4545
    4646== IPv6 support for I2P ==
    47 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.
     47Currently 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.[[BR]]
    4848'''Difficulty:''' easy-medium
    4949=== Required skills ===
     
    5656== Distributed Domain Name System (DNS) ==
    5757The 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.
    58 The idea for this task would be that the DNS system needs to turn into a distributed, easily updatable system.
     58The idea for this task would be that the DNS system needs to turn into a distributed, easily updatable system.[[BR]]
    5959'''Difficulty:''' medium
    6060=== Required skills ===
     
    6464
    6565== Revive Kademlia DHT ==
    66 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.
     66Peers 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.[[BR]]
    6767'''Difficulty:''' difficult
    6868=== Required skills ===
     
    7676
    7777== I2P seeding for applications (so central reseed locations are no longer required) ==
    78 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.
     78A 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.[[BR]]
    7979'''Difficulty:''' easy-medium
    8080=== Required skills ===
     
    8484
    8585== A website using i2ping ==
    86 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
     86Currently 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.[[BR]]
    8787'''Difficulty:''' very easy
    8888=== Required skills ===