Worldcoin Business Center - Joint project?

Berzeck

Hello, my name is Mario Blacutt, I am the manger of worldcoin.global team.
Some months ago i came here with a proposal to join forces in some development areas, back at the time we didn’t have too much to show and without a clear idea on what exactly we were searching for … this has changed now with our new version series 2.x.x, so in order to expose my idea I will divide my post in 3 sections:

1] What we have
2] What we want
3] What we offer

Hands on!

1] What we have .- We have made a new software from scratch, the architecture is completely changed and our new software has a lot of benefits we didn’t hear in crypto world:

1.1] Refactored architecture.- Now there are 4 completely separated layers:
1.1.1] The Daemon.- This is the application that performs crypto related activities like signing, sending coins, etc. It is the same application that exchanges, pools, etc are using, extremely stable.
1.1.2] The Director.- This is another application written in c++ called WorldcoinPanel, it’s main objective is to translate, coordinate and send back an answer of requests from the UI to the appropriate component target.
1.1.3] Components.- All components are scripts. A lot easier to develop (low learning curve) and a lot simpler to deploy (no more compiling, c++ nor visual studio). Components are loaded by the Director
Check code of components deployed inside ‘Components’ subdirectory to get an idea
1.1.4] User Interface (UI).- All elements of the UI are made using scripts and are loaded by the Director. One side effect of this is that we have an extremely powerful theme engine.

1.2] Custom components.- People and companies are able to develop their own components using scripts, these are fairly resistant to changes if wallet needs upgrading

1.3] Development framework.- Special functions and objects are being built specifically for WDC to simplify even more third party development process

1.4] Video card acceleration.- WBC tries to use video card to render all graphics removing the burden of rendering from the CPU.

1.5] Wapptoms.- These are basic units of crypto information and stand for ‘WDC Application Atom’, like Price, Difficulty, Hash Rate, etc. You can use these objects as simple variables in your custom components without worrying about implementation details (like network connections, syntax and other annoyances)

1.6] Theme engine.- WBC allows four levels of visual customization using scripts

Changing colors, sizes.
Changing images.
Layout management.
Advanced scripting
Check UI inside ‘WFUserInterface’ folder
Designers could have a direct role in development

1.7] Resolution independence.- Sizes are expressed in centimeters rather than pixels, so WBC will look more or less the same in monitors with different resolutions and DPI’s

1.8] Scaling.- When WBC is running, pressing Ctrl + rotating mouse wheel will scale up or down the wallet, this is possible because graphics are rendered by the video card instead of the cpu.

1.9] Automatic upgrade.- WBC is able to alert the user if a new version is released and the user can load the ‘Updater’ component, check out things that were changed and decide if he decides to go trough the process he only needs to click ‘Ok’ and WBC will do the rest (Including making a backup before the process starts)

In order to measure the efficiency of our new framework , i made a blog post with this goal in mind:

Develop a component which retrieves the last transactions from the wallet, converts them to american dollars and calculates the VAT according to a predefined parameter. Also we want to refresh automatically the transaction list whenever the exchange rate changes.

Ask yourselves how much time (including compiling and deploying) would take this requirement in the current architecture.
With our architecture it took 70 lines of scripted code and 20 minutes of development. ( the blog took 2 hours to write)

Hence we changed the ‘wallet’ term to Worldcoin Business Center, where the wallet is just a single module (we have just 2 modules developed right now)

Screenshot 1
Screenshot 1

2] What we want
a] Join forces to continue WBC development with more developers
b] Coordinate and co develop daemon re basing from last ltc/btc wallets

3] What we offer
As the design separates completely the daemon from the UI, it would be relatively easy to make a port for FTC and use your branding.
a] Guidelines on how to achieve port using our code
b] Support in that process

So what do you guys think?

PD: My cpu usage goes to the roof when using this site. Does anybody experience the same thing? Using Linux OpenSuse Leap 42.1

lizhi

Hi Mario Blacutt , I see your point.Thank you for your advice. We’ll consider your proposal.
Now, our development is still based on bitcoin.

mirrax

@Berzeck Hi, i see this as another attempt to parasite on our brand. I say go away.

Berzeck

What do you mean with parasite your brand? the whole point is that the wallet is easily rebrandable.
Besides do you honestly believe that i am interested in FTC brand? if that’s the case wouldn’t it be more effective for me to go to ltc/btc or one of 40+ coins that has more brand recognition than yours? (or ours for that matter)
In your logic if BTC release version 0.12 and someone posts here about its benefits then you will say that they are parasites too? “hey guys we will re base to BTC 0.12 but shhhhh nobody can talk about it’s benefits in public”
No wonder why there a 600+ coins with 600+ developers

Berzeck

@lizhi said:

Hi Mario Blacutt , I see your point.Thank you for your advice. We’ll consider your proposal.
Now, our development is still based on bitcoin.

Thanks for your response. Let me know when you decide something.

Berzeck

This post is deleted!

Wellenreiter

@Berzeck

Sounds inteeresting. We will look into it.

Without knowing your code, I already have some questions.

Did you write your new code from scratch?
Did you fork some BTC/LTC code?
- if Yes, which version?
how flexible is your code?
- can it adapt to uncommon behavior of a blockchain?
  1. We changed mean time to block from 2.5 mins to 1 min
  2. We changed the number of coins mined per block from 200 to 80
  3. We changed our Algorithm form Scrypt to Neoscrypt.
- all of the above requires special coding
can you provide a link to your latest code base?
- saves some searching ;)

Berzeck

@Wellenreiter said:

@Berzeck

Sounds inteeresting. We will look into it.

Without knowing your code, I already have some questions.

Did you write your new code from scratch?

Did you fork some BTC/LTC code?

if Yes, which version?

how flexible is your code?

can it adapt to uncommon behavior of a blockchain?

We changed mean time to block from 2.5 mins to 1 min

We changed the number of coins mined per block from 200 to 80

We changed our Algorithm form Scrypt to Neoscrypt.

all of the above requires special coding

can you provide a link to your latest code base?

saves some searching ;)

Thank you for your interest!
My answer below will cover all questions (hopefully):

The Business Center (WBC) is written in c++ (Qt) from scratch not a single line leeched from anywhere.
WBC translates requests from UI (users) to RPC API calls to the standard already developed and more stable daemon (another executable) and also to external services (like price in USD for example) . This means that the daemon is already written. In other words Business Center acts as a thick layer of abstraction between a daemon and the user. The idea is that users can make easily their own modules and components using this level of abstraction which is a lot easier to develop … no c++, everything is scripted, no risk of fucking up with core crypto functions, no need to understand how underlaying crypto works just common sense. In this way core functions (daemons) can progress a lot more slowly (because they need a lot more QA and testing) but WBC progress a lot faster with the ability to integrate many services and functions. As i put in my blog, it is very easy that each user/company scratches their own itches without depending on core developers.

Each daemon is implemented using 2 objects:

A c++ plugin. Which detail some particularities of the the specified daemon and acts as the bridge between WBC and the executable
A dictionary text file which lists specific RPC API calls for that daemon with their expected results which WBC would parse

In other words you don’t have to scrap all your code, just the current Qt part and develop the plugin for WBC to connect to it, also WBC is completely themable so you can use your branding as you please.

If you have some minutes to spare it would be very useful if you can download the wallet and read the blog which it is referred in my first post to understand what we consider one of our killer features.

Repo of WBC: https://github.com/WorldcoinGlobal/WorldcoinPanel (Build system is QBS not qmake because Qt guys said that they wont evolve it anymore, edit main .qbs file and change paths accordingly). It is tested with Linux and VS 2013 both 64 bits
Repo of WDC daemon: https://github.com/WorldcoinGlobal/WorldcoinDaemon

Speaking about rebasing (0.10.2) we can’t decide on two items so i wanted to consult you guys how you are dealing with them :
a] For future BTC rebasing (0.1x.x) how are you dealing with ACS (Advanced Checkpoint System)will you keep it? risks?
b] Do you consider that enforcing protocol v2 a good idea if you don’t have any idea if most nodes will upgrade?

We are not pushing our rebasing project because we want to maintain 100% compatibility with previous Qt wallet for some months at least. As it is a big change it will take longer for people to adopt than normal releases.

Wellenreiter

My answer below will cover all questions (hopefully):

The Business Center (WBC) is written in c++ (Qt) from scratch not a single line leeched from anywhere.
WBC translates requests from UI (users) to RPC API calls to the standard already developed and more stable daemon (another executable) and also to external services (like price in USD for example) . This means that the daemon is already written. In other words Business Center acts as a thick layer of abstraction between a daemon and the user.

Thank for the fast answer.

Actually I was thinking along the same line.
Why having a GUI and a daemon in parallel instead of using the Daemon for all block chain related tasks and use RPC calls to the daemon for the GUI?

It would be easy to develop a web based wallet GUI for mobile devices using a central instance of the daemon, so mobiles do not need to maintain the full BC

Berzeck

@Wellenreiter
Exactly! But our implementation is done in C++, Qt and QML (which uses a lot of Javascript) instead of html 5. Because i consider component reuse more clean and QML implementation of reusable objects is superb!, also in my tests it is faster.
Of course in the future our idea is to adapt backbone to other devices and only change the UI. One code many UI’s according to the form factor.

ghostlander

If I get it right, it’s a GUI wrapper which makes RPC calls to a daemon. The current GUI doesn’t need RPC. It’s integrated into the core.

FTC is already v2 enforced since v0.8.7.

Berzeck

@ghostlander said:

If I get it right, it’s a GUI wrapper which makes RPC calls to a daemon. The current GUI doesn’t need RPC. It’s integrated into the core.

FTC is already v2 enforced since v0.8.7.

Sadly no, you don’t get it right. WBC is a whole framework that enables a user to develop a wide range of non compiled applications inside the wallet, extremely easy to develop that hides completely the internals of crypto from the developer. Actually, decoupling the core from UI is considered a good practice on every language available, this is a very useful feature because it allows two completely different development cycles for two completely different kinds of products:
a] The daemon: slow development cycle, needs a lot of QA, certain knowledge of crypto internals, c++ and so on
b] WBC: very fast development cylce, needs standard QA time, requieres no knowledge of crypto internals, extremely fast deployment and some other features. UI development is just a side product of the whole framework and certainly not the most important, but it allows designers to directly contribute to the development cycle without knowing anything about programming.

I will have to ask to excuse my bad English again because probably i am not being too clear in some points.

Also I was asking for advice on enforcing v2 protocol because obviously you guys already have experience with it, and considering our situation (we don’t have any idea on what percentage of people will upgrade), i thought it was a good idea to ask for advice just in case.

I also would like to ask kindly , please download the wallet and read the blog so you guys can have a more informed opinion. If you think “It’s crap and we don’t need that useless sh**” i can live with that AFTER you understand what i am talking about. Also the blog just talks about ONE feature of the framework, there are other features important too, but at least it will give a clearer idea of what our objectives are with WBC.

ghostlander

@Berzeck That’s what it is. You may call it a framework if you like, however the functionality is limited by the RPC interface. The core GUI may do much more if necessary. The RPC data exchange is also a subject of JSON overhead, though it doesn’t matter much I suppose. Can you run it over RPC-SSL? Could be useful for remote wallet access.

Berzeck

@ghostlander said:

@Berzeck That’s what it is. You may call it a framework if you like, however the functionality is limited by the RPC interface. The core GUI may do much more if necessary. The RPC data exchange is also a subject of JSON overhead, though it doesn’t matter much I suppose. Can you run it over RPC-SSL? Could be useful for remote wallet access.

The functionality of WBC is not limited to RPC interface because you could, for example, make a whole video game inside the wallet, i am sure that FTC’s RPC API can’t do that; also you can build NON UI components so you couldn’t call it a GUI wrapper by definition. Price extractor is a small example of a non ui object built using the framework, so the price becomes a standard variable object you can use for your own components without the need to know where or how it is defined ( RPC mechanism? Internet? ), long term we will implement a lot of useful objects like more complex statistical variables for trade analysis, or simple ones like reward projection and others.

We haven’t implemented RPC-SSL for remote control yet, shouldn’t be complicated and will probably do in the future when and if users start asking for that :), it would be interesting if we could promote this for exchanges as a ‘remote daemon controller’, we will see. Thanks for the idea.

JSON overhead do not represent a fraction of a percentage point of total processing required by a full node, also i didn’t see anything in the current Qt wallet that can not be implemented by ‘outsider’ code. Care to detail a little?

lizhi

@Berzeck I don’t know what we can get.

Berzeck

@lizhi Did you download the wallet and read the blog post?