Skip to content
Stephen Oliver edited this page Mar 30, 2017 · 2 revisions

This page lists some ideas which haven't yet been started or looked into, but seem like they could be useful.

Uservoice

Until recently we were using UserVoice to track user suggestions and their respective popularities. Unfortunately the free version of UserVoice does not provide any adequate tools to deal with spam - in particular it is not possible to remove a spamming user.

The most popular ideas on Uservoice were:

Write a killer filesharing application

See Filesharing.

Currently Freenet has poor file searching and poor data persistence.

One GUI for all

This was originally a plea for a dedicated browser for Freenet, but IMHO the main issue is getting more functionality into the web interface and avoiding any clunkiness caused by its being a web interface. See Freetalk and FlogHelper.

This has been planned for a while, the most important issue from the comments appears to be getting the node back up to speed quickly after a pause.

This is closely related to Filesharing and data persistence

Use port 80,443,53,1863 for communication

This seems to be about transport plugins.

Many people can't use Freenet because they can't use encrypted UDP, they may only be able to use TCP or even HTTP.

Make FMS/Freetalk part of the Freenet project

A working messaging system (FMS or Freetalk) could be included in the core Freenet project and some fraction of time could be dedicated to it.

Currently the lack of a working, trusted, bundled messaging system contrasts with good usability of core Freenet. This is an issue for end users and harms user retention, because communities cannot exist without messaging. (Some people stopped running Freenet node altogether since Frost is unavailable).

Proposal

As a minimum, Freenet devs could review FMS/Freenet specs and publish an official "RFC-like" specifications for Freenet messaging. This would settle disputes over minor details. Making trusted specifications is of utmost importance too, because several messaging standards failed in the past (FMB, Frost) and both developers and users mistrust any new standard assuming it is fundamentally flawed too.

Ideally, Matthew could spend some time (say ~3 months) working on the messaging system. This could be a good alternative to the (proposed) diversion of donations to other projects. I am sure that most people would appreciate the trade-off: getting a working messaging system, even if core Freenet schedule is delayed few months.

Any suggestions for alternatives to uservoice would be very helpful. Please add them here. The obvious thing is a bug tracker with a voting system, but our current bug tracker is rather intimidating and unfriendly.

Network security

Developing attacks is a good thing. Freenet is vulnerable to several serious attacks but without a proof of concept we do not know *how* vulnerable; quantifying this would be very helpful in setting our coding priorities and in evaluating possible solutions. Several medium term security improvements will need to be extensively analyzed before they are deployed, such as rendezvous tunnels.

We cannot practically use onion routing on Darknet, but rendezvous tunnels may achieve something similar, by sending a bunch of (partially) random routed anchors out and having them meet up and use a shared secret scheme to establish a tunnel. Hence expertise with tunnels can help Freenet in the medium term. As it will slow things down we may only use it for those blocks which are predictable, or on those nodes with the strongest security requirements.

Social applications

Distributed revision control over Freenet looks to be a very interesting area of research. Source code, wiki's, all manner of things can be run on a fork-merge model, with only the changed files inserted. The project to convert wikipedia dumps into git repositories with history is an interesting precedent, although it can't be incorporated directly as it is not written in Java and Java git support is quite poor at the moment. And all this can connect to the web of trust. See also Fork-and-merge DSCM and Wiki over Freenet.

Application security

Sandboxing quasi-hostile code is another interesting area. For example, a filter for javascript that only allows it to access a specific, safe, API, or sandboxed plugins written in Java to run in the node itself with restricted privileges. Securing these will be a challenge as the ability to probe the datastore and time fetches and then insert that data could be deadly; restricting access to high accuracy clocks and parallel requests may help.

Clone this wiki locally