I blame @dirvine for not making it idiot proof in the op. Now we need a 3rd poll. 
4 Likes
You should be able to change your vote
2 Likes
It would be interesting to make Autonomi IPv6-only and watch the world get pushed into it just by wanting to use the network 
You can always undo your vote.
6 Likes
I did lets hope others who already voted read the comments.
I think itās highly likely that many users would choose a new payment option (native) that came along that made uploads cheaper, faster, and more private once itās available. Particularly in use cases where thereās a need to make lots of small transactions where fees might add to upload costs significantly (e.g. social media posts / likes, gaming etc).
I also think itās likely that nodes will accept a new payment method thatās easier & faster to transact with, and 1:1 exchangeable for ERC20 if needed (e.g. for exchanges / use in defi / other smart contracts etc).
The benefits of Native are clear, and the team has never abandoned it except, it seems, in the minds of the anti-crypto enclined. Maybe Iām being unreasonably optimistic, but I expect notā¦ it would take a lot for me to conclude thereās a betrayal of fundamentals by the founders & team.
The ecosystem of ERC20 + Native is richer than native alone due to smart contract capabilities (which have already improved the decentralisation of Autonomiās plans by reducing holdings of the foundation & managing distributions through smart contracts) & access to DEXs, CEXs, wallets and all other things the ETH ecosystem will open up as the project goes liveā¦ and of course the fact Autonomi can launch more quickly.
I also canāt imagine how a native only launch, where 100% of invested capital becomes at risk after launch, with potentially no way of recovering balances in the event of a network failure, could be considered sensible. With ERC20 in place, the native token testing & launch becomes a less risky following the far earlier launch.
But, on topic, is there a way of using some kind of VPN to forward IPV6 websites to a computer connected to an IPV4 only ISP?
8 Likes
Oh - I just installed CloudFlareās https://one.one.one.one/ app, and immediately got 10/10 on fixed line and mobile Internet where I couldnāt get IPV6 on either before.
I expect itās a safe app being cloudflare, but that was easy and successful.
I tried DNS only & it didnāt work, but their VPN did.
1 Like
Stop right there and show me how that is technically or otherwise achievable - to make the native token a seamless alternative to ERC20.
This is the root of the problem. People do not understand why this is not feasible. If it is, letās see how from anyone who believes it is. No-one from Autonomi have answered this - they havenāt presented a plan or strategy. They have just relied on people assuming that when they say āwe will implement the native tokenā that somehow means it will be a seamless peer alongside ERC20.
There is no reason to assume that and plenty of reasons to believe it isnāt feasible, and that even if it was that it may not happen anyway. Iām tired of this, so thatās all I want to say in response.
3 Likes
Before ERC20 was introduced, something very close to the Native token design was operating, and with further development it would operate better, with easy to use wallets etc.
Right now, the ERC20 version is running with no problems.
So if both are already shown to be feasible separately, how could it be not feasible to update software to let nodes & clients send & receive both?
The biggest challenge I see is in the bridging, which it is true has not yet been detailed by the team, so Iām trusting there will be a solution. That bridging (ideally 2 way) will be possible doesnāt seem implausible to me given the amount of successful bridges that have been shown to work for a variety of other types of crypto token. Itās ready to go for Arbitrum, but will need the Native token side sorted.
Can you explain why it is not feasible?
Can you give some examples?
If you want to leave your assertions that ERC20 + Native is infeasible without giving reasons, I guess thatās fine, but it wonāt help inform anyone who doesnāt see why you think itās infeasible. I for one would like to know if there are solid reasons it canāt work because I canāt think of any beyond the bridging challenge.
1 Like
Yes, there are few different methods how to do that. You can google ipv6 tunnel broker, that is a good start.
1 Like
Thanks - Iāll look into that.
For now I tried Cloudflareās 1.1.1.1 + WARP app, and WARP got it working on my Android phone where it wasnāt working before.
Nice to know there are easy solutions in case IPV6 solves more problems than the short-term inconvenience of using something like this for some to access IPV6 services.
There is the problem. The assumption that if each can be done (which is not what I am questioning), then surely they can be run alongside and one segway to the other.
That is not tenable and until someone explains how that can work, and presents a plan and strategy showing how, it is wishful thinking. Which I have pointed out is what Autonomi are relying on. Iām not going to keep explaining why I donāt see this as feasible. Let someone explain how it can so we can then assess the feasibility of that.
Bridging is not easy, but I have not said thatās the problem. The problem is that once ERC20 is there, I donāt see how you can get a native token in there too. Focus on that.
2 Likes
Youāve just asserted again that itās not feasible without explaining why.
Have you laid out the problems you see anywhere else you can refer me to?
Many exchanges & wallets accept USDT on various L1s and L2s with no problem. Why must that kind of thing be problematic on Autonomi with ERC20 + Native, assuming bridges? What problems do you see that seem insurmountable?
Maybe if you explained how you see the two working together. Like if erc20 and native exist, do nodes have the choice between accepting payments in ERC20 or Native, or is ERC20 just the token that can be exchanged for Native to use on the network?
I have no clue what you mean when you say ERC20 and Native and bridges. There are many ways that could be done and many considerations for which way you mean. Cannot discuss your idea without knowing it
1 Like
I see no problem having both operate alongside each other, with both being able to be used to pay nodes for storage.
By bridging I mean the ability to swap ERC20 ANT for Native ANT, and ideally vice versa using a ābridgeā between the 2 versions of ANT.
If a 2 way bridge (my preference) is enabled, uploaders could pay in Native ANT or ERC20 ANT, and nodes can accept both.
If a node has a preference for one or the other, they can Bridge / swap to only hold the one they want. This could be automated in the node software if someone always only wanted Native for example.
Anyway, there are probably many ways of how it could be done.
The question I have is why it should be considered not feasible to have both ERC20 ANT and Native ANT on the same network?
Assumption is that nodes will accept both. As soon as one token changes in price to the other, node operators will switch to accepting one token only. Someone will provide a mod to make that so if its not already written in.
Thus the fracturing begins.
This is why payments have to be on one token only. People cannot be expected to have a supply of native and a supply of erc20 to cover these cases. And once the 5 closest nodes only accept one of the two tokens then data cannot be uploaded and the file upload fails.
If you then say the uploader can simply bridge what they have into the other token to pay then you defeat the argument for the 2 tokens available to pay because you can simply bridge everything to the native and just pay with that.
Having two tokens to pay nodes with does not make sense once you can bridge the ERC20 to native. At that point the network uses native only and erc can be used as a vehicle to interact with wallets, exchanges, dexs etc.
No need to mention the added complexity in the code to be using two tokens to pay for resources. And as David said it may require a āforkā to switch over. Also Bux has said there will only be the one token to buy resources with and it will be a burn from the erc20 token to native
4 Likes
By utilising a DEX running on autonomi to exchange the one coin for the other and crediting only the ārightā coin to the connected wallet? 
(why would you opt die a different version that simply declines payments instead of converting?)
2 Likes
Or at some point we just switch to storage being paid in nativeā¦ The other thing still coexists and might have use cases other than storage paymentsā¦ But storage is being paid in native because it doesnāt make sense to do anything elseā¦
1 Like
My point was that if these exchange mechanisms are that easy then there is no need to make nodes accept two types of tokens.
All that is needed is for the node operators and clients to do their own conversions in and out of the network if they really want to use erc20 and use the native token on the network to pay for resources. None of this confusing (to general public) use of multiple tokens that some nodes accept and some do not. It will spell fracturing of the data when people who do not know crypto have to exchange just to satisfy nodes for that one chunk out of hundreds.
If a node operator really wants to have erc20 then simply use a bridge when taking out their tokens
The issue will resolve itselfā¦ Erc20 comes with fees for every TXā¦ With native you save on every uploaded chunk (I personally do expect the tx fees to be higher than storage cost) and may just have one conversion fee to Nativeā¦ No-brainerā¦ Nobody will want to pay storage in erc20 when thereās a tx fee free alternative available
6 Likes
I can see value for some if they use an exchange mechanism/bridge to take out their native token earned to erc20, and have no issues with that.
I agree erc20 will not be good for payments once the native is in place because of the fees. So there is zero reason to have a system where 2 tokens have to be accepted by nodes. Keep the code simple, save on debugging, attack vectors, and so on by having just the one payment token for storage etc. Once native is introduced it becomes the token of resource payment
5 Likes