[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] Decentralized database
From: |
Christian Grothoff |
Subject: |
Re: [GNUnet-developers] Decentralized database |
Date: |
Sun, 14 Jan 2018 00:20:26 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 |
On 01/13/2018 08:23 PM, Amirouche Boubekki wrote:
> On 2018-01-12 22:53, Amirouche Boubekki wrote:
>> I'd like to create a database on top of gnunet.
>>
>> One might argue that gnunet-fs is already a database.
>>
>> Q: How can you discover links (as in a graph datastructure)
>> between files? How would you implement that in gnunet?
>>
>
> Others in the same thread mentionned CRDTs. My understanding is CRDTs
> are useful in a context of concurent writes which is not a usecase
> in my database design since you can not update a value. It's append
> only database. There is no update, so there is no conflict so there
> is no need for CRDT.
Eh, that's not necessarily true, as if two users can update, moving
A->B and A->C concurrently, you still have a conflict even in an
append-only DB.
> Even, in the git usecase I think we don't need
> CRDTs.
For me, Git wasn't a usecase, more a tool to efficiently send diffs and
to implement merge and notification strategies via the existing hook
mechanism. The use case would be applications that can define conflict
resolution strategies as hooks and can use the resulting restricted
subset of Git.
> On top the database, you will have GNS that will point to the latest
> version of a particular ressource E.g a wiki page (actually the
> description of the content of the wiki page not html). That can be
> updated by the owner of the given namespace AFAIU.
>
> Unlike, IPFS pages are not "static". The application will search for
> links of the current vertex and allow to implement dynamic pages like
> gnusocial, wikipedia all in the cloud *ahem* gnunet.
>
> Unlike, the current web, applications are run by the client which
> can be GTK or web apps. The interface is the database layered on top
> gnunet.
That can work if you have a single person in charge of updates (or at
least one person per GNS pointer). It fails for use-cases like
collaborative editing.
> I have questions about the DHT:
>
> 1) How are keywords stored in the dht (I assume) by the fs service,
> to later allow search? I looked at the code but it difficult to
> figure out alone.
Eh, hashed? The actual method is in fs_search.c:
sre->keyword = GNUNET_strdup (keyword);
GNUNET_CRYPTO_ecdsa_public_key_derive (&anon_pub,
keyword,
"fs-ublock",
&sre->dpub);
GNUNET_CRYPTO_hash (&sre->dpub,
sizeof (struct GNUNET_CRYPTO_EcdsaPublicKey),
&sre->uquery);
But notice the DHT operation is only done for the non-anonymous variant
of publishing.
> 2) Is it possible to store multiple values for the same key?
> The documentation is not clear about that.
Yes. Where in the DHT documentation should we clarify this?
> 3) Is the key in the dht random, or somekind of hash of the value?
> Same.
Never random, always hashes. Details depend upon the application, DHT
does not care.
signature.asc
Description: OpenPGP digital signature