Numbered List of Freenet Project Ideas

Hi there. Wall of text incoming.

Here are some projects which I think would take Freenet in some interesting=
 directions:

Capabilities / APIs
-------------------

1.  Introduce a restricted plugin API: nextgens has had this idea for a whi=
le - only give plugins a plugin API object instead of a full classloader wi=
th access to the entire Node. If plugins can only access Fred functions exp=
licitly intended for plugin use, it should be way easier to figure out how =
plugins are intended to do things, way easier to document and find document=
ation for because it=E2=80=99s all in one area, and it could also have bett=
er security characteristics with more work - like a system for plugins to b=
e granted and restricted from various capabilities, both within Freenet=
=E2=80=99s API and on the system. It=E2=80=99d be better for backwards comp=
atibility going forward because now it=E2=80=99s defined instead of plugins=
 reaching into the Node object and poking at whatever they found to make th=
ings work.

2.  Make FCP into a plugin: bonus points if it uses the restricted plugin A=
PI. It=E2=80=99d be a good way to test the plugin API and ensure it covers =
a good amount of functionality. This would separate an important function f=
rom core Fred code. (Side note: FCP really should require two-sided user in=
teraction like KeepassXC and its browser companion plugins, or an API key, =
instead of giving access to whatever plugin can connect to its port.) The p=
lugin might also be able to be run in a passive mode in a transition phase,=
 like GitHub can do with changes it makes, where its answer to a query is c=
ompared to that of the integrated FCP. (This=E2=80=99d have to be for some =
subset of queries that doesn=E2=80=99t change the state of things - are the=
re many/any of those? Maybe fall back to integrated FCP for things not impl=
emented by the plugin?)

3.  Supersede FCP with Protocol Buffers and gRPC: it may have made sense at=
 the time, but now there are well-established methods of defining network p=
rotocols and RPCs, and we=E2=80=99re really not doing ourselves favors by c=
ontinuing to roll our own. Doing something like this would make it easier t=
o build applications that use Freenet, like a mobile app that connects to a=
 node.

4.  Transport plugins: we need more things Freenet traffic can look like an=
d more ways for it to move around, and as a bonus doing this will likely co=
ntinue to turn up bugs in various places. There=E2=80=99s a PR for this fro=
m GSoC but it has long since stalled. https://github.com/ValveSoftware/Game=
NetworkingSockets would be very cool to layer Freenet on top of. Not to men=
tion a Tor Hidden Service transport plugin - listen as a hidden service, an=
d connect to other nodes so listening.

5.  Protocol Buffers for network communication: similar thoughts to FCP usi=
ng protocol buffers for local node control. It=E2=80=99d remove weird custo=
m code and make alternate implementations easier. (There=E2=80=99s still pr=
oblem of using Reijendal but that=E2=80=99s separate and seems more managea=
ble.)

6.  Can we adapt existing applications?: forgetting for a moment how JavaSc=
ript adverse much of our userbase is, can those who are willing to run it (=
not from Freesites but from local applications) be served by writing a back=
end powered by Freenet for an existing forum or wiki? How practical would t=
hat be to do? https://github.com/Requarks/wiki  https://github.com/discours=
e/discourse I feel like we=E2=80=99re spending a lot of effort trying to wr=
ite these applications from the ground up, and while that does have some de=
sirable properties it=E2=80=99s also more work for fewer features.


Packaging
---------

1.  First party distro packages: this may be easier once we=E2=80=99re fina=
lly done splitting freenet-ext. I=E2=80=99d been working on it but didn=
=E2=80=99t manage to finish so far. https://github.com/Thynix/fred-staging/=
tree/remove-freenet-ext I=E2=80=99m not opposed to standalone packaging in =
principle, but using package managers would probably both remove the need t=
o do a bunch of careful update work ourselves and allow better distro-speci=
fic integration and adaptation.

2.  Better support for package repositories in Freenet: I think this has be=
en discussed previously, and the Mempo folks ran up against the lack of thi=
s pretty hard, but one way to do it would be to have a MirrorUSK plugin tha=
t can mirror the contents of a USK/manifest to disk. Then, distro packages =
can install Fred with this MirrorUSK plugin already installed and configure=
d to mirror their repo, and point the package manager at the directory on d=
isk unless requested not to. Tada! Distro-specific updates over Freenet.

- Steve