[Top][All Lists]

[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 <> 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.


> 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 <> 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]