Re: [GNUnet-developers] Namespace creation

[Christian Grothoff]

On 02/16/2013 01:50 PM, LRN wrote:
> Right now namespace creation is synchronous (RSA key is created
> synchronously).
> 
> With the changes to IPC, it now may be possible to use async RSA key
> creation securely, thus making namespace creation also asynchronous.
> 
> 1) Should API users be exposed to key creation? Right now they have no
> idea that namespace uses RSA internally (will it be switched to ECC at
> some point?).

I don't know if we go to ECC yet, but as per #2564 we'll definitively
move away from RSA.

> However, if we expose key creation functions to the API
> users, they will be able to create a key (synchronously or
> asynchronously), and then (with a new FS API function) create a
> namespace around that key. That way it will not be necessary to write
> yet another namespace creation function that works asynchronously (it
> will be synchronous instead; async key creation will be done by the FS
> API user).

As we may use yet again completely different crypto from both RSA and
ECC for namespaces, I suspect keeping the key generation internal inside
FS-API will continue to make sense. Still, of course, the API should be
changed to be asynchronous.

> 2) Should namespace creation API keep the "create always" behaviour?
> Right now you can only give namespace a name (key is generated
> internally), and if a namespace with that name already exists, the
> exiting one will be returned immediately, making the whole thing opaque.
> If API users are exposed to key generation, they may also take
> advantage of more transparent namespace creation from generated keys.
> FS API would fail to create a namespace if another namespace with the
> same name exists, UI will let user pick a different name.

For command-line tools, I think the current semantics are already just
fine; for GUIs, they _can_ query for a list of existing namespaces
beforehand, if needed.

> 3) Should namespaces have user-provided names, or is it OK to generate
> their names randomly? Is namespace name (as named by user at the
> moment) exposed in advertisements by default? If it is, then maybe
> using some kind of generated "Namespace-XXXXXXX" name initially would
> be better.

I think that's fine if the GUI designer thinks this is better;
ultimately, namespace names are only used for each user to be able to
tell his namespaces apart, so whatever way the GUI uses to present this
to the user is fine in principle.

> Anyway, from UI point of view it's more convenient to generate things,
> since no dialogs need to be shown.

Right, except that then later if the user ever has to pick between the
namespaces, we still need to think about how the user will distinguish
between the different namespaces.

> The idea is that only one namespace will be used by default, and
> initially one will have to be created. Showing the namespace
> management dialog (which is relatively large and multi-functional) at
> the initial UI startup may not be a good idea. Just generate a key,
> pick a dummy name, and be done with it. And if namespace name is not
> advertised by default, it doesn't matter what it's named, and since
> most users won't have more than one namespace, they won't be confused
> by naming anyway.
>
> Something like that.

Right, if our vision is *one* namespace per user per default, that's
fine.  And maybe having the GUI maintain this simplification for good is
also fine, as the additional widgets needed to support many namespaces
are likely to significantly reduce the number of users that are able to
use even just a single namespace.  And for most use cases that I can
think of, one namespace should be perfectly sufficient anyway.

So I'm fine with one namespace with generated (or default?) name from
the GUI-perspective --- right now, I think too few users really
understand what namespaces can do, so usability is probably the most
important thing to focus on. (Aside from fixing #2564...)


Happy hacking!

-Christian