Just wanted to bring this to @happybeing s attention:
interesting - I somehow was afraid this would break it when the mutable gets edited by someone else - but it still gets fetched; just overwritten locally when you know you wrote it (and the new state just didn’t propagate through the network yet)
makes performance tests a bit more tricky xD but that’s okay I guess
Thanks, but ahead of you. ![]()
I’d rather they were working reliably before adding complexity tbh.
Is this PR…
…going to finally resolve this issue:
I’m asking, because that PR -description seemed to refer just CI tests and was not linked to any issue.
Why do I care? I don’t even code anything. True, but believe or not, I was one of the first (maybe even The First) person from community trying to do something with registers back in January 2024. ![]()
And why was I doing that? I see these public mutable data types as the feature, that can make Autonomi more than just a data storage, paving way to the “new internet”.
Well this is an interesting idea!
Interesting, yes. If it works, doubt it to be honest.
To me, it feels like this is a quick fix for the current state of the network and partner uploads now. But once the network starts to fill, I expect (hope?) that cost for upload heavily leans towards ANT already instead of ETH L2 chain fees. That would instantly make this feature absolute again. What am I missing here?
Add an additional payment mode where only one node gets paid instead of three for each record. The one node will have to be paid ten times the quoted amount as a penalty for using this mode. So uploads using the single node payment mode will be more expensive ANT token wise, but it will save gas fees by about 67%.
From what I can see on the Arbitrium blockchain, it would be much cheaper to pay 10 times more to the node if the cost of fees were reduced by 67% at the same time.
In fact, paying 10 times more to the node is currently irrelevant, so the savings using this feature are almost two-thirds of the total.
I expect this is the main purpose.
Even at network equilibrium, with paying 3 nodes per chunk, I’ve previously estimated that we could be looking at somewhere in the region of 50% ANT, 50% ETH for the cost of uploading to the network.
If paying 1 node became the default vs 3, then that 50/50 ANT/ETH split would change to 67/33 in favour of ANT if my maths is correct. That’s a move in the right direction for sure.
Of course 100% ANT with Native token or ANT EVM chain will be the best solution ![]()
Indeed
IIRC if a record exists only on one node then other nodes will not accept it as valid when churning. This is to help prevent certain attacks and or bringing in records from other networks. Introduced during beta networks when we saw files from previous networks appearing on a clean start of a new beta network. This was due to records on a single node being replicated across the network, and of course enough of these nodes.
Some other changes have occurred since then that would prevent this anyhow so hopefully they remember to change that behaviour or else they will have limited success ![]()
Of course this is a much more risky situation since if you upload your records to singular nodes and if one or more of those nodes go offline before other nodes churn/replicate the record to themselves then bye bye record. For a 100 record file then one node going off line wrecks the file and that record has to be uploaded again. This complicates the process since the uploader has to check the file is (still) all there 5 minutes later. @mick.vandijke
Certainly help cost wise for large files. Paying for 75 records for each transaction will be cheaper. On the order of 1/3 the cost (token and fees)
I see what you mean. But maybe they are talking about paying only 1 node but the client doesn’t report a successful upload until it nevertheless has been uploaded to 3 nodes?
I think just maybe this means I can stop beating my head against the wall, fingers crossed:
cc @riddim
I wonder what this changes for users of these data types…
But for sure the right call to go for unified behaviour SP and pointer
If I understood correctly, the underlying problem is this one below, and it should be solved first / too:
I expect there to be more than that but at least it is being worked on instead of blamed on developers.
Mutable data is a tricky problem and I think so far, has not been thought through well enough each time it has been tackled. This goes back over 18 months to the first version of Registers which didn’t work because the design was fundamentally flawed: unable to scale.
I think they need proper code review where one developer explains to at least one other developer (who works in the same area - libp2p) in depth, what the code does and how, working through the code to demonstrate this.
I don’t believe they do this, but it may be necessary here, and they certainly should not use AI to generate any of this.
Without this depth of attention and understanding this will probably go on. It’s also an example of how setting deadlines can make things take longer than giving people time to do things properly.
![]()
Bit late now, but the Billboard app on Autonomi (Findable via Atlas) is actually a nice demo what these forks do. On repeated reloads you get different versions of the pads.
EDIT: (Well I’m not sure what causes it, but I suspect the forks.)
@rusty.spork just announced on Discord that they were hoping for a release tomorrow.
Hopefully this will sort out scratchpads and we can get to reliably dogfooding with Friends Atlas Colony and others.
I like this forum but I’d rather be munching my Winalot on Friends etc
Paging Mr @happybeing
Pointers! It’s Pointers I’ve been banging on about for months but because they haven’t featured in IF apps and who knows why else, the problems have persisted.
Scratchpads have been ok, not perfect, but adequate the whole time.
Pointers have been an issue since mainnet began. If others had been using them I suspect this would have got more attention but as it was only me, Autonomi seem to have assumed my reports were incorrect, issues in my code etc.
There have now been some changes in the recent release but I’m unable to test that atm for lack of time. I think @riddim may have had a go though.
I’m still busy with other stuff so don’t expect an update from me until next week at the earliest.
hmmm - I think we may get rid of the fallback with manual counter creation on update stuff again; that would be a simplification we should do if this is correct (but hard to test because we cannot create forked scratchpads on purpose … I haven’t seen a - for real - forked one myself yet … I guess we should just believe them, remove the no longer needed complexity and scream around if issues appear at some point again
)