# 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.
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”_

See: Full Public Fake/Mirror API [WIP] by @gtg