![image.png](https://files.peakd.com/file/peakd-hive/mattockfs/J0RXbDKl-image.png)

In this post I want to share my modest progress on the new Hive-Adds project. Hive-Ads is to be a rethink and reboot of the old abandoned @steemsense-eu, and a pilot project to explore the use of [FlureeDB](https://flur.ee/) as a HIVE sidechain.

For an idea of what is coming, check out the [post](/hive-139531/@mattockfs/feedback-wanted-an-updated-outline-for-a-add-revenues-ecconomy-for-the-hive-platform-using-flureedb) I did last week, trying to gauge if I should do this project. Thanks everybody for the positive feedback on that post. 

I'm not going to rehash the basic setup, I'll do other posts on that when I reach important milestones, in this/these posts I only want to share the progress on the project to keep interested people in the loop.

## DTAP

The first important note for this project is, I don't intend to eventually run the code of this project myself. I'm a data and code guy, not really a system administration person. I'll be focusing on the D(evelopment), (T)esting and (A)cceptance, not (P)roduction. Not just because I'm really not an admin, but also because of the trust model the code will rely on. HIVE has a trust web that I as a non-witness aren't part of. A system like the one envisioned should eventually be run by a high reputation witness, and that's not me.

For the T+A part of the development DTAP project setup I'll be using three HIVE accounts. My old @pibarabot account that I'm powering up and repurposing as main HIVE-ads T+A bot account, the newly created @pibarabank account that is meant to manage batched financial transactions, and in the near future, a third account meant to manage FlureeDB side-chain synchronization.

The progress here this week has been:
* Created @pibarabank account
* Started powering up @pibarabot and @pibarabank
* Found out (see below in the side-chain section) I need a third bot account.

## Github projects

Not much there yet, but I've created a set of github repos for the project.

* [hive-ads](https://github.com/pibara/hive-ads)
* [hive-sidechain-flureedb](https://github.com/pibara/hive-sidechain-flureedb)
* [hive-ads-flureedb-schema](https://github.com/pibara/hive-ads-flureedb-schema)
* [hive-ads-bot](https://github.com/pibara/hive-ads-bot)
* [hive-ads-bank](https://github.com/pibara/hive-ads-bank)

The *hive-sidechain-flureedb* is meant to be a lazy synchronizer between HIVE and the FlureeDB database that I'm using for the project. More about that below. The *hive-ads-flureedb-schema* repo is meant for importing the hive-adds domain model and the access-rights to this model into FlureeDB. The *hive-ads-bot* repo is meant for the main bot code. The *hive-ads-bank* script is meant to be the code that takes care of pending pay-outs, refunds and burns.

## Looked into escrow

Took some time to look into the HIVE escrow API and if I could map my hive-ads-bank needs to it. Seems, at least for now,  it won't be of much help. As the idea for a bank-like account, the only possible way right now to implement the system, is sub-optimal, even if a *trusted* witness will end up running the system eventually, I'm thinking about writing up an outline. 

Think the ideal system would look something like this.

1) The hive-ads creates a deposit template, defining:
   * 25% of the split should go to null (burn)
   * 75% of split should be split according to the split as specified by the ad system
   * A timeout of 40 days for funds to be refunded to the campaign owner.
   * A dispute timeout of 4 days.
   * An arbiter

2) The campaign owner does an escrow-like transfer, specifying the template above.
3) Every week the ad system creates a split-proposal specifying:
   * Any immediate refund (no arbitrage needed)
   * The amount to be split between content creators and @null
   * The division of split between content-creators.

4) If the campaign owner doesn't open a dispute, the split proposal is honored.
5) If the campaign owner opens a dispute that the arbiter can resolve.

At this moment I'm just putting this out there as a HIVE feature that I think could prove really useful for projects like mine, and I'm keeping focus on my own project.

## hive-sidechain-flureedb experiments

So far I've been experimenting with some scripts for the hive-sidechain-flureedb sub-project. One of the goals of the hive-ads project is to become a pilot for the use of FlureeDB for a side-chain. FlureeDB is a triple-store graph-database that runs on top of blockchain technology. 

One of the primary functions needed for FlureeDB to run as a side-chain to HIVE is synchonizing the users from HIVE into the Fluree database. FlureeDB comes with a quite powerfull access control system for its data. FlureeDB uses data centric security, and by defining roles, rules and smart functions, a side chain App like hive-ads can implement basically any access control rule needed for implementation. A first step though to make that possible is filling the FlureeDB with HIVE users and key-id's as used by FlureeDB.

FlureeDB and HIVE make use of pretty much compatible crypto. And as the HIVE *get_account* API call returns the ECDSA public keys of the account, we can construct FlureeDB key id's. 

The way we do that is, we use the Python bitcoinlib library to turn the HIVE pubkeys into bitcoin adresses.

![image.png](https://files.peakd.com/file/peakd-hive/mattockfs/zsY0CI8o-image.png)

We can than decompose the bitcoin adress, replace the bitcoin 0x00 prefix with the FlureeDB \x0f\x02 and calculate an updated checksum like this:

```python
def hive_pubkey_to_fluree_address(ownerpubkey):
    pubkeyb58 = ownerpubkey[3:]
    pubkey = base58.b58decode(pubkeyb58)[:-4]
    bitcoin_pubkey = bitcoinlib.keys.Key(pubkey)
    bitcoin_address = bitcoin_pubkey.address()
    core = b'\x0f\x02' + base58.b58decode(bitcoin_address)[1:-4]
    h1 = hashlib.sha256()
    h2 = hashlib.sha256()
    h1.update(core)
    h2.update(h1.digest())
    keyid = base58.b58encode(core + h2.digest()[:4]).decode()
    return keyid
```

Now in my experiment, I use this code from a script that reads all new blocks, extracts all references to accounts, does a *get_accounts* API call for any account it hasn't seen yet or any account mentioned in an *account_update* or *recover_account* operation. 

This is how far I've come this week. Next step is to stream this data into FlureeDB so that every active account on HIVE eventually ends up in the FlureeDB side-chain. In fact, it wouldn't be a side-chain if we wouldn't do this.

## Next?

Next steps coming up now is the creations of basic roles, rules and possibly smart functions needed for access control with the different rules. If there are roles in the FlureeDB schema, I can start turning my experiment into a synchronizer. I'll power up the two existing accounts a bit more and will create a third one for the side-chain synchronizer.

My next post will hopefully be about a working side-chain-synchronizer. 

Like before, all input on my project is highly welcomed.