Again, don’t tell me, tell the team via an issue in github. That way its on record and will be looked at. Frankly at this time they are ignoring posts like yours and many others because they just cannot spend time worrying about them now.
If you leave a comment/issue on github then they will get to it. They will not be going back trying to read a hundred threads here later on.
Of course you are confident in your claims aren’t you, then do that.
This is an open discussion. Which repo you want me to add comments to? I dont think there is a whitepaper just yet. Have gone through vanilla wp
Of course its an open discussion and not trying to stop you, but trying to make sure you know the team is not going to see it (or not action anything from here) and if you want to get it looked at then Github is the best. Also explaining why I find this a waste of effort for me, and minimising one of the strengths is a mistake and makes it sound like blockchain or bust attitude
Maidsafe github pages. Not sure of the link but a search should find the currently active one quick enough.
And there is a version 2 Whitepaper now, so you missed 2 of them. Along with some other knowledge of workings of Autonomi
when assuming that the here suggested token (TX datatype) will be stored by nodes free of charge; the “standard TX Datatype” (that is not available e.g. in the current python API yet) does require to be stored on the network and paid for just like any other datatype - otherwise every token TX would again require a storage payment for the TX itself within the network (requiring ANT and ETH 
)
This is the issue. I really don’t want to get into being forced by sheer crowd pressure to introduce a native token right now, BUT I am as keen as anyone for this.
I have (and I being me have much less authority that anyone to make this happen, and I seriously mean I will fight to not have that authority or power as it’s very very bad) been muling over this and here is what I currently feel (current is this second, I am all over the place brainstorming here).
(assuming bugs are fixed we know about in upload)
So I am trying to figure out a mechanism that avoids changing antnode code itself to do this. Otherwise we need to have a data type that is free and with all the focus on us now, this type will be abused to absolute hell with folk just uploading billions of fake transactions per hour, flooding the network and damaging it. Many community members will create scripts to “prove” the transactions are good and free and … and so on.
So this is quite difficult to balance out, not that any of this means going free native first would have been any better. It’s just interesting as we we how fast this could grow but also with it will come threats to a relatively smallish network (even at 100million nodes) could come from supporters and attackers all working together in unison
There will be. vary clever and simple answer, but even mentioning native gets everyone saying we need it yesterday, the network is not real without it and w must must do this right now and so on. So it’s like trying to share some info and brainstorm in no mans land in a huge firefight Not simple
Maybe you should explain your understanding on how the network resolves multiple mutations, then argue why it is insufficient.
I don’t think that’s a great assumption.
I know it has been suggested that transactions should ideally be free, but I’ve always felt they should be priced according to what they cost nodes in storage / processing / bandwidth… so likely a very low cost, but high enough to prevent abuse and ensure nodes are rewarded for processing & storing transactions.
If a Native ANT were available, payments to nodes could be switched to Native so the transactions would not require ETH, only Native ANT.
This is encouraging to hear 
I am pleased you’re keen for Native, but with this thread I’m not seeking to pressure anyone, especially you given what you have on your plate!
Isn’t the simple answer to avoid spam just to charge a TX fee at a price that covers the cost the nodes face in processing & storing transactions?
It would mean transactions aren’t free, but they’d be very low, and any growth in transactions would be completely scalable and sustainable.
Maybe nodes who are receiving incoming payments for storing data could choose to ‘waive’ the fee, as it’s tiny vs what they’ll be receiving to store data.
This way, fees for paying to store data really will be zero, but fees for anyone looking to spam things will not be.
Yeah, there will be many contradicting opinions thrown around… but hopefully in the mess some useful stuff comes out that can move thinking forward. If people remember to be respectful & encouraging it’s not so bad, but when that is lost it goes rapidly downhill.
I know you’re not seeking to, but without @dirvine this topic will involve a lot of speculation and incorrect assertions. That puts the bat signal up and inevitably distracts.
It’s also a hit like discussing how the canteen will be operated, once we have landed on Mars. I mean, it’s a fun exercise, but actually getting to Mars is pretty much the entire focus until the landing rockets fire! 
okay - so it is like the following:
@DavidMc0 stores his favorite cat picture to the network
so without changing the initial payment system to include an additional payment output(s) for the additionally needed payment TX for a native token we are trapped in an infinite loop of required payments
and that’s just the first obvious needed change for nodes … we’ve not even started to investigate consequences …
I’m sure team members are perfectly capable of ignoring discussions that are a distraction to them.
If people don’t want to talk about bridging / Native token ideas, team or other, they can feel free to ignore this topic.
I would say it’s more like discussing how to enable possible boosters capable of getting us to mars. Without Native, we’ll only get part way to the potential of the network.
We’re discussing doing something new… of course changes will be needed, and may be needed for nodes to accept a new way to be paid.
Do you have any ideas about how Native tokens could be implemented and enabled to be bridged from / to ERC20 tokens?
well … since there’s no server side computing on autonomi yet … a bridge either would need to live as a SC on arbitrum or would be a centrally managed service I guess …
I’m not deep enough (at all) in SC design so I’d probably better leave this for others to dig into … a mint outside of the network doesn’t look super attractive to me … a unidirectional burn-process to get native token does somehow look easier to implement and secure… and/or maybe simply a decentralized market place could be used to swap native back to ANT(Arb) …
so maybe the question before “how to design a bridge” might be does it need to be bidirectional at all … (and I personally would question it)
but maybe before native currency we then might want a DEX within autonomi
I suspect that is why you started this thread when you did too. I’m just reading between lines. Carry on.
and for a burn process … well … nodes do have connection to the EVM network anyway … so one could utilize that for validating the genesis event (there’s just the question how we get rid of that evm dependency then again later on … but maybe there could be a cutoff event and after that all valid burn TXs get stored to one gigantic immutable blob stored on the network) …
nodes could verify that and without a valid burn the coin wouldn’t be valid … the question then is how to identify (in)valid coin when they have moved on without tracking back everything to the genesis event (and validate all involved genesis events on the arbitrum blockchain…) … and how to deal with wrongfully accepted branches of the native token etc etc …
I stated it clearly in the first post that I believe a lack of Native token will hold the network back, so I want to see it ASAP & discussing possible ways forward could help with that.
Yes, I asked this very question in the first post.
I feel bi-directional is better, but it will also probably be more complicated, and if one-way Bridge is economically viable (i.e. diverging price of Native vs ERC20 isn’t a problem), then it’s well worth considering, and is what Bux hinted at previously.
In addition to being better at keeping Native & ERC20 ANT at the same price, 2-way means people will be able to take Native ANT and move them off-network to store safely in a hardware wallet, to sell on an exchange, or borrow against on a defi protocol. I don’t think these things would be possible with a one-way bridge, and add value to the ecosystem.
This is also part of the reason I’m interested in a 2-way vs 1 way bridge; it would allow USDC / Wrapped BTC, ETH etc etc to also be bridged to Autonomi, which would allow a DEX to run on Autonomi.
If you could somehow do a DEX without 2-way bridging, and set up a market for ERC20 ANT / Native ANT, it would indeed make a smoother path for a 1-way ANT process to work.
A centralised bridge like what happened with eMAID via alt.co would probably be the fastest way to do it, but I doubt many people would want to go that route due to the required trust, KYC,and centralisation.
Yes, that would be a key challenge. I know DAGs aren’t well thought of, but I wonder if there were 1 mini-DAG per burn/mint event, it would prevent them getting unwieldy vs having one massive DAG for all Native ANT?
well - if you read my proposed burn process carefully you will see that it basically is exactly that … just with the possibility for branches to recombine again when all the strings are valid and point to the same genesis object (being derived from the thing that is being wrapped … possibly ANT but possibly any other currency too) … but ofc without a path back …
… but then again maybe that path back is not really needed (for sure not for native currency because that is cheaper to use for uploads + faster … and some farmers for sure will want to sell it so there should be liquidity on both sides)
@blvd by design Autonomi is essentially a distributed event driven architecture based on the principles of stigmergy, not a sequential blockchain being converted into a massively parallel set of shared L2 blockchains, all controlled including the rollups, by some timed epoch at L1 aka ETH aka SOL (Think Ben Hur hammers and slaves rowing the boat. there are speed and @ scale limits built in).
The challenge for all of us here is to work together to think outside of the ‘box of blockchains’, and create concepts, ideas within the context of Autonomi Network to leverage those stigmergy enabled capabilities.
I had to look this up.
This was still one-way!
