help-gnunet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about using gnunet to build an application


From: Christian Grothoff
Subject: Re: Questions about using gnunet to build an application
Date: Thu, 20 Oct 2022 15:37:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

On 10/20/22 12:17, Lily wrote:
> Hi! I've been evaluating gnunet for one of my personal projects and I
> had a few questions:
> 
>   * I saw in the docs that gnunet uses proof-of-work in a couple places
>     (NSE and Revocation), would this work well on something like a
>     smartphone? If not, are there alternatives in the works?

I would expect that it is very rare for a private key managed
exclusively on a smartphone to require to be globally revoked.

As for NSE, it's perfectly OK for the smartphones to not be counted as
part of the network size estimate, so you could configure the throttling
of that computation to make it so slow that even on a smartphone it
doesn't matter.

>   * Does the messaging application guarantee consistent ordering of
>     messages across different nodes?

I think right now yes, but Jackie may have plans to void this in the
future (not sure).

>   * I saw there was a social subsystem in the works, is there any
>     information about that public?

Well, it's not actively maintained for a few years, but secushare.org
has some of the ideas.

>   * How stable is gnunet, is it something that could be relied on to
>     build a stable p2p application on top of today?

Honestly, a small subset of the APIs (DHT, GNS, revocation) is what I'd
consider really stable, and the the lower layers (including the
protocol) are very frequently changing and will continue for some time.
Also, some components work quite well, others not so much. And we know
we have much work to do to make things run nicely on mobile phones. So
probably the answer is 'no', but of course you're welcome to help us
make GNUnet meet your requirements.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]