Table of contents:
-  Freenet basics
-  HTL (Hops to live)
-  Machine readable data
-  Key pairs
-  Keys;
- CHK (Content Hash Key), KSK (Keyword Signed Key), SSK (Signed/SVK Subspace Key), SVK (Signature Verifying/Verification Key), ARK ( Address Resolution Key) (internal use), TUK (Time Updatable Key) (does not exist yet)
-  Mapfiles/manifests:
- DBR, Active Links, Edition sites, FEC Splitfiles, Downloading files, NIM (Nearly Instant Messaging)
-  Error messages;
- “Route not found”, “Data not found”, ”Bad key”, “Unknown Network Error”, “Key collisions”
-  Client Software for Freenet
-  Freesites
-  Misc
Freenet is designed to be anonymous and totally peer to peer. Towards that end, you run a "node" that talks to other nodes. If you want some data on the network, you ask other nodes you know about if they have it. If they don't, they ask other nodes, etc. When a node replies that it does, indeed have the file, it starts passing it back up the chain. As the file travels through Freenet, nodes it passes through might keep a local copy, thereby improving future request times for the same data. This is the peer-to-peer part of Freenet. The anonymity exists because it is impossible to tell if a request for certain data came from your particular node. For example, you might just be handling it for another node which asked you for the data. Since no one can prove you asked for (or uploaded) the data, no one can punish you for your speech.
When you insert files into Freenet, your node tells other nodes that it has some content they might like. These other nodes take the file and pass it along a few times. In this way, even if your or another's node shuts down, the content will still be available on Freenet. You can never remove or update the file; the only way it will leave Freenet is if all nodes that contain the file get rid of it (usually if it is less popular than all the other files the node is holding). This is a nuisance sometimes, but is really one of Freenet's strengths: censorship is nigh impossible.
This is a major thrust of :Freenet free speech. No content on Freenet can be willfully removed or updated. Thus it is impossible to censor Freenet content by removing it or editing it unless you manage to destroy all the nodes that have the content in their datastore (and even merely requesting the file increases its propagation in the network). The Freenet community decides what is worthy speech because less popular content will eventually "fall out" of the network while popular content propagates throughout.
Freenet nodes over time specialize in certain types of keys (for example, keys starting with 'c') and learn who to go to for certain other types. Thus, Freenet has some basic routing capabilities to make requests faster. This is one reason that a long-running node will be more responsive and successful when requesting data.
Freenet nodes have a build number as part of their version number. Each node also has a last-good-build number built in. This is used in Freenet networking by refusing requests from nodes older than the last-good-build. Last-good- builds are only updated when a serious bugfix or network incompatibility has been introduced. In this way, node operators are forced to upgrade to newer code (a la Microsoft Word formats) because no one will talk to you if you are obsolete. I recommend you regularly update your node's code to keep current, since Freenet is very much in development.
A problem that arises from that structure is, that if some data is not available on Freenet, the requests would go around endlessly. To prevent this, every insert or request has a HTL number assigned. The maximum HTL at the moment is 20 (every higher HTLs will be reduced to 20). Every node a request passes usually decreased the HTL by one (and sometimes it does not, to prevent traffic analysis). So a request with HTL 20 takes longer than a reques with HTL 15 (the default) - but if HTL 15 does not yield a result, you might try again with a higher HTL (actually, if your browser supports meta refreshes - most current browsers do - a Data Not Found
will be redirected to a retry with higher HTL in 20 seconds.). Inserting or retrieving with HTL 0 will affact only your local datastore. But be careful - if you insert a file with HTL 0, every try to insert it with a higher HTL will fail, as the data already is in Freenet (even if it's only in your node and that one is transient, so no one except you can get it!)
Due to that problem (the data is only in your node, but nowhere else - that can happen if you insert a freesite and no one requests it, but your node's datastore is big enough to keep it) most "professional" Freesite insertion tools (FIW, fishtools) allow to bypass the local data store when inserting. If you run a transient node (like me), I'd suggest to switch that option on.
Machine readable data
Due to the structure of freenet (encryption everywhere) it has to handle lots of binary data that is unreadable for humans. When this data is shown to humans (e.g. in keys), it is encoded in a way called (modified) BASE64 so that it only uses
"-" and "~"
So the most important point for users here is that these "texts" are case sensitive. So don't mess up the case of them, if you ever have to use them...
It is important to distinguish "Keys" and "key pairs" on Freenet. The former is used to address content in Freenet (see next section), the latter is used to check authenticity of data that is in Freenet. Most utilities allow you to generate a key pair, if you need one. However fproxy does not have a nice form for that purpose. So if you need a key pair (e.g. for some tests with SSK keys), you have to open a terminal window or command prompt, change to your Freenet directory and type java -cp freenet.jar freenet.client.cli.Main
The result will show you a public and a private key, like this: Priv. key: AK3 Am Gr 3 Tto JYK8p H8 Tapc Hg L7p 9
Pub. key: zqAWHHcbu2KtCRbOrnZMJ7loajo
Entropy: Qjf R87 GS Jip A4 JW0 X4ly 0g
These keys are valid keys - however, do not use them for anything besides tests; as the private key is available to everyone here, this key pair has lost all of its security now.
Keys are used in Freenet to store or retrieve information. Information on Freenet consists of data and metadata. The data is what the user sees from a key, the metadata contains information needed for the retriever to use the content (e.g. redirects, mapfiles, or simply the type of a file). As freenet cannot be searched (yet), it is important to know the key if you want to get information. Data stored into a key cannot be removed from freenet (except if it gets dropped because no one requests it). Trying to store data into a key that is already used creates a "key collision". So data cannot be overwritten or updated either. Generally a key looks like "freenet:type
@name". The :freenet prefix is optional. Key types consist of three uppercase letters of which the last on is (at least, until now), a "K". When you reference an absolute key from a freesite, you use the syntax <a href="/type@name">link</a>
CHK (Content Hash Key)
Example: CHK@hdXaxkwZ9rA8-Sid T0 AN-bniQlgPAwI,Xd C Dm Bu Gsd-ulqbLnZ8v~w
Description: A content hash key consists of two parts of machine readable data (separated by a comma) that are generated from the content of the file. As this key type is the only one that is not limited to 32K data, it is usually used to store the actual files. All other key types usually only contain metadata. As two identical files will get the same CHK, one will get a key collision if he tries to upload a file that is already in Freenet - so CHK files save space in Freenet by preventing to insert the same file several times.
As for generation of the key both data and metadata are used, you can, on the one hand, reinsert a file by changing its metadata slightly. On the other hand, CHKs with metadata mostly do not collide because of the different metadata different programs use. So for insertion programs it is a good idea not to use metadata on CHKs at all (for splitfile chunks (see below) it is mandatory not to have any metadata.) [I planned to add this paragraph to part two, but as Kadmos wanted it here, I added it here...]
Theroetically, it would be possible to have two files that get the same CHK (as chk length is short and files are usually longer), but you would have to "brute force" lots of files if you want to archieve this, as the way CHKs are computed can not be reversed. I myself did not hear of any case where two different files collided.
Usually you won't see many CHKs, as they are usually "hidden" in a redirect or a mapfile. If you see it, there is usually a "/filename.ext" part appended to it. Although that is not officially specified, fproxy will use that file name if you try to save a CHK target to a file.
Inserting: For inserting something as CHK, simply specify "CHK@" as key. Freenet will calculate the real key for you and show it to you.
- Every CHK content is only stored once
- no size limitations of the content
- low risk of key collisions (with different data)
- insertion is easy (no key pair needed)
- You cannot determine the key before you have the file (you cannot say: next version will be here)
- The keys cannot be remembered by humans
- you don't know what the content should be when you see the link
- the filenames look ugly if you save them
- Saving files that are referenced from metadata of other keys
- saving huge metadata (e.g. large mapfiles)
- saving split file metadata
- Files you announce via another channel (e.g. a mailing list)
KSK (Keyword Signed Key)
Description: A keyword signed key is simply some human-readable text that does not need to have any relation to the file that is in it. However, usually it will describe what is in the key. The problem of those keys is that there is no control - everyone can insert data to any KSK if he does not get a key collision. Even if a KSK is used in Freenet, one can try to upload another file to that KSK with some small HTL value (HTL specifies how many nodes should be searched for the data) - if that succeeds (he "hijacked" the key), it will be kind of random which content is found first by someone who requests it. So if you try to fetch the key above, you will not necessarily get the GPL (General Public License, the license Freenet uses) - more likely you will get (i. e. I also got) a picture of a naked woman or the BSD Licence - or something completely different.
Due to that fact, KSKs cannot be used well to announce places where one gets the next "edition" of a site - as everyone could insert something there and it would not even be possible to determine who did that.
Usually this key type will only contain metadata that redirects to the CHK with the actual content.
Inserting: The key for instering and retrieving is completely the same - something inserted as KSK@example will be retrievable as KSK@example.
- Key can easily be remembered
- Keys can be determined before having the actual content (NIM systems)
- Everyone can insert into a given key
- when data can be indexed uniquely (e. g. author/title), information can be * retrieved without knowing the special key
- insertion is easy (no key pair needed)
- higher risk of a key collision (people use short names)
- NIM - sending a message to a freesite author
nessage indexes in chat systems like Frost
- Saving files you announce via another channel (e.g. a mailing list), if you don't think someone hijacks them
SSK (Signed/SVK Subspace Key)
SSK@T Dtk Q Zp HT Mbh Go Sx Wf R-ly8BTa4PAgM,phJ~Ig AAD Jkijt DO7i Ae Sw/toad/1//index.html
Description: A signed subspace key consists of two parts: a public key from a keypair and some human-readable text (that may contain slashes) separated by the characters "P Ag M/". There may be some "entropy" between the P Ag M and the /. To insert a file into a SSK, you need the private key of that keypair - for retrieving you only need the public key. So these keys allow to control a "subspace" of Freenet keys by your key pair. So you can insert a file as e.g. SSK@zqAWHHcbu2KtCRbOrnZMJ7loajoPAgM/example/1/test.txt and tell others that you'll upload the next version at SSH@zqAWHHcbu2KtCRbOrnZMJ7loajoPAgM/example/2/test.txt. A more automated way to do this are DBRs (see below) or Edition sites (although the latter use exactly that principle to tell people where they can find the next editions). If you do not give your private key away, virtually no one will be able to hijack your SSK keys.
Usually this key type will only contain metadata that redirects to the CHK with the actual content.
Inserting: For inserting you need your private key. A file inserted as SSK@AK3 Am Gr 3 Tto JYK8p H8 Tapc Hg L7p 9/example.txt can be retrieved at SSK@zqAWHHcbu2KtCRbOrnZMJ7loajoPAgM/example.txt - a file inserted as SSK@AK3 Am Gr 3 Tto JYK8p H8 Tapc Hg L7p 9,Qjf R87 GS Jip A4 JW0 X4ly 0g/example.txt can be retrieved as SSK@zqAWHHcbu2KtCRbOrnZMJ7loajoPAgM,Qjf R87 GS Jip A4 JW0 X4ly 0g/example.txt. Note that these two keys will collide as the entropy is only used for encryption, not for the place in the datastore (I'm using the example keypair mentioned above for this example). Authors of new freesites should use keys with entropy, as it is harder to brute force the contents in the datastore for them.
- Keys cannot be hijacked - even if they are still empty
- If you use your own key pair, and do not use keys twice, there is no risk of * key collisions
- Keys can be determined before having the actual content (for "updating")
- insertion is more difficult (you need a key pair)
- Only some people can insert into a given key
- Freesites (DBR or Edition)
- announcement boards in chat systems like Frost
ARK ( Address Resolution Key) (internal use)
An ARK looks like an SSK, but is used internally by one node to announce that it got another IP address. If a node is unreachable, the node that tried to contact it, fetches its next ARK to get the new IP address.
Matthew (amphibian) writes about ARKs:
Essentially, the node inserts the full node reference under an SSK every time the physical address changes. Other nodes look it up when the node is persistently unreachable.
TUK (Time Updatable Key) (does not exist yet)
the word TUK is used whenever someone discusses about keys that can be updated. Most likely no one knows how they should work, but everyone wants to have them ;-)
Everyone that uses Freenes will see links that use manifests quite fast. Those links contain a double slash (look at your location bar to see one). For referencing a file in a mapfile, fproxy requests the mapfile (the part before the //) first. It contains lots of metadata - file names and CHKs - one CHK for each filename. Then fproxy looks up which file name you look for and fetches that CHK. Freenet is quite high-latency - so fetching two small keys take lots longer than fetching one larger key. Usually files for a freesite are inserted as SSK - so one SSK as redirect to a CHK for each file is a bit much. Using mapfiles, you only need one SSK to redirect to lots of CHKs. Another advantage is that fproxy can determine quite fast which files do not exist (if the freesite author made a mistake) and show a descriptive error message instead of fetching a SSK - if you want to see that message, click here.
DBR means Date Based Redirect, and that is some kind of metadata that redirects to a different key (usually a SSK) every day, week, or any other (constant) time interval. Most DBRs update every day at midnight GMT. Internally, it adds the string after the first slash of the SSK. (This string looks like "3c057a80-" and is the number of seconds since 1970-01-01 in hex; this example is from Nubile and means 2001-11-29 - so you can imagine how outdated the information there is * g * .) Usually, at this location a mapfile is inserted - so you only need one DBR for your complete site.
As mapfiles change very often when you use a DBR (even if the site remains the same all time), there is a high risk that the mapfile of an unknown site gets dropped. Also, it is somehow frustrating to click a link and get absolutely nothing, because the author forgot to insert the latest DBR slot. So most sites have a 95x32 pixel image (PNG or GIF) that is inside the mapfile and is used to link to a site. As every user who sees the link loads the image (and so the mapfile), on the one hand the mapfile is propagated through freenet and on the other hand you can see from the links (if you wait long enough) if there is a chance to get some content. On the oldest Freenet portal, The Freedom Engine (formerly known as Content of Nice or Co N), all sites are linked with Active Links
, so you can get some impression about which sites are available and which are not.
For people that don't have a permanent internet connection (or for people that have other hobbies than Freenet, SCNR) it might be a problem to insert their site regurlarly (every day or week). So there has been established another type of freesites, that is not supported in any kind by the underlying Freenet Protocol (as long as there are no TUKs), but works on using the reader to determine when a site has changed. For that purpose Active Links
to "future" editions are added to the top (or bottom) of the freesite. When a new edition is available, users will see them and click them to get the current version. The disadvantage is that everyone who links to an Edition page has to change the link from time to time, so that users don't have to click onto several Active Links
until they have the latest edition. To make that link changes easier (and to allow automatic checks for new editions), it is now "best common practice" to end Edition manifest URLs by a slash and a decimal number that is increased for every edition - in other words, Edition URL will contain "/number//". Index sites like TFE try to get future URLs (with an increased number) from time to time to update their links.
Generally a splitfile is some kind of metadata that contains links to CHKs which contain parts of the file. In "traditional" splitfiles, the whole file is split into parts of nearly the same length (usually all but the last one use a power of 2 as length, as these Data Lengths can be handled best by Freenet), called "chunks" or "blocks". The advantages of these splitfiles is that there are smaller keys (every node has a maximum file size, usually defaulting to 1 MB) now, that they can be split between different nodes (one file must be stored by one node completely) and that it simplifys "resuming" downloads (one key can only be fetch completely, not in parts) when a network error occurs: The blocks already downloaded are in your datastore and you only have to fetch the rest of them.
However, these are the "traditional" ones (you can also call them the "deprecated" ones, if you like that word better). The large disadvantage of that splitfiles is that, according to Murphy, you will always get all but the last block for a file - and so splitfiles leave a lot of "useless garbage" in the network. As a solution to this FEC encoding is used. This quite slow and mathematically complex algorithm can create check blocks - by default half the number of the data blocks - of which every subset of the original file's size can regenerate the file completely. So if your file has 10 data blocks, 5 check blocks are created for them, so that any 10 of these 15 blocks are enough to reconstruct the data. This seems to be inpossible when you hear it first, but it works.
So when you insert a FEC splitfile, encoding the check blocks will take some time (there is a faster native FEC codec available somewhere to be inserted into Fproxy; but I did not need it, so I cannot tell you how to use it), and insert will take 1.5 times the time of a regular splitfile. However, when someone receives the file, it is more likely that he will get the full file - and if there were unretrievable blocks, fproxy will reinsert them to "heal" the FEC splitfile. So, if you want to be good for freenet, do not disable healing in a FEC splitfile download page.
One point may be confusing about downloading files from Freenet. Usually on the Web, you right-click the link and say "Save location to..." to save the link's destination. However, in Freenet files that are no HTML files will have an additional confirmation page where you have to confirm that you really want to download the file (as some browsers might run it and it could compromise your anonymity). So better use left-clicks there, and select "Force save to disk" on the confirmation page. Another reason why to use left-clicks is, that if you try to download a FEC split file, you can set several parameters for that on an extra page. If you chose to save to disk, you would save that page instead of the real file.
If you use a download manager, disable it for freenet. Freenet files cannot be resumed directly, so there is no need for an external download manager.
NIM (Nearly Instant Messaging)
NIMs seems to be the preferred way to provide feedback to a freesite author. Someone who want to send some feedback inserts it under a KSK like KSK@fxcomment-1, if that one is used, he tries KSK@fxcomment-2, and so on. The freesite author usually checks the next few number for new NIMs every few days/weeks/months and so gets the feedback. To simplify that kind of inserts, most freesites that accept NIMs provide a NIM form (like the one below). If you want to send a nim, you click some of the number links at the top until you get one that says Data not found - then you adjust the number in the text box (that one after KSK@fxcomment-), write your own text into the text box and submit.
Usually, all NIM forms should work the same way - however, there was a change to Fproxy's insert mechanism some time ago, and so you might find NIM forms on really old sites that don't work as exspected. In that case, simply use another form (e.g. the one on TFE) instead - don't forget to specify the correct key!
The reason for that is that the request should have been sent to another node (according to the current HTL), but your node did not know another one. Fproxy also shows you some statistics what the other nodes did: if all were "unreachable", most likely there is a problem with your internet connection or your node reference table or the network is in a bad shape. Try to decrease the HTL down to 1. If you still get a Route Not Found, the problem is your node. Check that your internet connection is working - if it is, download new seed nodes (in Windows, right click the bunny and select configure; then click "Import new node ref" and "download references")
Another thing you can try is downloading the GPL - this key is one of the most requested ones and so you should be able to get it.
On the Nubile freesite there are some alternative sources for getting seed nodes, but they are either outdated or not working any longer.
In that case, enough nodes were found - but none had the data. If the data is really new (e.g. you heard on IIP that it has been inserted in the last minutes) wait a few minutes and try again - maybe it is not stored properly yet. Otherwise you can try to increase the HTL (up to 25). If the data is there, you should get it then. If you have to pay for your inet connection per minute and need some data you don't get,in times of high network load (e.g. when there was a new release) hit might help to start fetching it with HTL 25, and then diconnect your internet connection after about half a minute. Come again in half an hour and most likely you will have it in one minute or less (the data is propagated to the node next to you, as your node could not be connected)
You will get that message if you specify an incorrect URI (e.g. use wrong characters in the CHK.). Check that you did not make a typo/ did not forget to copy a part of the URI.
Unknown Network Error
If you see this message, please do what it says (copy the full message text and send it together with information about your system (operating system, java version) to email@example.com.
Most likely this is some kind of recursive redirects (e.g. KSK@foo redirects to KSK@bar, which redirects to KSK@foo) - or it is a serious bug in the Freenet software.
This is something you might get after an insert. If the insert was at a CHK@, this means that the file was already available on Freenet - so usually no problem. If it was another key, it might have been collided with different data. To check this, download the key, and if you get another file, you should try inserting at a different key. If you got the same file, it seems to have been collided with itself, so the file still is somewhere in Freenet (perhaps only on your own node).
A rather "hackish" way to reinsert text or html files that produce a key collision is to add a newline to the file (thus making it different) and reinserting it. This should not be necessary, but sometimes it seems to be.
Client Software for Freenet
For current Freenet software, check the Applications page on the Freenet website and some of the other newbie sites here in Freenet. Or see For Developers
So, you have some content you want to offer the Freenet world? Great! If it's files, music, or other such data files, you may be better off inserting it into Freenet via Frost and telling others about it in the appropriate board. If you have something like an essay or a one-shot item, you might be better off handing it to someone like Cof E to post, rather than taking on the commitment of a freesite.
That being said, Freenet could always use some more portals of content and there's plenty of room here. If this is your first time, I recommend you insert your freesite in a similar manner to this one, using an edition-based system because you are not pressured to constantly insert it on a daily basis. (Believe me, it gets old fast.) When you are more comfortable, you can move over to a DBR system.
However, DBR sites are also nice because they are easier to use. You don't have to monkey around with changing static links on your site to other editions of your site and you don't have to tell people when a new edition is out; it is all handled by the clients transparently.
You're going to want to grab an SSK to use. Do not give the private key to other people. I highly recommend testing anything you insert under some made-up key (i.e. SSK@blarg/testing/) in your SSK before inserting it under the key you give out to others (i.e. SSK@blarg/mysite/). This way, you can test it to make sure it won't trip fproxy's anonymity alarm or some such, which occurs if you have links that might ruin the anonymity of your users.
Basically, to link to sites outside of Freenet, you must use the following syntax: <a href="/__CHECKED_HTTP__sourceforge.net">. You cannot write /__CHECKED_HTTP__http://sourceforge.net
. To link to other sites within Freenet, write something similar to <a href="/SSK@blarg"> -- the preceding / is the important thing. To link to other files on your freesite, just link to them relatively, like so: <a href="otherfile.html">.
If you are linking to static content outside of your site, like some mp3's or a video, please link directly to the CHK. This makes one less file request for your readers and ultimately makes the link more reliable.
Note: You should be inserting using a map file, which is one file that tells users where to download all the other files of your site, by CHK. This makes sites infinitely more propagatable because only one file really changes each update and there is only one redirect. You don't have to worry about manually inserting these, the tools should do that for you. But just be aware of it. These are what lets you use relative links without a care, since the user has already downloaded the map file that tells them what the link's CHK is.
To let other people access your site, give them the URI SSK@<public SSK key>/<site name>//. The double slash at the end means that the file is actually a map file, containing pointers to the files in your site.
Also, you may want to make a picture for your site that shows well at 95x32 pixels so that other sites can link to yours.
Check out my method-specific sections on editions and DBRs.
Ok. So you're going to insert using Editions. This has the advantage of letting you update as little or as often as you want. If you see some major mistake, you can fix it immediately, instead of waiting a day. If you don't see a major mistake, you can wait a week or so before updating.
The only thing to be real careful of is to always have a link to the next edition of your site in a prominent place. Since you haven't inserted it yet, you're making a commitment to use the filenames to which you have linked. You might want to link to more than just the next edition as well because if you screw up anywhere along the line using a single-link chain of editions, it can be difficult for users to know, and the chain will be broken. Also, some editions may fall out of Freenet for whatever reason and a visitor to an old edition would think you haven't updated yet. Thus, you may want to have another means, in addition to the on-your-site-links, of letting people know about updates. Maybe a Frost board?
First, get the FCPTool-provided fcpputsite. For instructions, check out my FCPTool section.
To actually insert the site now that you have your new fcpputsite, if you have all the files you want to insert in one directory (with an index.html) and your fcpputsite executable in your path, then type in fcpputsite -d <your site name>/<your edition number> <directory of your site files> <public SSK key> <private SSK key>
For example: fcpputsite -d nubile/9 files9 qe3ZRJg1Nv1XErADrz7ZYjhDidUPAgM privprivprivprivprivprivpriv.
A DBR is a date-based redirect that will automatically tell Freenet clients to look at a different key with today's date in seconds since epoch (Jan. 1, 1970) in hex. So, if you have a freesite at SSK@foo/bar//, the DBR says to go look at SSK@foo/3f982d-bar// for example. DBRs are great, since everything is transparent and all you have to do is make sure to insert your site every day before midnight GMT, since that is when DBRs roll over. You have to reinsert even if nothing has changed. If you haven't inserted, users requesting your site get redirected to a date key that you haven't inserted under yet, thus making your site appear offline. If you know you won't be able to update for a while, you can avoid your site being unavailable by inserting into the future, as you'll see below.
First, get the FCPTool-provided fcpputsite. For instructions, check out my FCPTool section.
Put all the files you want to insert in a directory with an index.html as your default file. Now, say fcpputsite -f <number of days in future to insert> <your site name> <directory of your site files> <public SSK key> <private SSK key>.
For example: fcpputsite -f 1 nubile files qe3ZRJg1Nv1XErADrz7ZYjhDidUPAgM privprivprivprivprivprivpriv.
It is wise to insert a day in advance shortly before GMT midnight. This way, the insert will be over and done with when the date switches and readers can get it immediately.
You're all done. Wasn't that easy? Now, just do that everyday for the rest of your life. :)
Nearly Instant Messaging
If you want reader feedback, but don't want to bother with FMB or Frost, then NIM is the way to go. It is a form submission that will insert messages under a predictable scheme -- like, KSK@myfeedback-1, KSK@myfeedback-2, etc. To read user comments, just check each of these until you start getting Data Not Found messages.
Here is some sample code to put in your freesite (adapted from Cof E's NIM) This uses the base KSK@myfeedback and has some explanatory text. The numbers for keys to insert under are hard-coded and need to be adjusted each time you receive the messages.
<p><a name="nim"></a><font size="+2">Feedback</font></p>
Enter your comment in the text box. Check the below possible numbers
for already-present messages to avoid a collision, adjusting the insert
key if necessary, then click send.<br>
Please no test messages.
<p><font size="+1">Possibly Available Keys</font></p>
<a href="/KSK@myfeedback-3" target="_blank">3</a> -
<a href="/KSK@myfeedback-4" target="_blank">4</a> -
<a href="/KSK@myfeedback-5" target="_blank">5</a> -
<a href="/KSK@myfeedback-6" target="_blank">6</a> -
<a href="/KSK@myfeedback-7" target="_blank">7</a> -
<a href="/KSK@myfeedback-8" target="_blank">8</a> -
<a href="/KSK@myfeedback-9" target="_blank">9</a> -
<a href="/KSK@myfeedback-10" target="_blank">10</a>
<form method="POST" enctype="multipart/form-data">
<td><div align="center">NIM - Nearly Instant Messaging - originally created
<td> <div align="right"><font size="-1">Target Key</font></div></td>
<td> <input type="text" name="key" value="KSK@myfeedback-3" size="30">
<font size="-1">Increase message number as required.</font></td>
<td> <div align="right"><font size="-1">Message</font></div></td>
<td> <textarea name="filename" rows="12" cols="80" wrap="virtual"></textarea></td>
<input type="hidden" name="htl" value="15">
<input type="hidden" name="content-type" value="text/plain">
<td> <input type="submit" value="Send message ">
<font size="-1">Note : Sending a message may take a long time.</font> </td>
GPG stands for Gnu Privacy Guard. It is a free software implementation of the non-libre PGP and is used to verify that messages are from one particular person. It uses key pairs consisting of a private key and a public key, much like SSKs. For example, on the of this page, I offer my GPG public key for download. You know this is from me, since only I control what is inserted under my SSK. Thus, you can use this key to verify that files or messages in Freenet (but that don't have the comfort of being under my SSK) actually come from me. I might sign messages in Frost, for example, and using my public key, you could verify that I actually wrote the message.
I will, instead of writing a half-ass writeup of how to use GPG, refer the reader to the excellent documentation already made available by the Free Software Foundation.