Namecoin Forum

I posted this after a LONG day. Corrections to grammar, etc. are appreciated.

We really need a protocol for proposing enhancements. I wanted to wait until I had time to create some custom thing that would capture discussion but this just made the perfect an enemy of the good:

• The edit-ability of the wiki makes it difficult for others to track down accurate standards and propose changes formally, with proposals and actual standards getting mixed up.
• Authors attempting to create a reference for a specific proposal generally turn to a combination of forum, wiki, or blog posts. While this might be useful for initially developing an idea, it's hard for others to propose changes and for those changes to get incorporated into the proposal.

Name

Sorry, we can't call it a NIP:

Urban Dictionary wrote:A Japanese person (derogatory, from Nippon, the Japanese word for Japan)
#1 with >1,000 votes

Structure & Format

Bitcoin uses a bip repo with a simple directory structure consisting of a "readme.md" that manually links to each BIP file "bip-000#.mediawiki". BIPS store images and other accompanying files store in subdirectories named after the BIP "./bip-000#/image.png", but the file itself is always stored in the root directory.

BIP are stored in the Mediawiki format, a product of their legacy wiki. I propose that we instead use markdown directly. For more complex formatting, we could switch to Gollum, Gihub's wiki system that can be stored in the repo while still being accessible and editable through GitHub's wiki interface. However, unless Ademan or someone else is else wants to take on setting this up, let's start with basic markdown files and iterate from there.

Appending the title after the the numbering would be helpful: "nep-0002-d", "nep-0003-id", "nep-0004-name-ops".
Versioning

BIPS are numbered using an integer system. Withdrawn and replaced BIPs simply label the older BIP as withdrawn and add a new BIP.

UPDATE: I believe that since we have standards that naturally go through multiple revisions (namespaces, for example) we should adopt a versioning scheme. This would consist of adding a single line to the "header" of the document.
I'm unfamiliar with Git's versioning options (i.e. tags vs hashes) and their accessibility through GitHub's web UI and linking. Experts, please discuss.

Process

BIP-0001 lays out the types of BIPS, formatting, and a workflow. We can largely copy it, making adjustments for Markdown formatting.

Their workflow is essentially: I would suggest the the same basic workflow, but replacing it with forums and Git PR instead: Those with push access to the NEP repo would handle the editing bit, with git comments limited to discussion of formatting and compliance with review process, not technical merits (unless of course it was rejected on technical merits earlier in the review process). Consensus does not need not be reached before accepting a proposal.

The NEP should link to a forum thread for discussion with the OP consisting of the NEP. When to create a new thread (vs updating the OP to match a new draft) should be left to the author. Older draft threads should probably be listed in the subsection of the "see also" section.

This seems reasonable to me. Bitcoin's setup seems to work pretty well, I don't see any reason to try to further optimize it.

We are way smaller than Bitcoin. At the current status imho this would slow development down to a grinding halt.

Just take a look at the changelog and imagine all this going through the nep... or is it only relevant for people from the outside? Still I don't think it's necessary. For any improvement proposal people should just create an issue or forum post.

phelix wrote:We are way smaller than Bitcoin. At the current status imho this would slow development down to a grinding halt.

Could you please cut the hyperbole?

phelix wrote: Just take a look at the changelog and imagine all this going through the nep... or is it only relevant for people from the outside? Still I don't think it's necessary. For any improvement proposal people should just create an issue or forum post.

This is just a reference, everything will go through the forum as it already does but it gets codified at the end so others can look things up. The reason I'm proposing this is because I've been having trouble tracking the evolution of different proposals and specs. Ideas and changes get spread all over the place and there is no single "working" draft. This would make development easier.

The wiki is a shit-show because of the bolted-on permissions system. People have been going in and creating proposed standards that LOOK like the real deal but are incorrect. This would enable us to give a final stamp of approval on standards as they are implemented.

I think such a process could be useful to track larger proposals in discussion (for instance, floating fees or name permissions). It should not be necessary to apply it to every small change, though (like the ones on the change list) - there a pull request and maybe a small forum discussion should be enough.

Does that sound like a good compromise?

Oh shit, I'm sorry Phelix,

Just take a look at the changelog and imagine all this going through the nep... or is it only relevant for people from the outside? Still I don't think it's necessary. For any improvement proposal people should just create an issue or forum post.

I've been so knee-deep in editing Wikipedia articles I thought you were referring to the change log for entries in the wiki. I absolutely do not think that NEP's should define every minor change to the software. This would only be for big stuff.

domob wrote:It should not be necessary to apply it to every small change, though (like the ones on the change list) - there a pull request and maybe a small forum discussion should be enough.

Does that sound like a good compromise?

Yes, exactly. From the ~50 lines of the last change log, the only changes that might need to be included are:

• Set default fee per kb to 0.005NMC (phelix)
• Relay transaction size limited to 20kb (consensus/phelix)
• Increased network relay fee MIN_RELAY_TX_FEE to 100000

None of these should have require more than a single PR request and perfunctory audit by the editors.

I think documentation of the API should be done using auto-generated documentation. The vast majority of API calls should not be defined in some codified spec.

Authors of proposals can update the draft proposal as often as they care to. After a proposal has become a specification, it really shouldn't change unless the implementation changes.

Furthermore, I tried to stick as close as possible to our current process of using the forum for early feedback and iterations.

indolering wrote:the ~50 lines of the last change log, the only changes that might need to be included are:

• Set default fee per kb to 0.005NMC (phelix)
• Relay transaction size limited to 20kb (consensus/phelix)
• Increased network relay fee MIN_RELAY_TX_FEE to 100000

So, I checked Bitcoin's BIPs and I didn't find any of the above items specified there. So, from the 50 lines of the latest change log, none of them would need to be codified in an NEP.

biolizard89 wrote:This seems reasonable to me. Bitcoin's setup seems to work pretty well, I don't see any reason to try to further optimize it.

Based on our IRC discussion, I'm going to assume you're mainly referring to the versioning system. I think we need a versioning system because a lot of our specs naturally go through multiple versions. For example, changes to the d and id namespaces would require entirely new proposals. Adding versioning would only require adding a single line to the "header" of the document:

Doesn't BIP just use new BIP numbers for new versions?