I was thinking out loud in the chatroom earlier, and thought that it might help 
attract new users and bring enhanced usability if we had a way to support 
arbitrary but secure URLs in a similar way to the public DNS system. Perhaps 
this has been proposed and ridiculed before, i don't know. I've thought through 
some of the potential problems and ways to resolve them, and i think long term 
it is a good idea :)



------------
Proposal
------------

Our current URLs are implemented by requesting specific key types, SSKs, CHKs, 
KSKs, etc. However they are completely unfriendly and confusing to new users, 
difficult to tell apart at a glance, and extremely long.

So I'm proposing a Freenet system analogous to the public DNS system, but 
customized to retain anonymity, decentralization, and to fit the Freenet model 
of requesting data directly rather than requesting data from a specific 
computer/node.

We've got Freemail to replace E-mail, Freetalk to replace Usenet and forums, 
this would be FreeNS to replace DNS :)

While these "domain" URLs would not be directly analogous to DNS domains, 
functionally they would be similar, and the concept is already familiar to 
internet users so it would be quickly understood; we're requesting a specific 
Freesite. 

It is partly cosmetic of course but so is public DNS, which also makes things a 
bit easier on the users. 

Each FreeNS name would identify a specific "site" the user would like to visit, 
and FProxy could accept arbitrary site "domains" like this:

http://127.0.0.1:8888/myfreesite.freenet/6/history.html

Or, with a new key type: 

http://127.0.0.1:8888/FNS at myfreesite.freenet/5/us-constitution.txt

---------------------
Implementation
---------------------

Instead of linking to a specific node/computer like the DNS system does (which 
we don't want to do even if we could), it would be a redirect to an existing 
site inserted using an SSK, etc. It would also "mask" the real SSK URL much 
like the DNS system masks the IP of a public website. 

To enable this to work without building in central points of failure or control 
over the whole thing (or censorship), the system would not have a true "root" 
as the DNS system does, instead the node would support an arbitrary number of 
FreeNS lookup and mapping spaces, which would be SSK URLs containing a specific 
filename in a specific format (XML?), that would include key pairs of FreeNS 
names mapped to specific SSK URLs. These tables would be updated automatically 
in the background by the node, much like we update new editions of activelinks 
periodically, or check for new Freenet builds.

New installs could include a default FreeNS lookup space much like we include 
default activelinks, including mappings for common freesites to enable 
out-of-the-box use. Users could then add one or more community maintained 
FreeNS lists after installation. Of course this may introduce the possibility 
(near guarantee, actually) of collisions, but perhaps the system could include 
a relative trust system using WoT, where FreeNS domains returned by one list 
are trusted more than another, or perhaps we just warn the user that the 
freesite or filename they clicked points to two different SSKs, and let them 
pick if a clearly trusted mapping does not exist.

---------------------------------
Possible enhancements
---------------------------------

The second part of the "domain" could potentially serve as a namespace for the 
backend implementation of the name lookup somehow

Individual nodes could maintain a list of "known bad" and "known good" FreeNS 
mappings, and publish them alongside WoT identity trust lists, this may enable 
the entire thing to function decentralized with no true "lists" at all.

If we are making use of WoT, the creation of a FreeNS name for a newly inserted 
Freesite could be announced simply by adding it to whatever message digests 
we're already inserting from Freetalk for the day, others would pick it up and 
propagate it in their own decentralized FreeNS lists.

-------------
Problems
-------------

One potential problem could be that a user follows a badly formed link 
somewhere in freenet, or tries to just stick "myfreesite.freenet/6/index.html" 
in a browser box, which may cause the browser to issue a real DNS request, 
potentially compromising anonymity. Perhaps we can subtly alter the string 
format such that common browsers just fail to make the lookup, but at least 
Firefox is known to forward malformed URL strings to Google if they can't be 
resolved.



Reply via email to