Page 1 of 3

Brainstorming: GUI for the rebased client

Posted: Fri Nov 28, 2014 10:05 am
by phelix
There will be no Qt GUI for the rebased client so we should create a separate GUI to do name ops etc.

I suggest we use a higher level language to do so, e.g. Python as a lot of other Namecoin stuff is written in it.

It would probably be most efficient to build on something existent... Maybe we could build on Electrum or Armory? What are the latest Armory efforts about, I assume they have nothing to do with name ops?

Or integrate in NMControl http GUI?

This Lib could be helpful (Electrum compatible): https://github.com/vbuterin/pybitcointools/

Re: Brainstorming: GUI for the rebased client

Posted: Fri Nov 28, 2014 10:30 am
by biolizard89
phelix wrote:There will be no Qt GUI for the rebased client so we should create a separate GUI to do name ops etc.

I suggest we use a higher level language to do so, e.g. Python as a lot of other Namecoin stuff is written in it.

It would probably be most efficient to build on something existent... Maybe we could build on Electrum or Armory? What are the latest Armory efforts about, I assume they have nothing to do with name ops?

Or integrate in NMControl http GUI?

This Lib could be helpful (Electrum compatible): https://github.com/vbuterin/pybitcointools/
Adding name scripts to Armory would probably not be very difficult once the Namecoin support is ready. There is a chance I could donate to such an effort. I think Ryan said he might be interested in working on it in a few weeks, if his work schedule permits.

I believe Electrum relies on libbitcoin, which does not currently support Namecoin, so it's not a great option.

I do strongly support building on existing GUI's; it's not Namecoin's job to build a general-purpose coin GUI.

Re: Brainstorming: GUI for the rebased client

Posted: Fri Nov 28, 2014 10:38 am
by domob
biolizard89 wrote:I do strongly support building on existing GUI's; it's not Namecoin's job to build a general-purpose coin GUI.
Fully agree. I also agree that a separate UI, building on top of the RPC interface, would be very cool. There's no reason why the UI should depend on a particular core implementation - it would be great to allow a choice like libcoin vs rebased client.

That said, it is not fully sure that I won't work on the rebased Qt UI. For core coin functionality, it should just work out of the box (it compiles but I haven't ever tested it). Maybe adding name support means just copy&pasting the old code. But it is a very low priority thing to do on my list.

Re: Brainstorming: GUI for the rebased client

Posted: Fri Nov 28, 2014 1:53 pm
by josephbisch
I like the idea of going with Python for the GUI, whether that is for a new GUI written specifically for Namecoin or using an existing GUI-based program like Electrum or Armory. It is news to me that Electrum uses libbitcoin. I read talk about using libbitcoin, but afaik that never happened.

The latest Armory efforts have been about Namecoin support without any Namecoin-specific transaction types. I had to start somewhere, so I decided to focus on the basics to get sending and receiving working. I think it is best to get the basic support merged first, so that there is less for the Armory devs to review before merging.

I haven't heard back from the Armory devs recently. I said, via a forum post, that they can start reviewing the code, but I don't think they have yet. I think I am almost done with the code except for URI stuff and tests. The thing that is holding me back is the tests. They are not working, but the rest of the code is. Let me know if you want me to elaborate on the tests and what is not working. If I could get the tests done, then I can ask the Armory devs via email to review the code.

I said I would be willing to help Ryan if he needed help adding name transactions to Armory. I could probably do it myself if he doesn't have the time.

I haven't asked the Armory devs yet if they would merge support for libcoin into Armory. So that is something to find out before making a decision about all this.

Re: Brainstorming: GUI for the rebased client

Posted: Fri Nov 28, 2014 2:00 pm
by virtual_master
domob wrote:
biolizard89 wrote:I do strongly support building on existing GUI's; it's not Namecoin's job to build a general-purpose coin GUI.
Fully agree. I also agree that a separate UI, building on top of the RPC interface, would be very cool. There's no reason why the UI should depend on a particular core implementation - it would be great to allow a choice like libcoin vs rebased client.
Yes. I agree. We should keep a high modularity and compatibility if possible so every namecoind rebase to be compatible with every future GUI.
Another important points would be security and privacy. Available and tested features in this area should be integrated, like HD wallet, offline and multisig transactions, coin control and stealth addresses. Of course this features could be added step by step so it would be useful if it is written in a higher language which already has this libraries, more programmers know it and has a higher collaborative character so that the project can be easier continued even if some core developers would quit.
I don't think the speed reduction and system resource requirement would be so high because of the GUI written in a higher language.

Namecoin already supports other coins with NameID and its up of the other coin users and developers to implement it.
Ufasoft has showed interest to implement in their multicoin wallet sending coins to an id/ and it is already in their todo list.
If this feature will have positive feedback than probably will be used in other wallets also.

Re: Brainstorming: GUI for the rebased client

Posted: Fri Nov 28, 2014 2:14 pm
by biolizard89
josephbisch wrote:I like the idea of going with Python for the GUI, whether that is for a new GUI written specifically for Namecoin or using an existing GUI-based program like Electrum or Armory. It is news to me that Electrum uses libbitcoin. I read talk about using libbitcoin, but afaik that never happened.
Hmm, a quick Startpage for "electrum libbitcoin" isn't returning much, so maybe I'm remembering wrong.
josephbisch wrote:The latest Armory efforts have been about Namecoin support without any Namecoin-specific transaction types. I had to start somewhere, so I decided to focus on the basics to get sending and receiving working. I think it is best to get the basic support merged first, so that there is less for the Armory devs to review before merging.

I haven't heard back from the Armory devs recently. I said, via a forum post, that they can start reviewing the code, but I don't think they have yet. I think I am almost done with the code except for URI stuff and tests. The thing that is holding me back is the tests. They are not working, but the rest of the code is. Let me know if you want me to elaborate on the tests and what is not working. If I could get the tests done, then I can ask the Armory devs via email to review the code.

I said I would be willing to help Ryan if he needed help adding name transactions to Armory. I could probably do it myself if he doesn't have the time.

I haven't asked the Armory devs yet if they would merge support for libcoin into Armory. So that is something to find out before making a decision about all this.
libcoin support would be potentially difficult, given that libcoin stores the blockchain in a SQLite database rather than the serialized format that bitcoind uses. That said, my opinion is that getting Armory working with the standard Namecoin client is more important than worrying about libcoin compatibility (although libcoin support would be cool).

Re: Brainstorming: GUI for the rebased client

Posted: Sun Mar 01, 2015 2:02 pm
by phelix
I would like to reopen this discussion.

Please correct me if I am wrong as I have never really used armory, but is armory not even heavier than bitcoind/namecoind? If I understand correctly it parses all block data itself.

What I would have in mind would be a lightweight RPC frontend that would either use bitcoind/namecoind wallet features directly or Electrum/PyBitcointools HD addresses combined with watch only addresses in bitcoind/namecoind.

Re: Brainstorming: GUI for the rebased client

Posted: Sun Mar 01, 2015 2:08 pm
by biolizard89
phelix wrote:I would like to reopen this discussion.

Please correct me if I am wrong as I have never really used armory, but is armory not even heavier than bitcoind/namecoind? If I understand correctly it parses all block data itself.

What I would have in mind would be a lightweight RPC frontend that would either use bitcoind/namecoind wallet features directly or Electrum/PyBitcointools HD addresses combined with watch only addresses in bitcoind/namecoind.
Armory is a little bit heavier than Bitcoin-Qt, although I believe the next release of Armory will improve this a lot. I think Armory is a good fit for Namecoin, but it certainly doesn't have to be the only Bitcoin GUI ported to Namecoin. Joseph is looking at porting Multibit, and I think there's an Electrum port in development too. What I am against is developing customs UI's from scratch specifically for Namecoin -- I think cryptocurrency GUI's are the realm of Bitcoin development. We don't have enough development resources to be doing that, and such work should benefit Bitcoin and all of its forks, not just us.

Re: Brainstorming: GUI for the rebased client

Posted: Sun Mar 01, 2015 3:09 pm
by josephbisch
Armory uses more disk space than what is used when you just run Bitcoin Core, because all the blocks are read from the raw files on disk and a database is built for Armory to use.

See this code. The beginning has two enums ARMORY_DB_TYPE and DB_PRUNE_TYPE. I believe ARMORY_DB_FULL is the default and the supernode mode is also implemented. It would appear that they are planning on lighter modes in the future, like ARMORY_DB_LITE.

Certainly now isn't a good time to be using Armory if you want something with a light footprint. It runs bitcoind in the background, since Armory doesn't handle any of the network communication with the Bitcoin network itself. So you are using the same resources as bitcoind by itself, plus the resources used by Armory itself.

Re: Brainstorming: GUI for the rebased client

Posted: Mon Mar 02, 2015 6:10 am
by biolizard89
josephbisch wrote:Armory uses more disk space than what is used when you just run Bitcoin Core, because all the blocks are read from the raw files on disk and a database is built for Armory to use.

See this code. The beginning has two enums ARMORY_DB_TYPE and DB_PRUNE_TYPE. I believe ARMORY_DB_FULL is the default and the supernode mode is also implemented. It would appear that they are planning on lighter modes in the future, like ARMORY_DB_LITE.

Certainly now isn't a good time to be using Armory if you want something with a light footprint. It runs bitcoind in the background, since Armory doesn't handle any of the network communication with the Bitcoin network itself. So you are using the same resources as bitcoind by itself, plus the resources used by Armory itself.
The Armory devs mentioned on BitcoinTalk that a future release (I think the next one) will be able to shrink the databases massively -- something like under 100MB if I recall correctly. Unfortunately I don't have a link handy.