Nov 4 Update from Bux

[Profess]

@Dimitar

Of course, it could also turn out that a network starting with fewer nodes performs better, grows faster, and attracts more users. It would be great to see an alternative network launched where these ideas can be tested — and, if proven successful, perhaps applied to Autonomi as well.

---

@neo

@Dimitar

Of course, it could also turn out that a network starting with fewer nodes performs better, grows faster, and attracts more users.

I do believe this is a no-brainer. Big uploaders look at the network and se large number of nodes being run without the storage to back them up. And they will do their due-diligence and see that its not sustainable while this is the case. A smaller more dynamic network will attract them more

@JimCollinson In August 2024, I proposed this solution and explained it several times, I foresaw the current problems and suggested that we at least discuss the creation of two parallel networks, but unfortunately I either received no response or read responses (including from team members) saying that it was a bad idea, it is a pity that the advantages of this proposal have only been recognised today:

@Profess

@dirvine

@Profess

I will ask perversely, is there really no alternative to this approach?

There are many, but time and money need considered. i.e. do somewhat or ponder everything

I wonder if it would be possible to run two Autonomi networks, and I don’t mean a bifurcation but two parallel, twin networks:

• The first would be the original network with the Native Token, which would allow development and testing as originally conceived, the team could develop the token on it and innovate, eliminate problems and bugs etc, and developers could test and develop applications on it, it would not be burdened by regulation and legal requirements because the token would not be listed anywhere and would have a clearing value, and it would be created by all those willing to create it who are looking for the utility value of the network, not just tokenomics, you could say it would be a technology sandbox, and this would facilitate testing and experimentation without complicating the work and operation of the commercial network (ERC20),
• The second would be a prepared network with the ERC20 Token implemented, meeting adaptations to regulations and legal requirements, which would allow partners’ expectations to be met and would be developed in accordance with the adopted tokenisation, with TGE implementation etc., as in the Native network, the team would carry out development work and developers would develop applications using the adopted tokenomics,

Sure the idea seems ridiculous and maybe the thought is just very silly but it occurred to me:

• perhaps separating the work on the Native Token network and the work on the ERC20 network would allow the objectives to be achieved more easily, as each network would have different scalability and technological priorities, I am not in a position to assess this, but numerous statements indicate that the changes made to the ERC20 network will cause many complications, which will probably not facilitate the work on the objectives set,
• the Native network could use the dev forum, so as to simplify the flow of information, transparency of work etc, and the work on the ERC20 network would remain in the community forum, I know that for the team this could be some discomfort but it is possible that overall the transparency of work on individual problems would be more beneficial though,
• As the two networks would be twinned, all errors detected and updates developed could be mutually implemented in the common part (i.e. the data storage layer),
• the costs of the Native Network appear to be small for the project, as the infrastructure is created by the users, and the scale of the network would ultimately be an interpretation of its sophistication and market assessment, the team would have freedom in many areas of the work, and with the risk of attempts to bifurcate the network greatly reduced, full control would remain in the hands of MaidSafe,
• I don’t know what the future of these networks could look like, but the market could judge for itself which solution is better and which it wants to use, I have no idea if this is possible and it’s just speculation, but - maybe it would be possible to merge these networks in the future, since the storage layer would be exactly the same and each network would have its own token with its own genesis, while in the current assumptions about the future there is a flexible option offering the choice of Native or ERC Token,
• no one could accuse you or the Board of Directors that the original Native network has been abandoned for any interests, and that it will not be developed.

I don’t know if I’ve drifted too far away with this idea but could it at least be worth looking into?

[neo]

@Dimitar

On the other hand, if the data is indeed missing, that would mean we’ve lost 10 months of progress.

Not really, there has been a lot of learning, a lot of development of the code that could not have been done so quickly with beta network being reset so often.

The worse case is a network reset, but with only 0.004 chance (0.4%) of loss then its recoverable in the sense that some files have been lost but with so few files on the network people can restore lost records in due time or just absorb the loss. The real indicator of failure will be what happens from now with the data. But at least there is an acknowledgement of what people have experienced in actual figures.

If there was PBs of data on the network then it would be so much more serious

[Dimitar]

I was referring to the progress in building faith. The human psyche is affected by this factor, so personally I wouldn’t move my company data to the network before 1000 days have passed without data loss/loss of data access.

---

Check out the Impossible Futures!

[neo]

As part of a multi-level backup methodology then once they remove the issues causing this situation then it would be suitable as one of the backup stores. Many copies of the backup and even tapes are not 100% so there is always a potential for one backup to not be 100% complete. Same for Autonomi, if there is chance for minor loss then its not a deal breaker. Backups would work on chunks and not file based so one chunk missing would be covered by error checking/recovery in the backup mechanism. Multiple chunk also may not be an issue. But the backup system has to be able to deal with occasional file loss within the backup.

So there is still cases where businesses will still be happy to use Autonomi. It’ll be up to years before there is turnkey business applications like POS, accounting, etc. But backup is a simple use case

[Profess]

@neo

The worse case is a network reset, but with only 0.004 chance (0.4%) of loss then its recoverable in the sense that some files have been lost but with so few files on the network people can restore lost records in due time or just absorb the loss

We still do not know what % of data has been lost, as Nic or anyone else on the team has not clarified what 0.4% data loss means and what part of the network has been scanned so far.

@Nic_Dorman

Scanning so far shows that there is data loss of 0.4% (*) on the network.

so it may turn out that the final data loss is greater after all.

[JimCollinson]

@Profess

@JimCollinson In August 2024, I proposed this solution and explained it several times, I foresaw the current problems and suggested that we at least discuss the creation of two parallel networks, but unfortunately I either received no response or read responses (including from team members) saying that it was a bad idea, it is a pity that the advantages of this proposal have only been recognised today:

Proposals have to be both technically plausibly achievable, and move us forward, sometimes through an incremental and obvious step, or sometimes through a leap — but they have to be within the constraints we have, and prioritised as such.

Members of the community sometimes say they feel we ignore them when we don’t reply to things they are suggesting. But we have a lot of people suggesting things all the time. And we just can’t respond to them all, heck we can’t respond to most of them. It would be a full-time job if we did . And in responding, pointing out the nuance, or the technical constraints, it opens up more suggestions and alternatives, and further questions etc… and again, this is all cool and interesting and sometimes fun, but if we did this with every suggestion, nothing would get shipped.

And then again, we’re also an open source project — so people can also go further than just suggesting things and even contribute code directly!

So again, we hope people don’t feel ignored, but then we’re not in charge of their emotions. We’re just moving forward, progressing a complex project with a live network now in market.

[Profess]

@JimCollinson

Members of the community sometimes say they feel we ignore them when we don’t reply to things they are suggesting. But we have a lot of people suggesting things all the time. And we just can’t respond to them all, heck we can’t respond to most of them. It would be a full-time job if we did .

I did not write that I felt ignored; on the contrary, I wrote that I also received a reply, but it was negative and without any justification.

I am not one of those who constantly complain and they are criticising everything. I greatly appreciate your hard work in many areas and I understand perfectly well that everyone has their private life and limited time to devote to communication on the forum/Discord. I also appreciate the fact that there is constant interaction between the team and the community, even if it is sometimes not very constructive.

My proposal was obviously mainly concerned with NT at that time, but I mentioned that it was not difficult to predict certain network problems (I would be surprised if there were none) I think instead of writing about the ERC20 token in numerous threads, it would have been possible to calmly discuss the idea of two networks (and, at the same time, give the community/users the satisfaction that their opinion matters).

Who knows what the conclusions would have been… it is possible that the team would have done it their way anyway, but perhaps they would have considered an alternative idea that would slowly mature for implementation…