protocol stabilizing areas #19

Closed
quartzjer opened this Issue Jan 15, 2014 · 11 comments

3 participants

@quartzjer
telehash member

This is a thread to track which areas of the protocol need to be better defined / stabilized...

@quartzjer
telehash member

A documentation point: what is the logic to handle opens, the retransmits, changing keys, and handling the at timestamps.

@quartzjer
telehash member

The pull request for DHT handling, type:bucket: #18

@quartzjer
telehash member

The pull request for seek partials: #10

@quartzjer
telehash member

I'd like to add the sending-path information to the type:path packets (so the recipient knows what path the sender was sending to), this would replace getting the info implicitly from a type:seek see response (for yourself)

@quartzjer
telehash member

Standardize and document a common seeds.json format :)

@temas temas closed this Jan 15, 2014
@temas temas reopened this Jan 15, 2014
@jaytaph

Probably better and easier ways to bootstrap encrypted connections. Like fixed data to compare your output with. Could even be a test server or test DHT that returns debug info etc so it's easier to get the connectivity done

@temas
telehash member

seeds.json BER

@quartzjer
telehash member

From @fd, document what happens when one hashname has multiple instances.

@quartzjer
telehash member

Prototype and document better https://github.com/telehash/telehash.org/blob/master/ext_pool.md for use as secondary/app-specific DHTs (also from @fd).

@quartzjer
telehash member

Perhaps document how to do seek logic better? (via @dvanduzer)

@quartzjer
telehash member

Most of these have been addressed by #22 so I'm going to close this as a tracking thread, we'll be doing another review soon and start a new issue to track that.

@quartzjer quartzjer closed this Mar 31, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment