This is just to record some general stylistic issues in the spec which bug me.
This list is undoubtedly incomplete.

• The pronoun for a peer is sometimes "him". Remind me which century this is?

• More often, it's "them", which isn't too bad, except that "themselves" is
  often used for a single peer, which is confusing. I would either use "it"
  for the peer, or use "themself".

• Tense and modality are used inconsistently - sometimes an implementation
  "will" do something, often it "does" it, and occasionally it "should" or
  "must" do it. We should decide whether this is describing the behaviour of
  current implementations, in which case present tense "does" seems best to
  me, or whether it is defining a conforming implementation, in which case use
  of "may", "should", and "must" as in RFCs would be appropriate.

• There should be a typographical convention for introducing a definition. I
  favour bold text, as in "A gostak is a distimmer of doshes".

• "group", "groupchat" and "group chat" are used interchangeably; we should
  replace them all with "conference".

Currently in hs-toxcore, and also in toktok/spec, a node is added to a bucket if it is closer to the public key of the DhtState than any node already in the bucket, evicting the most distant node if necessary.

However, this in not the behaviour of c-toxcore - add_to_close() replaces the first entry in the bucket which is empty or contains a node which has timed out, failing if there is no such entry.

This is closer to the "least recently seen" eviction policy of Kademlia, and generally makes much more sense.

For the search lists, c-toxcore is in agreement that nodes closer to the searched key are preferred, and of course for them it does make sense.

The original spec by irungentoo agrees with the c-toxcore implementation.

Hi! Currently, hs-toxcore has an almost empty README, making it hard to understand the status of hs-toxcore.

Could you please write "Work-in-Progress Haskell Tox implementation." or "Haskell Tox implementation (Alpha)" or something like that? If it's fully ready, then a small indication of that would also help readers a lot (I think)

Thanks for considering! Personally, I don't know myself, otherwise I'd write a PR.

GHC 7.8 is kind of old, a significant amount of the community and libraries I use have moved to 7.10.3. Does this work in 7.10.3?

Makes it easier to see what changed vs. master.

Currently we paste the generated spec.md to gist. We should paste the diff to master instead.