Create the Getting-Started page #188
Conversation
There was a problem hiding this comment.
There are quite a few things here that are factually not correct. I have pointed out some of them.
From a high level this does not integrate with the main part of the mkdocs configuration and I think that this getting started document should probably be broken up into a number of pages.
Also with things like setting up the metamask account, we need to include screenshots and diagrams to make this each for the user to work through
| #### \ | ||
| Networks {#networks} | ||
|
|
||
| There are **2 native Fetch.ai networks**: \ |
There was a problem hiding this comment.
This is not quite correct we have quite a few networks:
There was a problem hiding this comment.
This is not quite correct we have quite a few networks:
Yes I thought some of them would be deprecated after full release of Stargate.
|
|
||
|
|
||
|
|
||
| * The **Fetch.ai Stargate mainnet** |
There was a problem hiding this comment.
The main net is on launchpad currently, but will be upgraded to the stargate version in the future. As this is, this is a little confusing I think.
There was a problem hiding this comment.
The main net is on launchpad currently, but will be upgraded to the stargate version in the future. As this is, this is a little confusing I think.
Ok, I thought the new version of the docs would be released after the Stargate upgrade, isn't supposed to be at the end of this week anymore?
|
|
||
| * The **Fetch.ai Stargate mainnet** | ||
| * The **StargateWorld testnet **for **developers** | ||
| * In parallel, the **Ethereum** blockchain is also used **until complete migration to our mainnet**, planned for Q4 2021 |
There was a problem hiding this comment.
FET tokens on the ETH mainnet will be available for the foreseeable future. We expect to get more exchanges to support the native network in the future, but this is always a long term project.
We expect to have token bridges between ETH and Native (as well as other networks in the future) from some time to come
There was a problem hiding this comment.
FET tokens on the ETH mainnet will be available for the foreseeable future. We expect to get more exchanges to support the native network in the future, but this is always a long term project.
I know but isn't it supposed to be ended in Q4? I mentioned Q4 as the time where ERC-20 would disappear.
We expect to have token bridges between ETH and Native (as well as other networks in the future) from some time to come
Yes I made a whole section about the ETH-Native bridge, but ok I can mention that other bridges will come.
|
|
||
|
|
||
| * Our **native FET**, running on our mainnet | ||
| * Our **temporary ERC-20 FET**, running on Ethereum until complete migration in Q4 2021. |
There was a problem hiding this comment.
Not correct. We will have FET on ETH and Native for the foreseeable future. In each network there will be the same total supply and it is the job of the bridges to ensure that the liquid tokens are locked up on the corresponding networks.
There was a problem hiding this comment.
Ok, but then if there will be FET still running on Ethereum after Q4, what is the point of the FET complete migration in Q4?
|
|
||
|
|
||
|
|
||
| * Fetch.ai’s nodes are run by selected **validators**, staking a big amount of FET. |
There was a problem hiding this comment.
Not quite true. The mechanics of the staking mean that the validators with the highest delegated stake (either by the validator themselves or the delegations by the community) will be selected as a validator.
There was a problem hiding this comment.
Sorry but I don't really get how it opposes to what I wrote.
| * Fetch.ai’s nodes are run by selected **validators**, staking a big amount of FET. | ||
| * You can **delegate** your FET to validators, and receive **rewards** in FET. | ||
| * Unless you are a delegator, when we talk about staking, we are actually talking about delegating your FET to a validator, and receiving rewards from the validator. | ||
| * You can stake both your native FET, that will eventually be the only ones in circulation, and your ERC-20 FET until they disappear. \ |
There was a problem hiding this comment.
Again ERC-20 FET will not disappear
There was a problem hiding this comment.
Ok but then is the complete migration planned for staked FET only?
|
|
||
|
|
||
| * Our **Chrome browser extension wallet**, based on the **Keplr open-source wallet** | ||
| * Our **Fetch.ai v2.0 mainnet** **wallet**, with your **Ledger Nano** and our **block explorer**’s interface |
There was a problem hiding this comment.
This is a little confusing. It is not really a wallet, it is just that our block explorer can talk via WebUSB to ledger devices. It would be clearer to say that if you install the cosmos application on your ledger devices that is the wallet
There was a problem hiding this comment.
Ok, then how about:
- Our Chrome browser extension wallet, based on the Keplr open-source wallet
- Our Fetch.ai v2.0 mainnet wallet
- Your Ledger Nano, using its Cosmos application and used on our block explorer’s interface
|
|
||
|
|
||
|
|
||
| * Our **Chrome browser extension wallet**, based on the **Keplr open-source wallet** |
There was a problem hiding this comment.
The current chrome browser wallet that we announced a few weeks ago does not support the current mainnet (launchpad) version. Instead it only supports stargate (the next release) so can only be used on the testnets currently (until we have done the network upgrade)
There was a problem hiding this comment.
Yes, but won't Stargate be running already when the browser extension is publicly released? I was basing the docs on the idea that they would be released at the earliest in August, when the Stargate upgrade would have happened already.
|
|
||
| At the time of writing (Q3 2021), most FET tokens in circulation or offered by exchanges are still ERC-20 FET on Ethereum, but you can already convert them to native FET and transfer them to mainnet. | ||
|
|
||
| Your storage options for **native FET** on mainnet, detailed below, are: |
There was a problem hiding this comment.
Storage options are not really a good description for this. It is much more about management of public/private key pairs really.
There was a problem hiding this comment.
Ok, then I need more info on that.
Ok, I actually followed Jon's plan, but yes, I think the idea is to have a page for each sub-section, I think we all agree on this.
Ok |
Co-authored-by: Ed FitzGerald <[email protected]>
No description provided.