Get the Namecoin daemon merged about consensusj HOT 15 CLOSED

Funny you should send this now. I've been thinking about the focus of this project and how to name, structure, and position it going forward. My original intention was to contribute it (or major parts of it) to the bitcoinj project. But bitcoinj is focused solely on Bitcoin and this project already is being used in and/or has components implemented for Bitcoin, Omni, Namecoin, and Ethereum.

Yesterday I was thinking about creating a new Github organization for the project and name it jCrypto or something similar that covers multiple currencies/chains. The goal would be to create reusable components that could be used by as many projects as possible and -- of perhaps greater importance -- attract as many contributions and contributors as possible. Maybe we could even merge in libdohj. I'd love to hear your thoughts on this.

Although, for this immediate issue of merging your code, we can certainly do it right here in this repository.

My suggestion would be to create a new submodule, called namecoin-daemon (or similar) for your daemon. bitcoinj-daemon is only 4 classes (a main Application class, and 3 configuration classes) so the namecoin-daemon could just have its own version of these files. The rest of the Namecoin functionality could be put in one or more Namecoin submodules. Any changes to the existing classes that you need can be addressed on a case-by-case basis, but I'm sure we'll be able to figure out how to create a nice, clean, modern OO architecture to maximize reusability and flexibility. And, yes, I should probably take another look at libdohj to refresh my memory.

from consensusj.

See also #8 and #14.

from consensusj.

from consensusj.

Both of these changes sound reasonable. I've already dabbled a bit with (1). For (2) it might be better to use Java interfaces than subclassing and I think we should be able to make it work that way. I also think the Namecoin daemon should have it's own Gradle submodule that builds the final application.

I'm leaning towards renaming this project ConsensusJ, by the way...

from consensusj.

@msgilligan Is it okay for libdohj to be added as a dependency to the various existing submodules (so that non-Bitcoin network parameters can be used with them), or should extra submodules be added for this purpose?

from consensusj.

In general, I believe that modules should have as few dependencies as possible. In fact, the module structure is largely about keeping overall dependencies minimized (and avoiding optional dependencies)

Which modules would need libdohj and what extra modules would need to be created when we add that dependency?

from consensusj.

Which modules would need libdohj and what extra modules would need to be created when we add that dependency?

@msgilligan I think it would be whichever modules currently access the Bitcoin mainnet and/or testnet network parameter classes. Libdohj provides alternate network parameters for a few altcoins; I don't think anything else would need libdohj (besides the Namecoin name lookup client, which is out of scope for this question).

from consensusj.

@JeremyRand You see that we've moved the project to ConensusJ/consensusj -- would you like to be a contributor to/member of this new Github organization?

from consensusj.

@JeremyRand You see that we've moved the project to ConensusJ/consensusj -- would you like to be a contributor to/member of this new Github organization?

@msgilligan Sure, sounds good to me.

from consensusj.

So there's been some activity in bitcoinj that is related to this issue.

First @marvin-we created Issue bitcoinj/bitcoinj#1486 on bitcoinj, then he created a thread Create a separate library that contains those parts which are useful for other Blockchains on the mailing list, and finally he created a project https://github.com/marvin-we/crypto-core to explore the idea.

I respond on his thread and created an issue on the project requesting that we get the changes merged into bitcoinj -- if possible. I think that would ultimately be the best solution for everyone.

from consensusj.

In terms of short-term strategy (say, the next few months), does it make sense for me to just continue maintaining my Namecoin fork of ConsensusJ without upstreaming things until we have a clearer picture of how we want things to look long-term? NLnet Foundation is willing to fund me to do some work on my Namecoin fork of ConsensusJ, and one of the things they'd like to fund is for me to get it upstreamed to ConsensusJ. If that's not doable short-term, that's totally fine, I'll just redirect the funding for that particular item to other Namecoin work (we have some flexibility in choosing which things NLnet funds). Thoughts?

from consensusj.

I think there's a short-term solution to get it merged and we should pursue it.

Separately, it would be nice to see a longer-term solution that solves the deeper issues that @marvin-we and others would like to address.

from consensusj.

OK, we've made some progress on this issue as of: b086d9b
This is based on the wok from @JeremyRand 's PR: #40 -- even though that PR was not directly merged.

The next step (I think) is to get the needed libdohj libraries published to a public Maven repo. Right @JeremyRand ?

from consensusj.

To be more specific: once libdohj is in a public Maven repo (easiest is probably bintray) it should be a roughly 10 line PR.

from consensusj.

Since this is not currently a priority for @msgilligan or @JeremyRand (see #69 (comment)) I am going to close this issue.

If someone new decides they want to work on a Namecoin daemon, please feel free to open any issues for changes that are needed, etc.

from consensusj.