P2P example for README?

[natevw]

I've gotten a bit stuck following the current README.

1. I generated an endpoint ("id") to play with, storing it to a file for reuse
2. I've instantiated a mesh and am logging it's link URI thing as the documentation does
3. (I've also found the currently-undocumented telehash.load helper that does the above for me)
4. Now what?

The documentation says I need a "router to assist" if I want to connect to a hashname.

I remembered that v2 used seeds and whatnot, but I don't see https://github.com/quartzjer/telehash-seeds/ as a dependency and passing that to telehash.load({id:"endpoint.json", links:"seeds.json"}) doesn't work as the links wants a CommonJS module rather than JSON [for starters]. I also see some hints that Telehash might be doing private meshes by default now, and/or that it's using blockname for DHT perhaps instead of seeds — but blockname's documentation makes it sound like it's a way to store backup DNS A records in Bitcoin so I'm a little lost down this path. What is a router, and do I need a Bitcoin wallet/client/??? to use Telehash in this way, but what does backup IPv4 host mappings have to do with Telehash hashnames and/or keys…?

Backing up to this README again, it looks like the other alternative is that I can connect directly, if I have endpoint/id-reminiscent information. Not sure about "paths" here though… I've already logged this URI thing as the first/only thing after instantiating(/starting?) my own mesh, so it seems important, but gets no further mention in the docs here. I guess I need the public keys from the file generated in step 1 above, and maybe the URI for paths? But paths is an {} instead of a [] so I'm not sure how I should pass it based on the docs.

---

This is as far as I've got today; and I'm guessing as I continue to UTSL in conjunction with the spec, things will gradually become clearer. But, while they were fresh, I wanted to document some things that were confusing to me and have slowed me down trying to play.

At this point, what I think would be helpful is if:

• the telehash.org page had a "getting started" link — perhaps I just did the wrong thing by using telehash-js and one of the other implementations is a better place to start? But telehash-js looked fairly recently updated and I've been doing a lot of node.js stuff lately, so it seemed a reasonable place to start
• this repo (if it is a good place to start) had a bit more fleshed out documentation, especially going to the point where a connection is made. I just checked and see now there is an examples directory, but the one example it has does a "same-process only" meshA.mesh(meshB) thing — at this point I have only a tentative understanding of what a Telehash mesh is in the abstract, or how its been encapsulated in this JS object I know have.
• there were something of a standard Telehash "blinky" or "Hello, World" kick-the-tires tutorial milestone, in common across projects and maybe even featured prominently on the homepage. I really didn't have clear goal (beyond understanding this system better) when setting down to do this; I guess I was hoping to get some sort of tracer bullet "send over here, some evidence of its receipt happens" type communications working. Is there a public "echo server" or "numbers station" somewhere, that I should aiming to access as a first step? Or should I be trying to connect two of my own processes together? Will that work regardless of where in the world each bit of telehash app code is, or does it need to be on the same LAN [the link:// URL contains only a network ip address] or what?

In short, how do I get to a point where I know Telehash is "working", and then what are my options for remixing things from that point?

[quartzjer]

These are excellent things to have documented as you experience them, thank you!!

I can't answer it all exhaustively here, but at least a few pointers to help move you along:

• blockname is still experimental and independent, not used by anything else in telehash (yet)
• all meshes are indeed private now, and "seed" is now called "router" and is private to each mesh (so there isn't any public ones)
• routers are only required to assist in p2p connectivity across different networks, and any endpoint can provide basic routing for others if enabled
• telehash.org is getting updated, and sorely needs it, as does the README and docs here, sorry for the rough edges!

[natevw]

Okay, I got something going:

var th = require('telehash'),
    fs = require('fs');


var ENDPOINT_FILE = process.env.ENDPOINT;


th.load({id:ENDPOINT_FILE}, function (e,mesh) {
  if (e) throw e;
  console.log(mesh.uri());

  if (process.env.LINK) {
    mesh.link(process.env.LINK);
    mesh.stream(function (from, args, accept){
      var chan = accept();
      chan.on('data', function (d) {
        d = d.toString();
        console.log("ECHO:", d);
        chan.write(d.toUpperCase());  
      });
    });
  }
  else mesh.accept = function (from) {
    console.log("INCOMING:", from.hashname);
    var link = mesh.link(from),
        chan = link.stream();
    chan.write("Hello?");
    var i = 0;
    setInterval(function () {
      chan.write("Test #"+(++i));
    }, 5e3);
    chan.on('data', function (d) {
      console.log("DATA:", d.toString());
    });
  };
});

Usage isn't particularly elegant, but not too bad either — I'm doing something like this:

## screen 1
ENDPOINT=test1.json node index
# … copy link URI into clipboard

## screen 2
ENDPOINT=test2.json LINK=`pbpaste` node index
# … should now log incoming strings, and those will echo back to screen 1 converted to all-caps

[NodeGuy]

Thanks for your code; it was helpful.

[lewisl9029]

Has anyone figured out how to hook up Telehash v3 with a public DHT?
I'm trying to upgrade a v2 project to v3 but I have no idea where to start with respect to the DHT functionality.

[cfvaughnii]

Are test1.json and test2.json like the links.json?

[natevw]

Sort of, but iirc the links.json you are referring to is live connection state (e.g. in case you need to restart your app/server but don't want to renegotiate routing/connections). The test1.json and test2.json are just the keys for each node. They don't actually store link state, just the various generated keypairs themselves.

[cfvaughnii]

I ran a modified copy of test_net_udp4.c and was able to get the mesh_add to show up on a remote machine running the router.js program. I get the message "2wxhqoe up" on the remote end. Now, I need to figure out why the link_up fails. I will probably run link_handshake or some other program that has ping support on the remote side.

[southbite]

@natevw - thanks so much for your code - it is the best example I could find so far to help me understand the protocol, a simple README/Getting started page would be great! but for now I guess I am going to have to read the whitepaper :)

[natevw]

@southbite I've actually written up a few page "explainer" overview on Telehash that's mostly waiting for a few (not super essential) diagrams that are still on my list. Don't know if @quartzjer has already published that somewhere or if he'd be comfortable with me publicly posting my draft to a personal gist/blog. (Note also that my draft hasn't been super thoroughly vetted for technical accuracy in every detail, but iirc the initial feedback I got was on track!)

[drasko]

@natevw any news on this paper? It would be great to have some introductory documentation on Telehash, some kind of step-by-step tutorial...

[stpeter]

It might make sense to wait until we finish the v4 refactor that Jer keeps talking about. :-)

[anhldbk]

@quartzjer Ping ping ping .... Still alive?

[RichardWeiYang]

Do we have an example on c library?