Namecoin Forum

phelix wrote:Just a quick thought: AFAIK there is no GUI with libcoin. What about modifying and using the Electrum client?

Elektrum is a great client, the best after the Satoshi client and I use it also. I like that it has deterministic key generation and offline transaction support also.
But I don't think that it is suited for the rebase of Namecoin as basis client. At least not how it is used by Bitcoin, with external blockchain.
However if you mind just as GUI part which connects to namecoind(rebased) that could be an interesting option if it could connect to a local namecoind or alternatively if you choose to some remote servers(like the Bitcoin Elektrum).
I think Elektrum as it is now cannot connect to bitcoind directly only if you made specially available as service through the internet.

virtual_master wrote:

phelix wrote:Just a quick thought: AFAIK there is no GUI with libcoin. What about modifying and using the Electrum client?

Elektrum is a great client, the best after the Satoshi client and I use it also. I like that it has deterministic key generation and offline transaction support also.
But I don't think that it is suited for the rebase of Namecoin as basis client. At least not how it is used by Bitcoin, with external blockchain.
However if you mind just as GUI part which connects to namecoind(rebased) that could be an interesting option if it could connect to a local namecoind or alternatively if you choose to some remote servers(like the Bitcoin Elektrum).
I think Elektrum as it is now cannot connect to bitcoind directly only if you made specially available as service through the internet.

This is what I have in mind. We would have to replace the interface code to the server with an rpc interface. Some operations would take a long time because the whole blockchain would have to be rescanned (what the electrum server database is used for normally).

Maybe there is a better candidate but I like Electrum, too, and it is in Python. Obviously we would have to extend it with a "name tab".

virtual_master wrote: But I don't think that it is suited for the rebase of Namecoin as basis client. At least not how it is used by Bitcoin, with external blockchain.
However if you mind just as GUI part which connects to namecoind(rebased) that could be an interesting option if it could connect to a local namecoind or alternatively if you choose to some remote servers(like the Bitcoin Elektrum).

Isn't the whole point of Electrum is that it doesn't interact with the blockchain directly? If we are talking about a client which manages the local blockchain, we would basically have to rip out most of Electrums backend.

I'm struggling to see where this conversation is going. I think it would best be split off into the bounty area.

If we are talking about bounties, then it should just be a functional spec. Deciding which client and what programming language is a really good way to shut down potential contributors: the only thing that matters is running code.

indolering wrote: Isn't the whole point of Electrum is that it doesn't interact with the blockchain directly? If we are talking about a client which manages the local blockchain, we would basically have to rip out most of Electrums backend.

Except that isn't at ALL what we want, we want a lightweight GUI that operates over an RPC interface. Derp.

Any idea of how it communicates with the Bitcoin backend?

Took a glance at the Electrum code and I am not so sure any more it can be easily adapted to libcoin.

What about the old NamecoinJ? http://forum.namecoin.info/viewtopic.php?f=9&t=379 I'm certainly not into Java but it looks like a good start.

phelix wrote:Took a glance at the Electrum code and I am not so sure any more it can be easily adapted to libcoin.

What about the old NamecoinJ? http://forum.namecoin.info/viewtopic.php?f=9&t=379 I'm certainly not into Java but it looks like a good start.

It's not a bad idea, but I still think the easiest route would be an HTML/CSS/JS stack. There are already a few HTML5 wallets, a moderate bounty would probably be enough to get them to port it over.

If my Haxe libraries work out, there are multiple front-end frameworks that compile to HTML5 as well as native clients.

indolering wrote: Isn't the whole point of Electrum is that it doesn't interact with the blockchain directly? If we are talking about a client which manages the local blockchain, we would basically have to rip out most of Electrums backend.

Elektrum is great but but not at this stage of development.

1. First we need a rebase for namecoind.
2. Second we need an easy GUI built on namecoind:
- a. we could take the (I think Snailbrains) old GUI and adapt it or make something similar
- b. we can make a local webserver and PHP based GUI which interacts with namecoind on RPC level

Namecoind rebase and the GUI development could go parallel when the new namecoind uses the same RPC comands as the actual one. If there will be few additional commands then it could be enhanced with them later.

virtual_master wrote: - a. we could take the (I think Snailbrains) old GUI and adapt it or make something similar
- b. we can make a local webserver and PHP based GUI which interacts with namecoind on RPC level

Namecoind rebase and the GUI development could go parallel when the new namecoind uses the same RPC comands as the actual one. If there will be few additional commands then it could be enhanced with them later.

I am unfamiliar with the old codebase and how portable it is, but I think using RPC calls are the way to go : )

Have you looked into the the PHP wallets out there?

indolering wrote: I am unfamiliar with the old codebase and how portable it is, but I think using RPC calls are the way to go : )

Have you looked into the the PHP wallets out there?

Not in detail. But this one for example is a PHP wallet using RPC commands and designed to support more cryptocurrencies :
https://github.com/zelles/WalletScript
However must be enhanced with Namecoin specific issues.

A TK based GUI would be also very lightweight, cross-platform and stable build.
Perl/Tk, Python/Tk, Ruby/Tk could be used. Perl, Python and Ruby all have RPC libraries.
They are some examples here how to use them with bitcoind:
https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29
Here is a Tcl/Tk GUI wallet which can connect to bitcoind locally or remote:
https://github.com/avl42/

indolering wrote:

biolizard89 wrote:
If indolering's issue with local clients is that they don't auto-renew, that's fixable. I haven't heard any other complaints about local clients.

My issue with local clients is that there is no recourse for non-technical users who screw up and are unable to renew their domain, due to lost keys, forgetting to renew, trashing their computer, etc. Registrars provide a valuable service for the 99% of people who don't need to worry about the government coming after their domain.

Lost keys and trashed computers are dealt with via paper backups, which Armory supports. That's a major reason I'd like to use Armory for Namecoin (along with the fact that it has a really nice GUI).

Forgetting to renew can be dealt with by trust-free delegated renewal, for which Ryan, Luke, and I came up with a proposal.

Relying on trusting a registrar is extremely unwise. It's not just the government that's the problem -- a large registrar is a juicy target for attackers, and the registrar operators themselves might be evil.

@phelix, Electrum uses libbitcoin; it's going to be extremely hard to use it for Namecoin unless we port libbitcoin. Also, Electrum's security properties are extremely sucky for name purposes... it's worse than using it for currency purposes.

@indolering, I'm pretty strongly against re-inventing another GUI. I think we should use an existing GUI if at all possible. Also, a web-browser-based GUI has immense attack surface compared to something like Armory.