Unless your credit is actually with the nodes you are going to upload to then there needs to be transfers. Best to just wait till you don’t need credit nor the complexities that go with it
What would the upload credit be?
If it were on Arbitrum, there would be no benefit.
If it were a native Autonomi based token, then is it not effectively a native token, and would be just as much work to implement as a native token?
Yes, 2c isn’t terrible. I hope there is a short term solution to avoid massive fees as you & Neo say.
Also, a more sensible minimum ANT price for uploads would help ensure nodes benefit from uploads while the network is flooded with excess nodes.
It seems like Native token would be very beneficial short term as well, so why not take steps that might bring forward its readiness while the team can’t focus on it?
David hinted a number of times that he’d be open to another team developing a Native token solution.
There is a new upgrade for ethereum, Pectra, in March. That update seem to anhance scalability and lower cost. I am no eth expert so it is just what I read on google.
Short term would be awesome, but presumably out of reach. I believe going with blockchain was to bridge the implementation time gap, as well as avoiding exchange issues.
I expect so, but it highlights how ASAP is probably desirable, so if there steps that can be taken to make it possible sooner, it’s worth considering them.
Absolutely. The blockchain aspect will still add value after any native implementation due to exchange integrations, smart contracts etc, and it’s fantastic to have a live network running and developing ahead of any native implementation.
Yes I too got stung last night after having finally got a medium size upload to work - 200M of a Who bootleg. It failed because I did not have £12.50 worth of ETH available - only about £8 which I thought would do me for a good while.
So just when the actual uploading seems smoother we get stung with stupid high gas fees…
We will get there, but its a sair fecht, right enough.
they’d be able to escape this trap right now switching to the solana network, it’s literally where 90% of appbuilers/liquidity is. The only proven blockchain that works under enormous load, both in terms of transaction fees- and speed.
Changing chains at this time will be a MAJOR hassle and will not have good optics at all.
That does not mean you are wrong , however.
There may be some tough choices to make for @Bux, @JimCollinson et al.
Maybe we should just wait until the hot fix is ready this week, then see where we stand?
The max gas fee would seem like good, low hanging, fruit too.
Changing blockchains, implemting native, etc, are all big lifts. We also aren’t aware how close to a solution on all this the team are yet. Give the devs a breath! ![]()
Yes we may have (perfectly legitimate) complaints but NOTHING should take away from the efforts the devs have put in -and will need to continue putting in.
They deserve our continued thanks.
We have the luxury of being able to shout and bawl on the forum and on Discord - they need to put in the hard work and make the tough choices to move us forward.
I am pretty sure we all have the long-term interests of the project at heart, even if we dont always see eye to eye on every detail.
One more time, give it up for the devs AND management team
![]()
Last August:
This isn’t about the development team for me, and I have never criticised them because my issue is about the way things are portrayed compared to the reality. Whether about when launch, or the real impact of ERC20, or anything else.
The devs continue to do sterling work and I’ve always found them more than willing to help out when I felt so stuck I had to ask.
That fix cannot solve the problem of volatility or handle different users who will inevitably have different price sensitivity, or different attitudes to storage or different kinds of data.
Having said that I do hope the fix will help uploads work far better.
no benefit other than the team was more familiar with eth/layer 2, a prior conversion was done on this same network (maid to emaid) and eth is somewhat more accepted tech amongst our dinosour crypto community. Arb was therefor a more logical step compared to Sol, but a terrible descision nevertheless.
Oh fork, I have a script running that will pay whatever. “Only” $300 in eth on it but… noooooooooooooooooo
NNNNNOOOOOOOOOOOO
It’s still a brilliant move to have ANT on the blockchain, it’s a perfect demo that it doesn’t scale (tx costs) and availability for newbs.
But there is also Stellar with it’s 0.00001 tx fee, although if smartcontracts go on top of that your mileage may…
This is all good news for the native token and altANT on the Network
Don’t get my comments wrong, this is not criticising anyone but is observations and trying to highlight perhaps some issues that will impact the users trying to use uploading from their home situation.
Basically I had to use a VPS to get (a lot) better success rate than from a decent home connection setup. 1 in 10 for home and about 25 in 30 for VPS in the end.
The other highlighted point was that the client has no way to limit what will be paid (eg just not upload), like a fees per chunk or ANT per chunk. From a user’s perspective this is perhaps one of the most important features to add to the client. (seems @happybeing has highlighted this already)
The team is super busy and I can understand that everything will not be done in my or another’s perceived urgency. It is here to highlight, not criticise the hard work being done.
I generally think at the moment, while the network is operational, this is a SC emissions issue only, that is the SC is not that smart, so it is getting gamed by big node operators, leaving out the small operators.
My suggestion’s focus was,
in order to make that SC smarter so as not to leave the small operators out of recieving any emnissions,
was to retool the SC emissions behaviour to more evenly distribute emissions,
and as far as I can tell to acheive such a goal,
that requires changes to effectively ID the size of operators defined by a unique pair, the suggestion was for the SC to request that unique pair Wallet-ID/IP Address and then map that data into an array to produce/maintain an actual bell curve of what was distributed, versus what the distirbution wants to be , in some fashion,
of course there are multiple ways to do that, that is all I was trying to address , suggesting a w way to ‘;smarten up’ SC emmisions so the small operators dont get left out. WQho appear to be about 25% of the network at the moment per the poll made in this forum?
![]()
While I don’t think it’ll work in practice since the big players will bypass the restrictions, I do see your point and be nice if an easy way to do that was available.
Still the best way to level it out a bit in my opinion is to have data being uploaded to the network. Then its harder to run nodes as emissions earners, they are then actually also doing work for the network.
I am pro uploader for sure, I don’t really care for the emissions program, the emphasis of incentives should imo be biased toward the end user uploader and the small home node operator.
For sure the Economic Model for upload rewards will get tuned but that Model needs a DAO run by the community to manage that tuning.
Clearly the original vision and the main goal is to enlist the entire planet to use the Autonomi Network and its native token, we need to stay true to that vision.
(I get the ERC-20 bridge need, however maybe the wrapper notion is the way to go with native but only for the bridge in/out liquidity flows and let the gas fees take care of the flow rate)
The above means treating uploaders and home node operators as first class roadmap citizens in the UI Client sense (I think node-launchpad is decent now in this respect, I have not attemped to play with DAVE, its seems still WIP ) which is where the DAO is a must. How that governance works for submitting and approving and even Foundation funding of CR, NFR work needs to have a solid look at those DAOs that actually work well, Cosmos I am sad to say is not one of them (he who has the most tokens staked in the vote wins)
Also treating the ‘pro’ node runners with well tested tools, as well as equipping them with a supported/tested orchestration deployment capability at scale in the form of CRUD VM/Container monitoring framework Autonomi QA’d soloution @ scale(Clustering) these operators can rely on from the cli…, optional UI (ie- Incus or LXD with cluster support or something similar). This needs to be a community/Maidsafe joint effort imo. I am biased here full disclosure, toward linuxcontainers.org and Incus. I’ve veered away from Canonical and LXD WEB UI LXD, given their licensing shenanigans.
I like what is going on with anTP and dweb, Jams and the like by builders. Imo perhaps there should be a starter pack of builder apps that are tested by the foundation or 3rd party testing, easily and optionally downloaded from autonomi for use by anyone at least in basic FOSS form?