[GNUnet-SVN] r30053 - gnunet-java

[gnunet]

Author: grothoff
Date: 2013-10-09 15:53:08 +0200 (Wed, 09 Oct 2013)
New Revision: 30053

Modified:
   gnunet-java/ISSUES
Log:
-comments

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-10-09 12:50:15 UTC (rev 30052)
+++ gnunet-java/ISSUES  2013-10-09 13:53:08 UTC (rev 30053)
@@ -1,4 +1,5 @@
 I noticed that GNUnet is changing to xdg, what does that change for 
gnunet-java?
+ => $-expansion in configuration...
 
 testbed api is now quite complete
  * problem with reconfigure was a bug in the testbed service
@@ -17,26 +18,29 @@
 
 timing information in ballot: we talked about round times,
 but shouldn't this be done transparently by consensus?
-aren't START_TIME, CLOSING_TIME, QUERY_TIME, END_TIME and maybe 
CONSENSUS_PARAMS be enough?
+aren't START_TIME, CLOSING_TIME, CONSENSUS_CONCLUDE_TIME, QUERY_TIME, END_TIME 
and maybe CONSENSUS_PARAMS be enough?
 
 certificate authority: is the CAs pubkey different from its peer?
  * it definitely makes sense to have it seperate for other cert methods
   * like sending a cert per email, snail mail, social network ...
  * how do we specify how to reach the cert? one peer? multiple peers?
-  * maybe use GADS? (I know very little about GADS right now)
- * does it even make sense to have the CA service at this time?
+  * maybe use GNS? (I know very little about GNS right now)
+ * does it even make sense to have the CA service at this time? No.
 
 what now works:
  * authorities check for double vote submission, late / early voting, early 
result query,
    double registering, vouchers (I don't like to call vouchers receipts 
because that term has
-   a certain meaning in voting literature already)
+   a certain meaning in voting literature already)     confirmation(s)?
 
 but: group certs are not checked right now
 
 how to test voting without waiting too long or missing the right time?
+ => make the code run fast, so your sleeps on the pi.net.in.tum. can still be 
small... (good luck with that)
 
 any progress on crypto?
  * luckily the private key has the same size, so identity can be used
+  => will have ECDSA Sign Keys, and EdDSA sign keys (and matching private key 
structs)
+  => Note: ECDSA with RFC 6979 over Curve25519 (Egos); and Ed25519 separately 
(PeerIdentity)
 
 next:
  * use identity
@@ -45,4 +49,4 @@
  * encrypting votes
 
 suggestions?
-
+* new crypto! fun! (wait for C change to drop)