Namecoin Forum

We all agree that we should use a way to get a GUI for namecore that takes as little effort as possible (at a reasonable outcome).

I image it to be relatively difficult to add name_ops to Armory. Maybe it would be easier to create a light weight RPC GUI front end. Cassini suggested using a HTTP GUI (imho a normal GUI is slightly more confidence inspiring).

I will take a closer look at these:
http://chromawallet.com/
http://tcatm.github.io/bitcoin-js-remote/

phelix wrote:We all agree that we should use a way to get a GUI for namecore that takes as little effort as possible (at a reasonable outcome).

I image it to be relatively difficult to add name_ops to Armory. Maybe it would be easier to create a light weight RPC GUI front end. Cassini suggested using a HTTP GUI (imho a normal GUI is slightly more confidence inspiring).

I will take a closer look at these:
http://chromawallet.com/
http://tcatm.github.io/bitcoin-js-remote/

I can't speak myself to the difficulty of adding name ops to Armory, but Ryan didn't seem to think it would be very hard (I believe based on comments on GitHub and/or IRC).

phelix wrote:http://tcatm.github.io/bitcoin-js-remote/

This looks very promising. Latest commit occurred 14 months ago, though. However, the dev is still quite active at github. Currently busy with meshnet.
It shouldn't be too difficult for him or any other developer proficient in JavaScript to fork bitcoin-js-remote and add name-related features.

Recently domob and I discussed this issue and (I think domob) came up with a new idea:

* Use the rebranded Bitcoin-Qt GUI for everything currency related
* Create a separate GUI only for name_ops

This has some advantages:
* we get all features from Bitcoin, e.g. coincontrol
* differences between Bitcoin and Namecore are kept at a minimum
* we only need to implement a minimal new GUI frontend for name_ops and can focus all efforts on this
* we can easily add new features to the name-GUI

IMHO separating the name_ops is quite a clear cut. The name-GUI could be integrated into NMControl. The only thing missing is coin control for name_ops but I don't see any other option with this feature.

phelix wrote:Recently domob and I discussed this issue and (I think domob) came up with a new idea:

* Use the rebranded Bitcoin-Qt GUI for everything currency related
* Create a separate GUI only for name_ops

This has some advantages:
* we get all features from Bitcoin, e.g. coincontrol
* differences between Bitcoin and Namecore are kept at a minimum
* we only need to implement a minimal new GUI frontend for name_ops and can focus all efforts on this
* we can easily add new features to the name-GUI

IMHO separating the name_ops is quite a clear cut. The name-GUI could be integrated into NMControl. The only thing missing is coin control for name_ops but I don't see any other option with this feature.

Personally I don't think this makes sense from a usability perspective. End users probably want to receive NMC from the same UI that creates names by spending those NMC. I still think Armory makes more sense.

biolizard89 wrote:

phelix wrote:Recently domob and I discussed this issue and (I think domob) came up with a new idea:

* Use the rebranded Bitcoin-Qt GUI for everything currency related
* Create a separate GUI only for name_ops

This has some advantages:
* we get all features from Bitcoin, e.g. coincontrol
* differences between Bitcoin and Namecore are kept at a minimum
* we only need to implement a minimal new GUI frontend for name_ops and can focus all efforts on this
* we can easily add new features to the name-GUI

IMHO separating the name_ops is quite a clear cut. The name-GUI could be integrated into NMControl. The only thing missing is coin control for name_ops but I don't see any other option with this feature.

Personally I don't think this makes sense from a usability perspective. End users probably want to receive NMC from the same UI that creates names by spending those NMC. I still think Armory makes more sense.

This should be way easier. Also we could maybe design it in a modular way so that the nameGUI and Armory can share as much code as possible.

from the roadmap thread:

somename wrote:Related to Core GUI > Alternatives, you can take a look at github.com/CounterpartyXCP/counterparty-gui, it's a Python-based wrapper that can support several back ends (currently Bitcoin Core 0.10) and it is easily extensible via plugins. It can use a local or remote server.
It's built to be simple, which may be a good or bad thing depending on one's goals.

hmm...

IMHO namecontrol for name operations at least, it is namecontrol after all.

For Tx and Signing too if it's technically possible and secure. If not armory/multibit.

Other development avenue would be to create a lightweight client.

johnc wrote:IMHO namecontrol for name operations at least, it is namecontrol after all.

For Tx and Signing too if it's technically possible and secure. If not armory/multibit.

Other development avenue would be to create a lightweight client.

In terms of attack surface, I would rather than the application holding private keys be separate from the application looking up names. Armory fits that bill perfectly. Having NMControl (which may be renamed NameControl) hold keys as well as look up names would not be a good idea by this standard.

biolizard89 wrote:

johnc wrote:IMHO namecontrol for name operations at least, it is namecontrol after all.

For Tx and Signing too if it's technically possible and secure. If not armory/multibit.

Other development avenue would be to create a lightweight client.

In terms of attack surface, I would rather than the application holding private keys be separate from the application looking up names. Armory fits that bill perfectly. Having NMControl (which may be renamed NameControl) hold keys as well as look up names would not be a good idea by this standard.

No need for the name gui to hold keys.