> On 16. May 2021, at 13:53, Christian Grothoff <[email protected]> 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 <[email protected]> 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. >>> >>
signature.asc
Description: Message signed with OpenPGP
