specs: identify inconsistencies in implementation

[rootulp]

Discussed offline with @evan-forbes and we need to do a pass of existing specs, identify inconsistencies, fix them, and then migrate specs to individual repos.

Inconsistencies

• PayForMessage -> MsgPayForData celestia-specs#211
• specs: the first share of a message contains a message length delimiter #728
• specs: increase number of reserved bytes to two #883

[evan-forbes]

I'm also ok with doing this as we move chunks into each repo. We can then examine and edit the specs in those PRs, which might even add more context and links to code.

[rootulp]

Option A:

1. Identify inconsistencies
2. Fix them in this repo
3. Move the updated specs to individual repos

Option B:

1. Move the specs to individual repos
2. Identify and fix inconsistencies in the PRs that move specs

I'm leaning towards Option A because I think that will lead to smaller, atomic PRs.

[adlerjohn]

I'm leaning towards option B since it's a forcing function. In the current repo, there aren't enough eyes paid to the specs since it's one step removed.

[liamsi]

I'm also more in favour of option B. Additionally to what John said, I believe that if the specs are closer to the actual code that, they would rather be maintained as well.

[rootulp]

Since we're going with Option B we no longer need this issue to identify inconsistencies.

[evan-forbes]

Since we're going with Option B we no longer need this issue to identify inconsistencies.

? I think we might afaiu. I believe @adlerjohn will copy over the portions of the spec that are relevant to the app sometime soon, and then we can identify and fix inconsistencies.

[evan-forbes]

This was a miscommunication on my part, but there was also option C, which was only discussed on slack

• copy over the relevant specs
• identify and fix portions of the spec as we find them

we still get atomic PRs

[rootulp]

I should've included Option C above but yes I'm on-board because then we still get atomic PRs in individual repos to fix specs. Given Option C, we'll likely want a unique "Identify inconsistencies between specs and implementation" issue per repo where specs are migrated to.

[evan-forbes]

I'm leaning towards option B since it's a forcing function. In the current repo, there aren't enough eyes paid to the specs since it's one step removed.

I'll still obvi defer to the author on this. Regardless of what we pick, we'll likely be doing C forever anywho

[adlerjohn]

Subsumed by #650