gnunet-developers
[Top][All Lists]
Advanced

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

Re: Improving FCFS daemon


From: Schanzenbach, Martin
Subject: Re: Improving FCFS daemon
Date: Sun, 16 May 2021 12:07:53 +0000


> On 16. May 2021, at 13:53, Christian Grothoff <grothoff@gnunet.org> wrote:
> 
> FCFS is just a software that allows anyone to run a
> first-come-first-served registry. That's not something for GANA.
> 

Yes, but the policy for "pin" may be.

> We early on made the decision that the ".pin" zone would be public and
> free of charge, but of course extensions adding an option in the FCFS
> implementation to realize a non-public registry, or one where
> registration must be paid (say with GNU Taler?) are welcome. But those
> should then not be ".pin" but something else.

Hmm a Taler-based registry would be a nice little project. But the more I think
about it the less it makes sense to "extend" fcfsd.

> 
> What we could do is create a registry of default GNS top-level zones in
> GANA, and there we'd then put the public key of '.pin', together with
> other such registries. The tricky bit here is that we will need a policy
> that defines the process for adding and removing such entries. I think
> initially something simple would do, like "convince the GNUnet
> maintainers to add your zone". We can then decide on a case-by-case
> basis how high the bribe needs to be. ;-)

Yes, we should draft that.

BR
Martin

> 
> On 5/16/21 11:26 AM, Schanzenbach, Martin wrote:
>> We may also think about if the FCFS service falls under the authority of 
>> GANA.
>> Alessio made a good point wrt hidden names which would mean that we do not
>> want to put all registered names in GANA anyway, but the handling of FCFS and
>> its policy could be defined there.
>> 
>> BR
>> 
>>> On 16. May 2021, at 10:00, Christian Grothoff <grothoff@gnunet.org> wrote:
>>> 
>>> On 5/15/21 10:19 PM, Alessio Vanni wrote:
>>>> I'll add a section in the handbook after fixing the crash.
>>>> Should it be added as a subsection of NAMESTORE? I'm not really sure
>>>> where it would be more appropriate, but since at a source level it's in
>>>> the same directory, that seems to be a possible candidate.
>>> 
>>> I'd have put it under GNU Name System into a separate section. But,
>>> NAMESTORE is also not wrong.
>>> 
>> 

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

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