anchors API to support anchors into FCT mainnet

[ilzheev]

Currently factomd anchors API supports only BTC and ETH anchors, which are used into Factom Mainnet.
If there is a custom network (e.g. community testnet or any private network), it would be great to have anchors API returning anchors, made into FCT mainnet.

I know some Factom Inc private networks are anchored into FCT mainnet.

1. Do we have any standard for FCT anchoring entries?
2. Is it possible to implement FCT anchors support into anchors API?
3. As there are many custom networks possible, each will have own chain and signature for FCT mainnet anchors — so this data should be into factomd config rather than being hardcoded?
4. Is it good idea to update Factom Golang lib and implement FCT anchoring entry format as a standard? So it could be used in any custom networks?

Let's start the discussion.

[WhoSoup]

1. Currently only BTC and ETH anchors exist
2. Yes, the current format is semi-extendable. It would require core edits to understand it, and I'm not sure if the anchoring software inc. currently uses is open source. The latter wouldn't be hard to write, just a small script
3. The way BTC/ETH anchoring is currently configured is that each has a hardcoded chainid, with a configurable pubkey in the config used to verify entries. If you want to anchor into multiple different factom networks, that could be done with a single chain if you wanted to hardcode it for simplicity's sake
4. It can already read anchors so that would have to be extended to understand FCT anchors, but writing anchors should be part of the anchoring lib itself. There's no good reason to have it in the factom lib but also no good reason not to have it

Pros: It would allow private factom networks to anchor into the main factom network
Cons: This might encourage more private factom networks, which don't make a whole lot of sense when it comes to proof of authority

[ilzheev]

3. If you want to anchor into multiple different factom networks, that could be done with a single chain if you wanted to hardcode it for simplicity's sake

I meant that factomd is open-source and there can be many custom networks — e.g. community testnet, Inc's networks, De Facto's networks, etc. I think anchoring should be One-to-One: each network anchors into one own chain on FCT mainnet.

So FCT-Anchoring-ChainID should not be hardcoded in factomd, but should appear into config.

[ilzheev]

4. It can already read anchors so that would have to be extended to understand FCT anchors, but writing anchors should be part of the anchoring lib itself. There's no good reason to have it in the factom lib but also no good reason not to have it

If we want to have an anchoring standard (why not finally?), I think it's good idea to have into Factom Golang lib:

1. Functions to prepare and sign anchor entries (e.g. CreateFCTAnchor(dblock *factom.DBlock, key []byte) *factom.Entry).
   I am not telling about submitting this entry to the Factom Mainnet — I would leave it for anchoring software/script, as it needs to be separate software that reads data from customnet and writes it into mainnet.

2. Extend existing function GetAnchors() so it understands FCT anchors into API response.

[WhoSoup]

I meant that factomd is open-source and there can be many custom networks — e.g. community testnet, Inc's networks, De Facto's networks, etc. I think anchoring should be One-to-One: each network anchors into one own chain on FCT mainnet.

So FCT-Anchoring-ChainID should not be hardcoded in factomd, but should appear into config.

That makes sense. It should be configured with the network name in it, ie fct_community_test. Then the TestNet would anchor into a MainNet chain with a name of something like ["AnchorChain", "fct_community_test"]. The only downside of that would be if two custom networks have the same id. We can make another "unique id" in the config if needed for that case.

[ilzheev]

The only downside of that would be if two custom networks have the same id. We can make another "unique id" in the config if needed for that case.

How is it hardcoded in the mainnet? As ExtIDs or as chainIDs?
For consistency purpose —  i.e. having in config extID OR chainID — I would do the same way as BTC/ETH anchor chains hardcoded (extID vs chainID).

[WhoSoup]

How is it hardcoded in the mainnet? As ExtIDs or as chainIDs?
For consistency purpose —  i.e. having in config extID OR chainID — I would do the same way as BTC/ETH anchor chains hardcoded (extID vs chainID).

Currently, MainNet has only the chain id hardcoded. The chain itself was created outside of factomd, and factomd can only read the anchor entries, not write them.