gmane.network.gnunet.devel

GNUnet < at > Google Summer of Code

Bart Polot — 2013-04-11T13:48:04

Hi all GNUnet hackers!

Are you a student in any recognized university and are you interested in hacking 
on GNUnet and have Google pay you for it? Now it's possible! GNUnet is 
participating in the Google Summer of Code[1] under the GNU umbrella[2].


The Google Summer of Code gives you the opportunity to work on a GNUnet-
related *coding* project with one of the GNUnet developers as your mentor. The 
current ideas page is up [3] but feel free to suggest your own ideas!


- Go look at the Google Summer of Code FAQ [4] to make sure you are eligible to 
participate (basically, currently studiyng at any university outside of the US-
defined Axis of Evil). Important: if you are currenly working on GNUnet you STILL 
qualify to continue working on Google's bucks!
- Have a look at our ideas list [3] to see if one of those projects matches your 
interests.
- If there is no project on that list that you'd want to work on, read the 
documentation on our website [5] or our bug-tracker [6] (see various feature 
requests) and make up your own project idea!
- Come to #gnunet on Freenode or send an email to any mentor from the GNUnet 
ideas page and let us know about your project idea. Communication is essential 
to success in the summer of code, and we're unlikely to accept students we 
haven't heard from before reading their application. So really, come talk to us 
first!

Finally, write down your project idea and submit your application to Google until 
May 3, 2013 [7].

We are looking forward to discussing your project idea with you!

[1]https://www.google-melange.com/gsoc/homepage/google/gsoc2013
[2]https://www.google-melange.com/gsoc/org/google/gsoc2013/gnu
[3] https://gnunet.org/gsoc2013
[4] https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page
[5] https://gnunet.org/project-overview
[6] https://gnunet.org/bugs/main_page.php
[7] https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page#8.
_When_can_I_apply_for_Google_Summer_of
_______________________________________________
GNUnet-developers mailing list
GNUnet-developers< at >gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: GNU Guix GSoC ideas

Ling Kun — 2013-03-26T05:11:12

unsubscribe


On Tue, Mar 26, 2013 at 2:11 AM, Ludovic Courtès <ludo< at >gnu.org> wrote:

Re: Using GNUnet for binary package distribution

Christian Grothoff — 2013-03-22T14:42:56

I think looking into that specifically would make sense.


No, I don't think it would interfere. Matthias and Bart will generally
be happy to mentor GSoC hacking this year, and I suspect Sree Harsha
wouldn't mind giving advice either, so mentoring should not be an issue.

Happy hacking!

Christian

Re: Using GNUnet for binary package distribution

Ludovic Courtès — 2013-03-22T13:56:56

Christian Grothoff <grothoff< at >in.tum.de> skribis:


[...]


Ah great, sorry for the misunderstanding.

Ludo’.

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers< at >gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Using GNUnet for binary package distribution

Sree Harsha Totakura — 2013-03-21T18:14:46

For authentication, we intend to use GPG with gnunet-update.  The idea
is that the gnunet-updater would search for updates using GNUnet's File
Sharing service and downloads meta-data files.  It then verifies if the
meta-data files are signed by a trusted key (which is user-configurable)
and proceeds with the download of actual binaries.

Using this approach the meta-data files and the binaries pointed in
meta-data can be published by anyone and still be verified.  This could
improve the availability of both meta-data and the binaries.

--
Harsha

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers< at >gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Using GNUnet for binary package distribution

Christian Grothoff — 2013-03-21T18:01:04

Well, the GNUnet DHT expects that the data source periodically refreshes 
the values by re-issuing the PUT; without that, it cannot work. 
Furthermore, you need to consider that DHTs are typically only useful 
for small data pieces (think <= 64k), not for large files.  So what 
you'd store in the DHT is the meta data (where to find the large files), 
not the actual files.

gnunet-update (svn/gnunet-update/) is a little project where we started 
to work on a GNUnet installer that is supposed to include an update 
mechanism that downloads updates via GNUnet --- after all, if you are
using a recent version of GNUnet, sharing your installation binaries
costs you at least no disk space at all, and if censorship kicks in,
having a way to update in a decentralized fashion might become important.

So gnunet-update is planned to provide the means to locate files based 
on some package description (signatures, meta data) and download them
via the P2P network.  Fundamentally, there is nothing wrong with using
the basic ideas to distribute packages other than GNUnet itself.

Our current approach to package management is essentially to look at ldd 
and grab all dependencies (unless compatible versions are already
available on the target system, based on libtool versioning info); the
idea was to make it work with 'any' distribution as long as the 
architecture matches.  Naturally, that doesn't mean that in principle a 
different package manager could not be used/supported.

gnunet-update is not yet finished, we're currently planning to revise 
some internal part that gnunet-update will depend on (stream); still, 
help in moving this area along would be of course welcome.

Happy hacking!

Christian

Re: NS updates

Christian Grothoff — 2013-03-02T19:34:59

I agree that it looks OK, I'm just not sure about the utility of
allowing loops. But I guess it is as much work to detect and flag them,
as it would be to detect and disallow them, so maybe this is already
just fine.

Happy hacking!

-Christian

Re: NS updates

Christian Grothoff — 2013-03-02T19:33:25

I did so far, but if you change code, things could be different ;-).


Ah, I though you were changing that code as well -- especially as you
talked about having made modifications to the FS API.


Ok.


Oh, I thought you were rewriting that entire API as well. Hence my
questions.  Clearly we do need to enable that hash map check enabled then...


Sounds messy.  Might be easier to just forbid the creation of loops via
the GUI (and possibly the FS API as well), instead of having
non-standard behavior of a standard widget.

Happy hacking!

-Christian

Re: NS updates

LRN — 2013-03-02T13:25:40

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

On 02.03.2013 16:49, LRN wrote:

Here's how it looks (hashes last_id, next_id, uri and last_meta).
Didn't even try to do that selection-jumping thing though. But it
looks OK without it too, so maybe that's enough.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRMf3TAAoJEOs4Jb6SI2CwEuUIAL2u7h0i1z6AW7hc+iyBjupH
5Nl9HN4q2IrBfFQS6l/+w7agTrHUnhAzc+qBN1A+rOSa64ATahl2tZ/DGGiH53i3
yESPQGErQNftwhqAGMOQujpJ/4/hQ1hG1LcgDN3QUCZ9CH2DdXSK+cEiM0qdm34S
bAN+N5tvvn57pNhnpzaFCfB3Z0l0pfEge7EenWiqGCqALEyeiKEZQBPXO8NWw0tf
0z4BbQboWUL9yWcFm0BDo7muUZoGa0987DCvngJRRBkRrEt8sfhokP+tS1999l4E
JsjE31308VoWYLDdWtyo85MyeoVlbcjlvuXhPfrET2eSiBUHTAfYvUIDJ005Hp8=
=Qvzw
-----END PGP SIGNATURE-----
_______________________________________________
GNUnet-developers mailing list
GNUnet-developers< at >gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: NS updates

LRN — 2013-03-02T12:49:21

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

On 02.03.2013 15:31, Christian Grothoff wrote:
My code is based on existed publishing dialog, which you wrote, AFAIK
(i am not aware of anyone else doing GUI hacking).

The correct question is "Do YOU allow it?".

That is exactly what happens.

The code that decides where "root" is was, again, written by you, it's
in fs library. Everything depends on its decisions.

No.

It doesn't. It shows what GNUNET_FS_namespace_list_updateable() tells
it to.

Apparently, GNUNET_FS_namespace_list_updateable() doesn't break the
cycle. I've just published test_7-1 that specifies "test_6" as its
update, looping back to its tree.
And fs-gtk enters an endless loop, with recursion, and eventually runs
out of stack.
Note that this is for the case where hashmap check is disabled.

A compromise solution would be to enable hashmap check, but make it
more sophisticated - take more than just "id" into account.
Also, when a previously-traversed item is encountered, don't just
return immediately - add the item, and set it up so that choosing it
will make the selection jump to its other copy somewhere else (which
is the only copy that is selectable; through i'm not sure i can make
GtkComboBox do that...), also marking it as such, and then return. So
it will be a tree, but with loopends that user can traverse.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRMfVQAAoJEOs4Jb6SI2CwZRAH/3T7bVywi5G9L6OkyLI9MfUr
seBoqJ6vvz5H8Hvp2PzMw43Cn1TuCA+vFJhAIzoKatvHUNhApSOFbegEiZ0nSuwm
UytgCz7GM/mUirDXZHriiIHB73O1n4g44pis6c/C6VMkKsQyzL1R7x43LV7iLM6x
JngA/1vlTfoOP0xq1IV6ox9nc69MioIh6HON7+xlOH6yVtcEBzyErwP76PQ598XU
uL3AMSsWV+l8mhENV8Yj+FLxK4ItcOTqQ6ty7O5ITGmZfrbaZf8XPWjCkT2JZVBY
ZNfucWRSKar3l0Y/cmu2rshvbK+zc/WGfM5/5Ocmhghrdf9e7i8a8fiDPvu1HR8=
=sIfk
-----END PGP SIGNATURE-----

Re: NS updates

Christian Grothoff — 2013-03-02T11:31:19

I don't specifically recall that suggestion, but obviously it is
possible to do it either way.  Not sure which way is better.


What does your GUI do if I publish a new entry as 'test_6-2' and specify
the update identifier to be test_7 (thus linking two existing trees)? Do
you allow it? If so, do you add the existing test_7 tree under the
test_6-2 tree?  What if I add an update identifier that points into the
middle of an existing tree?  What do you do if I specify an update
identifier within the existing tree (i.e. publish an entry 'test_6-2' to
be updated by 'test_6')? Do you allow that?

Do you actually try to guard against the things that are not allowed? If
yes, what's the error look like? If no, how does your GUI handle the
cycle in the update graph? What happens if your data structures on disk
contain such a cycle? (Never trust any external inputs, not even our
local disk database...).

Just wondering ;)

Happy hacking!

-Christian

Re: NS updates

LRN — 2013-03-02T04:50:34

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

On 02.03.2013 07:34, Christian Grothoff wrote:
This is what i have in my local repository (attached).
I'm currently putting some finishing touches on that, and then it'll
be ready to be dcommitted.

This implementation can't handle branching at all. See that test_6-1,
and its possible update test_6-2? If i publish _another_ test_6-1,
with a different update id, this code will replace existing test_6-1
with the new version, with its new update id. Previous test_6-1 and
its possible update test_6-2 will not be shown.
I think it's because of the multihashmap being used (that was your
idea, by the way). If i remove the multihashmap check, then it looks
like this (attached).

There's also a dialog for creating/renaming/deleting your own
namespaces (not attached). And appropriate changes to GNUnet itslef
(adds needed APIs).

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

iQEcBAEBAgAGBQJRMYUZAAoJEOs4Jb6SI2Cw6PMH/32vo1UkRJXB5kvtSXg6/+oc
RVHyy5x7smo/YThajMPpMHMG78mPdyzSU72inETecKAZn06LiB50uPkXcpnLKL/s
MyZU8bv6GaRp8Nq+bkfcuGLWO5zoU69G06mtCVVOHrGeurFnD9b76rLN/+bm7gQp
PcBWsg4F+DHg/aOX6tn3tV4JUVSQQqfza4GFMsSGsUgMWzO9SdFIrApZXNhtJKPl
c7MGI7RKDIkDfIjEqqxH6dC3IC8dhcQQuJPF3VMvRqgR+oDXstoEiphoDCHxL+iK
aSaWK52E9FwZ1zdRk0c09hAmLme89GZ99mBMWFeqbq827IPQUGhsi46Qkp2OMJg=
=xGWG
-----END PGP SIGNATURE-----
_______________________________________________
GNUnet-developers mailing list
GNUnet-developers< at >gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: NS updates

Christian Grothoff — 2013-03-02T03:34:57

Right.


Right, so here you can put in an update (generation X+1) and specify the
identifier for generation X+2.


Right.


Not quite.  The issue is that there kind-of is no root.  Theoretically
the update graph can have cycles (update for A is B and update for B is
A).  So the code goes through some pain to try to find a "nice" way to
represent the (potentially) cyclic graph in a tree structure.  That of
course is a mess, but as we technically cannot prevent a cyclic
construction (as we may only have a partial view of the namespace), I
somehow had to deal with this issue.  So the 'root' is not the 'initial'
publication.  You could, in fact, post some item with identifier B to be
updated by C first, and then LATER post another item with identifier A
to be updated by B.  The tree structure is supposed to represent the
resulting directed graph as best as possible.

Additionally, even if the directed graph is acyclic, it can have
_multiple_ "roots" in the tree (update for A is C, update for B is C).


The goal was to coax users into making an update TREE (not linear), but
to make it "easy" to construct and keep a tree structure, while still
being able to somehow capture the mess you get if the user somehow
specified some arbitrary directed graph instead.  Linear was never the
intent here; however, as from our other discussions I might still be
happy if a future version of the GUI focused on simple linear update
graphs; the question then is how we deal with non-linear constructions
--- do we simply "forbid" managing those within the GUI? Is the entire
namespace ONE linear update list, or do we allow multiple lines? Or keep
trees and force a forest? Again, libgnunetfs allows much, and we might
want a more restricted version for the GUI.


Yes, having a special widget to represent the directed graph would also
work, but hacking that up is a major nightmare, and I don't see that
happen anytime soon.  Additionally, the question is if this wouldn't be
another one of those cases where we write a ton of code that then is
useful for 0.0001% of the users that understand AND need it. At this
point, I'd rather like to see a simplistic GUI for namespaces that may
not allow much but that users do understand and sometimes use, rather
than heavy work on custom widgets for complex operations few will ever
understand or need.

So for me the question is more if we simplify to linear, to trees, keep
the current pseudo-tree (tree representing a directed graph) and/or how
we make whatever we choose to do _easy_ to understand. I'm very open to
suggestions (or patches ;-)).


Happy hacking!

Christian

NS updates

LRN — 2013-02-26T12:28:47

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

I'm looking at gnunet-fs-gtk core at the moment, and i don't get it.

It is my understanding that 'next_id' is simply an identifier, and its
presence in metadata indicates that GNUnet client should do a search
for that identifier, and any results should be considered 'updated'
versions of the original. Fairly straightforward.

add_updateable_to_ts() inserts "last_id" value it gets from the
iterator as PSEUDONYM_MC_LAST_ID, while setting PSEUDONYM_MC_NEXT_ID
to an empty string.

GNUNET_GTK_master_publish_dialog_execute_button_clicked_cb() gets
PSEUDONYM_MC_LAST_ID and PSEUDONYM_MC_NEXT_ID and uses them as
"identifier" and "update identifier" respectively.

When populating the treeview, PSEUDONYM_MC_CURRENT_ID_EDITABLE is set
to FALSE for all updateable items, it seems, and TRUE for all "empty"
rows (for new publications that do not update anything).
PSEUDONYM_MC_NEXT_ID_EDITABLE is always TRUE, no matter what.

But. GNUNET_FS_namespace_list_updateable () passes nsn->id as a second
callback argument (which becomes "last_id"), and nsn->update as a last
callback argument (which becomes "next_id").

So. fs-gtk pseudonym threeview seems to have four different item types:
1) "Blanks" - items for new publications, where you can edit both 'id'
and 'next_id'
2) "Leaves" - items for updates, where 'id' is frozen with the value
of 'next_id' from a previous publication, and 'next_id' is editable.
3) "Stems" - items that were inserted during the updateable items
graph walking. Their 'id' is frozen with the value of 'next_id' from a
previous publication, and 'next_id' is editable. They differ from the
leaves in that there already were updates to these items. Updating
them again will sprout more leaves (creating ambiguity, as one stem
will now have >1 possible updates instead of 0 or 1 updates).
4) "Root" - initial publication that started the update graph. Its
'id' is frozen with the value of 'id' (!) from the initial
publication, and 'next_id' is editable. Making "updates" with this
item will, in fact, produce a new publication with the same identifier
(thus increasing ambiguity, as one identifier will now yield multiple
items), and not update anything.

IMO (4) should not be in the list at all, why does
add_updateable_to_ts() add it? And the need of (3) is debatable as
well, since they break linearity of the update graph. If (3) is to be
offered, it should at least be indicated appropriately (to think of
it, (4) may remain in the tree as well, it just has to be unusable for
publications).
Do we _strive_ for linear update graphs at all?

It'd prefer to encourage users to maintain linear update graphs.
If someone wants branching graphs, we should offer a special widget
for that (you ever seen git commit trees in tutotirals? that's how
that special widget should look like, roughly).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRLKp+AAoJEOs4Jb6SI2CwtWgIANHV0qyepzKytSnpBycP9hbN
gohrabUHSfsq9KH6KOkWuXk8tU/8V2zAVYZ26LdxcAHbck50fmXmTyZSAbtpKNIY
xgjVnSOWOrcLAgC+eKygnRxsu0Q+KVsk6Q2mX3t/JNOi6AUYkVICZhO9Izf9KSU1
j3i0oVdsmG9qnoo74Vx9+FRkvSOf74uLB5Q+U8O9TOZOMSvRkO9EV87XLlFNAvut
tZg/IUkNAQi8HDqvlsrIMqcNGRRdqPIHOgTJsBXJ8Ww22xssSw+nrofHOTsOx0SJ
KPJ5g54uwAK5XfqF+gCOVMCG6RtSPGyt9VH3ljgSahzb66M8Aayh1pkJML1jU/8=
=uKtX
-----END PGP SIGNATURE-----

Re: Namespace creation

LRN — 2013-02-17T20:37:20

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

On 16.02.2013 19:20, Christian Grothoff wrote:

I just remembered a few things that might be relevant.
1) Google for "Barry Schwartz: The paradox of choice", there's a video
where the guy explains that having too much choice is discouraging,
especially if the one who has to make all these choices is not
informed well enough to make these choices...well...informed.
2) Gabe Zichermann in one of his gamification talks mentioned that
people are more creative when working in confined systems.

Just something off the top of my head.

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

iQEcBAEBAgAGBQJRIT+AAAoJEOs4Jb6SI2Cw5fQH/AxcFcLZDrSS5UtRAXam1uw1
cVbHdPM1rKmxFlYdTiqyiZ7SselY3UhwMl4cEplWmGmrg21JKtA919w003uu3X2b
mXA7k5+88nC7bFN2RQQv5sRpjI4chbzJYW9tr4C8tW0PRIPSHSX26dkMBPvesaDN
9xzxTPMer3T1XpzfQqLKaEm2jUFgdMsP1nVHAy25E8mEzrEVeXDzg2tnFCWHrYN5
mZ5+LEK1CmWwuWFqsL51D6DbvxowB6h723gBBpdTadS61CFKkzfpuJyC0yBOHxHZ
OfBxwr6qp17lIROHZtaAJrpNQVOlJVNSlgDXyqXhkn9DyAoNyQjiOh2aYLUQWh4=
=ktDZ
-----END PGP SIGNATURE-----

Re: Namespace creation

Christian Grothoff — 2013-02-16T19:22:54

Might be a useful to generate something like this by default.


The additional load for update searches should not be significant; the
only possible issue is that one might want to specify "no updates" for
some SKS URI, so that one can also never be forced to produce an update.
But that might also be just a mostly useless feature in practice...

-Christian

Re: Namespace creation

LRN — 2013-02-16T18:50:52

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

On 16.02.2013 19:20, Christian Grothoff wrote:
OK, then i'll write a namespace creation function that works
asynchronously.

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.

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

Re: Namespace creation

Christian Grothoff — 2013-02-16T15:20:05

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


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.


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.


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.


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.


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

Namespace creation

LRN — 2013-02-16T12:50:14

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

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?). 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).

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.

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.
Anyway, from UI point of view it's more convenient to generate things,
since no dialogs need to be shown.
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRH4CFAAoJEOs4Jb6SI2CwmnMH/1Q41PvAI9YTZ9RMSiqcLj5h
e8yB3kUkWM8V+OSFGg+FyS48z5+x3Wlyo9HCsPFTw591jHN4JFs/7cj7pHkP55Ns
Bj62PPtuEab2ZmZTTkbQ0FPuqO0lswFaNe+PoE5DkZXHu6rL93CDlFsH8z/LtIBc
2oYLD8VyHQrni5IOC4C3rnnKo7jf/ce54lvTLCGthw5S2usstL+P7d/Kn3ki4NHF
K6SESKe5msNNw4Pr5gyh+KMFW2j5ZJTgkyizvUz28RTW48TPLFvrruvPUGdWH6jj
D2tiVZGS7dvE9Muv3j3eITfM3qxusfbs6uSqK3HVnqtTu4aiV8vilH7ojUzL76w=
=Zc1+
-----END PGP SIGNATURE-----

Re: gnunet-java classloader issue

Christian Grothoff — 2013-02-09T18:21:43

Fixed as suggested in SVN 26059. -Christian

On 02/09/2013 12:14 PM, Smoratinos wrote:


_______________________________________________
GNUnet-developers mailing list
GNUnet-developers< at >gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

gnunet-java classloader issue

Smoratinos — 2013-02-09T11:14:16

Hello,

SVN revision 25955 fix a classloading issue from the Runabout class, but
there is the same problem with the MessageLoader class

Here is a patch : 

Index: src/org/gnunet/construct/MessageLoader.java
===================================================================
--- src/org/gnunet/construct/MessageLoader.java(révision 26052)
+++ src/org/gnunet/construct/MessageLoader.java(copie de travail)
< at >< at > -159,7 +159,7 < at >< at >
 
     < at >SuppressWarnings("unchecked")
     private static Class<? extends MessageUnion> loadClass(String
className) {
-        ClassLoader cl = ClassLoader.getSystemClassLoader();
+        ClassLoader cl =
Thread.currentThread().getContextClassLoader();
         Class<MessageUnion> msgClass;
         try {
             msgClass = (Class<MessageUnion>) cl.loadClass(className);


#############
This patch is needed by the GNUnetWebUI app.
https://gnunet.org/bugs/view.php?id=2769

Thank you


_______________________________________________
GNUnet-developers mailing list
GNUnet-developers< at >gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers