gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] Namespace creation


From: LRN
Subject: Re: [GNUnet-developers] Namespace creation
Date: Sat, 16 Feb 2013 22:50:52 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Thunderbird/21.0a1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16.02.2013 19:20, Christian Grothoff wrote:
> On 02/16/2013 01:50 PM, LRN wrote:
>> 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.
OK, then i'll write a namespace creation function that works
asynchronously.

>> 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.
If you only have one namespace, there's no confusion (nothing to
confuse it with).
To have more than one, you need to go to your namespace manager dialog
and create more. There you'll be able to name the new namespaces as
you wish and/or rename existing one. Again, no confusion there.

>> 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...)
Since you've mentioned that, how about generating update identifiers
automatically too? Say, you enter ns element identifier "foo", and GUI
will immediately fill the update identifier as "foo-2" or something.
Obviously, changing update identifier manually will switch that off,
so when you edit ns element id again, update identifier won't be updated.
Taking the burden of figuring out update id off users' shoulders may
help the usability.

How much effort does FS implementation put into looking for updated
items in NS? Would it have significant negative impact on the network,
if we make all ns items updateable by default?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRH9ULAAoJEOs4Jb6SI2CwjhYIANYCLD/EsI3a43fTz/nNZ9th
I2rQf5vYtyHgYpwIGjqVCdUpMKpiZY6dgmtGTNEsRqyNWYZeyXqDdAtCkRD2Vx2b
4K20liKBlHtOkVjE7p8tr53P2l5xA0EXsOE9iGF4ISit8DuwcdD7Z/9xC+nZ0u8c
m3w4tteVBFU36s/1lY5eG/jgTe2j4nDDat6chWxmuHs0kCidwM3Lec24V6C5jxPT
AZ1tuAQtFTggLe0rOGNuDJTlKM0h96SMmLy6F1hatXqsPe51TtX5i6lw6BRN2ajA
FrM6OQp8UU7a7isG5laMk+ehSIy2jVKW7mEQX2zkCG6khh0mMCRsWhndAR1KcPQ=
=VwoU
-----END PGP SIGNATURE-----



reply via email to

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