Full Public Fake/Mirror API [WIP]
# IPA rorriM\ekaF cilbuP lluF | Full Public Fake/Mirror API
Here it is again - a post that is meant to serve the purpose of on-chain coordination on the progress of testing the upcoming upgrade of our ecosystem.
https://www.youtube.com/watch?v=KhuTi1VLldo Yet another Hive logo reveal, special edition for the full Fake/Mirror API
# RTFM
Please refer to my previous posts if you are not familiar with what the mirror/fakenet is.
I strongly recommend you read it before doing anything that involves Hive Mirrornet.
# Dealing with rough edges
Before we turn the bleeding edge into cutting edge technology, let's deal with rough edges first.
Please make sure that this environment is set up properly. There might still be some minor issues in the environment itself. If you’ve found anything, make a comment here or come to [OpenHive.Chat’s #dev channel](https://openhive.chat/channel/dev) to tell about your issues.
This post will be edited as we progress (as long as there’s [WIP] in the title), so please pay attention to the changelog.
# Fake API endpoint: `https://api.fake.openhive.network`
Fake chain-id: 42
Previously I focused on the consensus nodes and their interaction in the mirrornet, but for app developers it was not enough to perform full scale testing. For that, nodes need to support not only the ability to broadcast transactions, but more API calls, which means more plugins in hived, especially the `account_history`, but also `market_history`, and `transaction_status`, etc.
## Plugins
My reference hived node used for API endpoint have those plugins configured:
```
plugin = webserver p2p json_rpc
plugin = database_api condenser_api
plugin = witness
plugin = rc
plugin = market_history
plugin = market_history_api
plugin = account_history_rocksdb
plugin = account_history_api
plugin = transaction_status
plugin = transaction_status_api
plugin = account_by_key
plugin = account_by_key_api
plugin = reputation
plugin = reputation_api
plugin = block_api network_broadcast_api rc_api
plugin = wallet_bridge_api
plugin = state_snapshot
```
## Hivemind
Such a full blown `hived` node is still not enough for many applications, especially those that deal with social aspects. For that `hivemind` is needed. Unfortunately it takes a lot of time before it can be sync from scratch, and since it’s a mirror/fake, I couldn’t use the mainnet snapshot to speed things up.
## Jussi
And of course in order to route API calls properly between the `hived` and the `hivemind` there’s a `jussi`, preceded of course with other mundane stuff such as SSL termination.
## Broadcaster
Currently, the same node that deals with incoming API calls (such as accoun_history calls), also serves as a source for hivemind and for any broadcast transactions.
# Mainnet traffic
Please be aware that some of the mainnet traffic also comes to the mirrornet through a so-called “node based converter”. That means that accounts on the mirror net live their own life.
# Mainnet lookalike but fake
Again, it's extremely important to understand that everything that's happening on the Fake/Mirror net is ... fake. Even if it looks real. All that stuff is for testing purposes only. Please make sure that you know what you are doing.
# Changelog
- API endpoint is up and running
# Let the testing begin
> _”Should anyone present know of any reason that this mirror should not be joined in holy consensus, speak now or forever hold your peace”_