Re: [GNUnet-developers] Propose new feature - Search Indexer WebService for GNUnet

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09.11.2012 21:32, SMoratinos wrote:

> I think the second part of my previous mail was misunderstood
> (probably because of my english). I propose a third idea.
> 
> The first idea was "central server" = bad The second was "3 entity,
> a downloader, a uploader, and a database maintainer" = too many
> problems (cf LRN previous mail). The third is "database link
> indexer is a new service in gnunet". There is only one entity, a
> gnunet user, each gnunet user have a database.
> 
> The new service could be built on top of file-sharing, or not (i
> don't know). This is not a fs replacement but an extension or an
> alternative. Possible features : - gnunet-search-db : search in the
> local database. - gnunet-notifier-db : notify user that new
> content, only uri with metadata (like CHK) not the document, is
> arrived from the network. - gnunet-indexer-db : a process which
> accept new entry from network and put them in his database. A
> process wich send new entry to the network.
> 
> 
> Wwhat is this information which are store in the database.
> 
> It's like KBlock but with a all know K (i call it PBlock). For
> example K="gnunet_public" by convention. All uploader who want that
> a publication became indexes by this new service must publish the
> content with keyword "gnunet_public". When an uploader publish
> content under the K="gnunet_public", then gnunet-indexer-db send a
> PBlock to the network. The PBlock will be propagated over the
> network. If the Key is know by all, so intermediaries could view
> metadata and uri, and that's what we want. Am I right ? Is it a
> problem ?
That would be easily censorable _and_ nodes will not have plausible
deniability ("i don't know what i was routing") - anyone will be able
to see contents of these P-blocks, and thus it will be possible for
some parties to demand of nodes to do some kind of content-based
filtering (i.e. drop all P-blocks that have a word X in filename or as
one the other metadata items).

I doubt that Grothoff will like this suggestion.

> 
> 
> About the size of the database. I have no idea of that size. In the
> documentation, i have understood that KBlock are appromatively 1%
> of the content. If I have in my database 10000 PBlock who
> reference 10000 files with an average size of 1Go. The content of
> my database will be 100Go, it's too huge. But this is not a problem
> if we keep PBlock only for a few period. For example only which are
> 10days old. Because I actually want the fresh result not the old. 
> And I want notification not actually store all gnunet network ! If
> I want old content I can search via normal gnunet-fs-search. And
> guys who want store more historic can, if they want.
K-blocks can have any size up to 64k, their size does not depends on
size of the files they link to. If you keep them small, their database
impact will be less. The problem with them is usually that you have
more than one (much more than one). With your proposal there will be
[mostly] only one P-block per file, so that's totally not a problem.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQnZABAAoJEOs4Jb6SI2CwPI8IAJbCOFqj3m7LeflQslBz/oMJ
9o+3M7XU80e3QtilttuYcj9yfoNJDe0PpCO2CNkuy3ubOFzgnMVLyTUMBEi7eL4N
7BZqs6zl8rRZ5LzS2wa0ZTFG377swgDfSvid/+7fwWAjGzFEcrPLL5mCl24sLMmi
JedQHVnmufIRmv3aCzo44w58hPKfu0kIjUomxxYf0V3c4qoILVZMCXxuCIeq+2l3
yYMoK4+fqAzQh6op4bVb7EoUnKYXqU9DVvK/wQigBrGhV2gj8y13klAHviC11wHw
89pjwnDPJwLAGchVPzbThtgA+Me1QIB8et4md0nSZ1r2isJXlGjwEwUVLFfCDeA=
=9cVa
-----END PGP SIGNATURE-----