List of nodes

[grarpamp]

Users will need nodes to test with.
Are there any nodes out there?
What are their addresses, ports and keys?
People that are running nodes could post them here.
Maybe Magnus can collate them, create and maintain a seed file for
a while in his /phantom/ distribution dir?
Maybe only one stable node is needed and it goes DHT from there?

Also, in the kadnodes.list file, what makes up the binary blob at
the start of each entry? Doesn't Phantom manage that file?
Etc... still reading.

[spjsschl]

Hi,

> Users will need nodes to test with.
> Are there any nodes out there?

Not that I know of, it is anyways not ready for any users. developers
maybe but I think it is more appropriate right now to run it on
virtual
machines in a controlled environment.

> What are their addresses, ports and keys?
> People that are running nodes could post them here.
> Maybe Magnus can collate them, create and maintain a seed file for
> a while in his /phantom/ distribution dir?
> Maybe only one stable node is needed and it goes DHT from there?

In theory, yes. In practice I have never tried if this works.

> Also, in the kadnodes.list file, what makes up the binary blob at
> the start of each entry? Doesn't Phantom manage that file?

the binary blob at the start of each entry is the nodes kademlia id,
the SHA-1 hash of is certificate iirc. You should get the file format
from
looking at kad_contacts.c.

Phantom does in theory manage that file. for my testing purposes
however
I went with static files that are not rewritten by phantom's kademlia
module.
That made for faster DHT bootup.
Johannes

[Johannes Schlumberger]

Hi,
forgive the horrible layout and spelling mistakes in my previous message. The
google interface did not do too good a job with line breaking and there was no
spell checker it seems.
Johannes

[grarpamp]

> not ready for any users. developers maybe

> more appropriate right now to run it on virtual
> machines in a controlled environment.

>> Maybe only one stable node is needed and it goes DHT from there?
> In theory, yes. In practice I have never tried if this works.

Of course, on all these things. Was thinking of having
an auxiliary node around to pingpong across the net.

> the binary blob at the start of each entry is the nodes kademlia id,
> the SHA-1 hash of is certificate iirc. You should get the file format

> from looking at kad_contacts.c ... static files.

I'd previously concatenated the IP line, cc and pbc keys. Only
that was remaining. With your note (thanks)...

head -1 test/faui00c-kadnodes.list | tr -d '\n' | bin2hex
73c2eedd76b081b3f6a948a6d455990e6d20d7c0
sha1 test/*pem | grep 73c2eedd76b081b3f6a948a6d455990e6d20d7c0
SHA1 (test/faui00m-cc.pem) = 73c2eedd76b081b3f6a948a6d455990e6d20d7c0
[snip]

... hex2bin will do the trick now. Maybe that file should remain
entirely plaintext for human init and debug, right? Binary only
saves 20 bytes and conversion cost is moot. The code could
keep any binary representation it needs in core.

[Johannes Schlumberger]

Hey,

> > the binary blob at the start of each entry is the nodes kademlia id,
> > the SHA-1 hash of is certificate iirc. You should get the file format
> > from looking at kad_contacts.c ... static files.

> ... hex2bin will do the trick now. Maybe that file should remain

> entirely plaintext for human init and debug, right? Binary only
> saves 20 bytes and conversion cost is moot. The code could
> keep any binary representation it needs in core.

Yes, that is not a problem. Dumping the binary without converting it to and from
a human readable format was just easier at that stage.
Johannes