Changes between Version 14 and Version 15 of gsoc/ideas

Mar 11, 2009 10:18:17 PM (11 years ago)


  • gsoc/ideas

    v14 v15  
    2020The 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.
    22 == 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).[[BR]]
    24 '''Difficulty:''' medium(depends on, which way you go)
    25 === Required skills ===
    26  * Programming knowledge, both desktop programming and web programming (for a wiki frontend)
    27 === Dependencies ===
    28  * Distributed data storage on I2P (optional -- if such a wiki is built on a distributed data storage system)
    29  * Distributed version control systems (optional -- if such a wiki is built on top of a distributed version control system)
    30 === Inspiration ===
    31  *
     22== Application level ==
     23 * [wiki:gsoc/ideas/apps/distributed-wiki Distributed wiki on I2P]
    35 == IPv6 support for I2P ==
    36 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.[[BR]]
    37 '''Difficulty:''' easy-medium
    38 === Required skills ===
    39  * Java
    40 === Notes ===
    41  * Some initial work has already been done in the i2p.i2p.ipv6 monotone branch.
     27== I2P router ==
     28 * [wiki:gsoc/ideas/router/ipv6 IPv6 support]
     29 * [wiki:gsoc/ideas/router/dht_kad Revive Kademlia DHT]
     30 * [wiki:gsoc/ideas/router/seeding I2P seeding for applications]
     31 * [wiki:gsoc/ideas/router/qos Improving the Message Priority System and looking into QoS]
     32 * [wiki:gsoc/ideas/router/upnp uPnP support]
     33 * [wiki:gsoc/ideas/router/android-port Port I2P to Android]
     34 * [wiki:gsoc/ideas/router/code-data-seperation Separate Code and Data]
    45 == Distributed Domain Name System (DNS) ==
    46 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.
    47 The idea for this task would be that the DNS system needs to turn into a distributed, easily updatable system.[[BR]]
    48 '''Difficulty:''' medium
    49 === Required skills ===
    50  * Java
    51  * Understanding of DNS
     37== I2PSnark ==
     38 * [wiki:gsoc/ideas/i2psnark/multitorrent Implement Multitracker support]
    54 == Revive Kademlia DHT ==
    55 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.[[BR]]
    56 '''Difficulty:''' difficult
    57 === Required skills ===
    58  * Java
    59  * Good knowledge of networking protocols, network routing ...
    60  * Willingness to learn about different types of Distributed Hash Tables and research how well they would fit into the I2P network
    61 === Notes ===
    62  * 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.
    63 ----
    66 == I2P seeding for applications (so central reseed locations are no longer required) ==
    67 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.[[BR]]
    68 '''Difficulty:''' easy-medium
    69 === Required skills ===
    70  * Java
    71 ----
    74 == A website-uptime site ==
    75 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.[[BR]]
    76 '''Difficulty:''' very easy(probably too easy)[[BR]]
    77 === Required skills ===
    78  * Java
    79  * JSP/Servlet/... maybe?
    80 === Inspiration ===
    81  * http://inproxy.tino.i2p/status.php (via I2P)
    82  * (from outside of I2P)
    83 ----
    86 == Implement I2NP level ping ==
    87 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.[[BR]]
    88 '''Difficulty:''' easy
    89 ----
    92 == Improve i2psnark UI ==
    93 Currently the webui of i2psnark consists of only a single page, where all the torrents are listed. This should be improved somewhat.[[BR]]
    94 '''Difficulty:''' very easy
    95 ----
    98 == implement i2psnark multitracker support ==
    99 I2PSnark only supports torrent files with a single tracker url right now. And cannot create any with more than one as well.
    100 '''Difficulty:''' very easy
    101 ----
    104 == Improving the Message Priority System and looking into QoS ==
    105 === Required skills ===
    106  * Java
    107 ----
    110 == Finish uPnP Support ==
    111 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. [[BR]]
    112 '''Difficulty:''' medium-hard
    113 === Required skills ===
    114  * Java
    115 ----
    118 == Port I2P to Android ==
    119 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. [[BR]]
    120 '''Difficulty:''' hard-very hard-impossible
    121 === Required skills ===
    122  * Java
    123 ----
    126 == Separate Code and Data for Easy Packaging ==
    127 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. [[BR]]
    128 '''Difficulty:''' medium-hard
    129 === Required skills ===
    130  * Java
     41== Other ==
     42 * [wiki:gsoc/ideas/other/i2uptime A website-uptime site]
     43 * [wiki:gsoc/ideas/other/ddns Distributed Domain Name System]