View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002010GNUnetpeerinfo servicepublic2011-12-13 20:102012-06-02 19:15
ReporterLRN Assigned ToLRN  
PrioritylowSeverityfeatureReproducibilityN/A
Status closedResolutionfixed 
Product Version0.9.0 
Target Version0.9.3Fixed in Version0.9.3 
Summary0002010: Be able to add HELLOs manually
DescriptionThere should be a way to give HELLOs (peer ID and addresses) to peerinfo by means other than inter-node gossip and hostlists. Preferably - encode HELLO into URI, and make it clickable. This will be a good supplement to hostlist-based bootstrapping.

P.S. Automatic outside-of-gnunet HELLO discovery and insertion can be done by a separate application that just connects to peerinfo and feeds data to it in a normal gnunetty fashion. That is, this is neither GUI-related, nor a task that can only be done by gnunet developers.
TagsNo tags attached.

Relationships

parent of 0002207 closedMatthias Wachs string_to_address API is unsupported 
parent of 0002209 closedMatthias Wachs string_to_address API is unsupported 

Activities

Christian Grothoff

2011-12-13 23:13

manager   ~0005093

I've put this into the appropriate category. HELLOs (and HELLO URI's) should be managed by gnunet-peerinfo (the command could take a serialized form of the HELLO and add it to the local database). As for generating our own HELLO's URI, that might fall to gnunet-transport or gnunet-peerinfo, I'm not 100% sure yet. For usability, I suspect gnunet-peerinfo would make most sense.

Christian Grothoff

2012-01-31 13:15

manager   ~0005412

The first thing we need to do is create a text-representation of a GNUnet HELLO message (which in its current binary form is not suitable for command-line manipulation). libgnunethello should be extended to be able to convert from and to the text representation from the internal binary representation.

Given that, we can then have gnunet-transport *output* our own HELLO (with the right command-line switch) in text-format and then feed it back into the system (presumably at a different peer) using gnunet-peerinfo.

LRN

2012-03-03 05:31

developer   ~0005558

GNUnet URIs are of the general form "gnunet://MODULE/IDENTIFIER".
The specific structure of "IDENTIFIER" depends on the module and
maybe differenciated into additional subcategories if applicable.
This module only deals with hello identifiers (MODULE = "hello").



The concrete URI format is:

"gnunet://hello/PEER[!YYYYMMDDHHNNSS!<TYPE>!<ADDRESS>]...".
These URIs can be used to add a peer record to peerinfo service.
PEER is the string representation of peer's public key.
YYYYMMDDHHNNSS is the expiration date.
TYPE is a transport type.
ADDRESS is the address, its format depends upon the transport type.
The concrete transport types and corresponding address formats are:



  • <TCP|UDP>!IPADDRESS
    IPVDDRESS is either IPV4 .-delimited address in form of XXX.XXX.XXX.XXX:PPPPP
    or IPV6 :-delimited address, but with '(' and ')' instead of '[' and ']' (RFC2396 advises against using square brackets in URIs):
    (XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX):PPPPP
    PPPPP is the port number. May be 0.



  • DNS!<DNS>:PPPPP
    DNS is a domain name that might map to an IPV4 or IPV6 or any other IP address.
    PPPPP is the port number. May be 0.



  • [add SMTP, HTTP and other addresses here]



The encoding for hexadecimal values is defined in the crypto_hash.c
module in the gnunetutil library and discussed there.

Examples:

gnunet://hello/0430205UC7D56PTQK8NV05776671CNN44FK4TL6D0GQ35OMF8MEN4RNMKA5UF6AL3DQO8B1SC5AQF50SQ2MABIRU4HC8H2HAJKJ59JL1JVRJAK308F9GASRFLMGUBB5TQ5AKR94AS5T3MDG8B9O1EMPRKB0HVCG7T6QPP4CDJ913LAEHVJ2DI1TOBB15Q1JIT5ARBOD12U4SIGRFDV3Q7T66G4TBVSJJ90UQF1BG29TGJJKLGEIMSPHHKO544D6EALQ4F2K0416311JC22GVAD48R616I7VK03K7MP7N0RS2MBV1TE9JV8CK1LSQMR7KCDRTLDA6917UGA67DHTGHERIACCGQ54TGSR48RMSGS9BA5HLMOKASFC1I6V4TT09TUGCU8GNDHQF0JF3H7LPV59UL5I38QID040G000!20120302010059!TCP!192.168.0.1:2086!TCP!64.23.8.174:0
gnunet://hello/0430205UC7D56PTQK8NV05776671CNN44FK4TL6D0GQ35OMF8MEN4RNMKA5UF6AL3DQO8B1SC5AQF50SQ2MABIRU4HC8H2HAJKJ59JL1JVRJAK308F9GASRFLMGUBB5TQ5AKR94AS5T3MDG8B9O1EMPRKB0HVCG7T6QPP4CDJ913LAEHVJ2DI1TOBB15Q1JIT5ARBOD12U4SIGRFDV3Q7T66G4TBVSJJ90UQF1BG29TGJJKLGEIMSPHHKO544D6EALQ4F2K0416311JC22GVAD48R616I7VK03K7MP7N0RS2MBV1TE9JV8CK1LSQMR7KCDRTLDA6917UGA67DHTGHERIACCGQ54TGSR48RMSGS9BA5HLMOKASFC1I6V4TT09TUGCU8GNDHQF0JF3H7LPV59UL5I38QID040G000!20120302010059!TCP!(2001:db8:85a3:8d3:1319:8a2e:370:7348):2086

Christian Grothoff

2012-03-24 16:11

manager   ~0005651

Isn't this now fully implemented?

LRN

2012-03-24 16:19

developer   ~0005652

Well, the code is beta-quality, and not all plugins implement the right functionality - but yes, i think it's implemented.

I actually have duplicate records in my peerinfo now, probably due to the fact that i've used the "put uri" functionality of peerinfo-tool.

Christian Grothoff

2012-03-24 17:56

manager   ~0005653

I don't see how the duplicate records can happen. I've linked the plugin-issues to this report now, to clarify that it's still open because of those sub-issues.

Christian Grothoff

2012-04-26 19:21

manager   ~0005753

Sub-issues were fixed, so this should be fully done now AFAIK.

Issue History

Date Modified Username Field Change
2011-12-13 20:10 LRN New Issue
2011-12-13 21:00 LRN Relationship added child of 0001966
2011-12-13 23:11 Christian Grothoff Project gnunet-gtk => GNUnet
2011-12-13 23:11 Christian Grothoff Category gnunet-fs-gtk => General
2011-12-13 23:13 Christian Grothoff Note Added: 0005093
2011-12-13 23:13 Christian Grothoff Status new => acknowledged
2011-12-13 23:13 Christian Grothoff Category General => peerinfo service
2011-12-13 23:13 Christian Grothoff Relationship deleted child of 0001966
2012-01-31 13:15 Christian Grothoff Note Added: 0005412
2012-02-21 21:54 Christian Grothoff Product Version => 0.9.0
2012-02-21 21:54 Christian Grothoff Target Version => 0.9.4
2012-03-03 05:31 LRN Note Added: 0005558
2012-03-05 01:47 Christian Grothoff Assigned To => LRN
2012-03-05 01:47 Christian Grothoff Status acknowledged => assigned
2012-03-24 16:11 Christian Grothoff Note Added: 0005651
2012-03-24 16:19 LRN Note Added: 0005652
2012-03-24 17:55 Christian Grothoff Relationship added parent of 0002207
2012-03-24 17:55 Christian Grothoff Relationship added parent of 0002209
2012-03-24 17:56 Christian Grothoff Note Added: 0005653
2012-04-26 19:21 Christian Grothoff Fixed in Version => 0.9.3
2012-04-26 19:21 Christian Grothoff Target Version 0.9.4 => 0.9.3
2012-04-26 19:21 Christian Grothoff Note Added: 0005753
2012-04-26 19:21 Christian Grothoff Status assigned => resolved
2012-04-26 19:21 Christian Grothoff Resolution open => fixed
2012-06-02 19:15 Christian Grothoff Status resolved => closed