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

[SMoratinos]

First thank you for this discussion,
I learn lot of thinks about Gnunet :)

El 2012-11-08 20:49, LRN escribió:
> Also, i think i should note that if you're thinking of mimicking
> torrent indexers (moderated collections of well-categorized links) in
> GNUnet this way, you should remember that you can't put ads on the
> content of the database (or, rather, you can, but someone will just
> automatically strip them off and re-publish the database without them
> - - and people will use that version instead). And you won't have a
> web-site to show ads on, to accept donations on or to sell stuff
> (unless you want to just throw away anonymity/censorship resistance,
> and play whack-a-mole the same way TPB does right now;
We agree. This is not my objective.

> or the database
> viewer and format will be proprietary, in which case you won't see 
> any
> cooperation from us; and that still won't work in a long term).
We aggree.


> Or you'd have to go back to variant one, where database only contains
> things that database maintainer (who could be a group of persons)
> discovered on his own - that way database maintainer won't need to
> wade through swamps of spam/fakes targeted at him, just through loads
> of crap that will populate the global namespace. Or cherry-pick other
> people's namespaces (which the maintainer will learn passively, on 
> his
> own).
I have a problem with the variant one.
"database maintainer" will became important and precious for majority 
guys.
Like websites who index ddl link (direct download link), these websites
make money but they don't care about uploader and downloader.
I prefer a solution (if we success in this discussion) which give the
power to the network.


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 ?


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.