[freenet-chat] is Publishing the only Freenet Killer App?

[David McNab]

Hi,

I've been reflecting on my years of intermittent involvement with the
freenet project, and trying to look at the bigger picture of Freenet's
place in the world, and the technical capabilities and limitations which
arise from Freenet's architectural model.

It feels clear to me that the ability to publish and retrieve freesites
and single content files anonymously is the One Great Freenet Killer App.

Publishing of freesites, as well as casual publishing/retrievable of
single content files like images, documents etc, is extremely scalable.
Flogs (freenet weblogs) are scalable because they can work like
freesites. Even RSS feeds are scalable.

My question is - are there any other uses of freenet which, in
real-world practical terms (with n percent of nodes running transiently,
and m percent of nodes on limited bandwidth), can perform effectively
and reliably at scale?

I ask, because after getting my pyfcp lib into a stable state, as well
as the 'freesitemgr' freesite insertion client app, I'm feeling a bit
dry on ideas at the moment.

I've thought of resurrecting FreeMail, and adapting it to the new FCP
interface, but I'm concerned about the fact that its design is based on
relentless KSK@ queue thrashing. I don't even know if FreeMail is
scalable. It certainly didn't work in Freenet 0.4-0.5. I tried several
retry algos, but none of these managed to lift it into a state where
message delivery became reliable. So I'm concerned about the possible
detrimental effect that a rebirthed FreeMail could have on the
fledgeling 0.7 network.

Is there scope to talk about a new keytype, something like a QSK@ (queue
space key), which would spare nodes and the greater network from being
hammered by endless ClientGet requests for mostly nonexistent KSKs?

A native queue-oriented key type, optimally supported within the core
node, would IMHO open up a lot of scope for new application concepts for
freenet.

Your thoughts?

-- 
Cheers
David