Launch Planning: Community Update šŸš€

Development Updates
673

Thank you for your response and I appreciate it. I have patiently read all the information in the topic and the statements of the team and the community but not all the questions were answered there.

I want to firstly point out that I very much appreciate your 18 year journey that you have been on and the work of the whole team and many of the most committed members of the community, I also understand very well that the decisions of the board were not easy and are legitimate because regulations, legal issues, commitments to investors, requirements of confidential partners etc. required it and I even expected these problems that the team had to face because this is a project different from anything that has been created so far and operates in an extremely difficult business environment. I respect these decisions and wonder how to bring the community together to support you, Bux, Jim and the team to alleviate the (understandable however) bitterness of many and avoid a rift in this fantastic community.

I read all your (and not only your) statements again after this reply and did not still find the answer to my question - how will the team lead the development of the Native Network and the target Token, will this be based on a working network with the ERC20 Token?

Basically, the answers to all the questions asked were: we donā€™t know, itā€™s unspecified, it canā€™t be calculated. This means that a network that works with Native Token will come into existence at some point, but for the time being, not even an approximate date can be given, which is perhaps why there is so much doubt among people as to whether a Native Network will ever be available.

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?

2 Likes
674

I was at Tuesdayā€™s Stages event but I had already asked these questions here so I didnā€™t want to disrupt, your speech.

675

I am still wondering about the royalty and the risks associated with it, are you committed to this approach or is it something you are still looking into? It feels unnecessarily risky, if Iā€™m correct youā€™ll have to remove the Royalty/Tax and as the network is already launched, you wonā€™t have the option of allocating a development fund from the genesis block.

User (A) being able to store data on another userā€™s (B) machine by paying a fee, is not permission-less if user (A) must pay a Tax/Royalty to a third-party (C). By definition that means User (A) needs permission of (C).

Therefore, is there not serious risk that the gate keeper (C) will be legally obligated and expected to validate the content that user (A) has uploaded is legal, and that they own the copyright? (You obviously canā€™t do this, because its encrypted, but may legally be required to)

If adding a Tax/Royalty wasnā€™t without risk, wouldnā€™t Uniswap be doing it? personally I think the reason they donā€™t is because they are unable to KYC participants in swaps and donā€™t want to be classified as a Broker.

676

That is not how a tax works. The tax receiver is not responsible for how the payer behaves, nor required to validate anything the payer does.

This is not a tax really. Its more of a development fund.

It has been there since the token was conceived. The pay the core developer, the app developer, the provider of content, it is not new. The only reason the foundation is involved in receiving the ā€œroyaltyā€ amount is because at this time the automatic control of it by the network itself is not yet possible/written and the foundation has the job to administer it to pay the developers (core & App) and other things that benefit the network

2 Likes
677

Agreed, itā€™s not exactly the definition of tax. So lets just stick with Royalty.

Is the royalty receiver who provides permission to store data on the network, in exchange for a fee, not responsible for verifying the legitimacy of that content?
They are also party to every storage transaction, would this not make them legally an easy target to go after? e.g they should have done more to stop illegal activity and not provide permission to store such content?

Iā€™m not saying it wasnā€™t, not even saying they shouldnā€™t have a development fund. What I am saying is this approach seems unnecessarily risky.

678

MaidSafe wrote the code and the code checks if the royalty is paid, which happens on the nodes.

I.e. they canā€™t censor anything, but a regulator might complain that theyā€™re making money off of the written like that code and they were obligated to check.

If they decide to hit them on this point they are helpless and I expect this to be removed.

There is another weak point in the current implementation - if MaidSafe do not release clear instructions on how to run your own Oracle and make it by default NOT added, ie. to have to manually add Oracle I also expect @dirvine to be hit by regulators ā€¦

Check out the Dev Forum

1 Like
679

Yes, there is no point in a process which has the intention of perpetually funding development. If that same process is the kink in the armour a state actor/regulator can use to end your existence. I do hope MaidSafe reconsider this royalty feature.

680

I have long expected that it would be the regulatory issues and not the technological or market issues that would be the biggest problem for MaidSafe, because launching the network in its original form for the ā€˜ordinaryā€™ user beats certain interest groups.

Therefore, I think that it would make a lot of sense to launch two networks (although I donā€™t know if there wouldnā€™t be technical obstacles), but the network with the ERC20 token will still limp along for many reasons, because the regulatory problems will come back like a boomerang, I am absolutely convinced of that.

No Safe, no wave.

1 Like
681

I like the idea of leaving current implementation of Native Token alive, as probably do all of the people concerned about delaying the work on it. It would be a nice gesture from Maidsafe. Unfortunately, this would mean maintaining two codebases and additional work, so distraction from other development. But, for sure, there will have to be a second network to test development of Native Token at some point, so maybe better sooner than later? Or, maybe this could be a community initiative? There are some skilled devs, maybe it would be possible for them to keep the network alive as a comnet?

3 Likes
682

I do not see the Foundation as a gatekeeper. They just provide software, that anybody can modify. True gatekeepers are other users/nodes, they decide about storing the chunk or not. Everyone can modify client software to not pay royalties, also everyone can modify node software to store data from people, who have not paid royalties. But nobody will do it, because itā€™s more a social deal, than requirement from Foundation.

2 Likes
683

ā€œconfidential partnersā€ā€¦ eeeeeeeek

684

If a single person modified the software to remove the royalty, the network would reject the request for storing data.

The default client is to pay a royalty, defaults are very important. A simple example would be when default browsers were shipped with operating systems.

685

The key is to run nodes, earn native tokens and transact with native tokens, because storage does have a value attached to it by the marketplace, and compute will too. Users can accept tokens when they sell service and products online, because they get storage/storewidth (and later compute) value in return, where price discovery of storage is not just capacity, its also IOPs read and write being two different categories. So the investment in node hdw and OS kit sure is purchased with fiat, then you earn a return in native tokens without the govt involved.

This means the Autonomi Network App API is key, as will be erecting a truly distributed DEFI layer on top of Autonomi Network at some point, perhaps supporting multiple existing L2 Smart Contract and VMs in theory, which is why the Spiderchain reference is important when one is looking to figure out exactly that type of L2 DEFI and more capability over Autonomiā€¦, Botanix and Spiderchain offers some clues on how to do it (rotating multi-signature Keys every epoch on the blockchain, where epoch can be equated to a set number of transactions posted to the Autonomi Network DAG without worrying about time, which will be implemented differently in the ā€˜Autonomi Network way.ā€™

If one thinks about a bit more in philosophical terms, ā€˜Store of valueā€™ ā€œunrealizedā€ in Autonomiā€™s case is represented as available ā€˜storewidthā€™ (both reading and writing to disk measured as IOPs) storewidth

storewidth

Coined by George Gilder in 2001
http://gildertech.com/subscriber_temp/Storewidth.ForbesMag.Sept.2001.pdf

and relay bandwidth measured in the same sense, possibly with tunable block sizes for different applications

Which means one, when they buy a pi5 with 8GB RAM and runs 10 safenodes with 1 TB of RAID 1 storage is actually creating a ā€œstore of valueā€ which remains unrealized, until someone uploads a file and one or more original chunks are stored by the Autonomi Network DAO algorithm to that Pi5 storage , where the DAO algo. pays the node operator a tokenized cryptographically protected amount (recording that payment as cryptographic protected record now attached to the Autonomi Network DAG ā€˜distributed ledgerā€™) to realize part of that ā€œStore of Valueā€ represented by a token now represented in their node operator wallet for exchanging part of their Storewidth to store that record (upfront the write bandwidth to disk is used, and later the download read from disk bandwidth is used more than once to retrieve a copy of the private file),

The node operator now has a ā€˜realized store of valueā€™ which is some percent of the money invested in buying that Pi5 system and turning it into a set of safenodes, so an ROI can be measured as well by the Autonomi Network node operator.

That said the tokens received by the node operator can now be spent , anytime to upload files (from anywhere from an Autonomi Client), paying one time, to receive value in the way of protected file storage on the network.

Itā€™s a Main St. Economic Model foundation for a new way of exchanging different types of value which can be expanded further, with layers as described above.

Itā€™s very much early daysā€¦ imoā€¦ this Autonomi Network journey , designed imo to nicely remove ourselves from central govt fiat money system control, running in parallel to that system, without govt interference of money supply manipulation.

The unrealized value of the Network will grow as operators invest to add more nodes of storage, and later will add as new services are added on top of more storewidth and more compute cycles , and more Memory and network bandwidth, etc, etc, etc. :slight_smile:

5 Likes
686

This could be a good idea if itā€™s possible without huge effort, but after the January launch I hope there will be an official ā€˜native tokenā€™ development branch with test networks that the community can play with to work on apps that use the native tokenā€™s capabilities.

If there were a mechanism to create ā€˜native tokensā€™ on test networks based on ERC20 Network Token balances, that would be cool to avoid the faucet issues etc.

7 Likes
687

My non-expert view is that having 2 separate networks (native and ERC20) would be a negative when both could live very nicely on a single network once the native token is sufficiently developed & tested, and there is a mechanism to swap between the two (2-way bridging or burn/mint setup).

I expect there will need to be native token test networks in parallel with the ERC20 main network, but once itā€™s tested sufficiently, integrating with the main network seems far better to me that having 2 separate networks competingā€¦ that would likely greatly de-value the ERC20 network, and if thatā€™s where all eMAID/MAID/Shareholders have their value, thatā€™s not going to make people happy, or make sense for everyone who thought they had stored data on the real network, only for it to quickly be supplanted / diluted (I say this, as I donā€™t think it would be technically possible to share data across 2 networks).

Speculation is fun though, and Iā€™m looking forward to seeing what the teamā€™s plans are when they are ready to release more detail.

6 Likes
688

Nope the receiver does not control the storage. The nodes collective do. So it seems the arguments are without merit due to incorrect assumption of foundation controlling the network.

The nodes could collectively decide not to collect royalty

Correct if the client software was modified to do this. But if a node was modded to not collect the royalty then I believe the chunk will be accepted without it. But in any case the community as whole could decide to allow royalty not to be paid. It is not upto the foundation as to what gets accepted or not accepted, it is the autonomous network and by proxy the world users

Even if the only reason is the data living on only one network. Also one network would likely end up under utilised and thus slowly (or fast) die off due to people using the popular one over the less popular one, so they donā€™t have to upload their data on both in case one ends up dying

2 Likes
689

:dart:

Me too.
What is said and how it is said will be dissected minutely :mag:

I had kicked the agogometer into the corner a week or two back. Might give it some TLC.

4 Likes
690

One thing that I hadnā€™t considered before, but I think is kind of obvious, is that when an ERC20 Network token is integrated, I expect itā€™d be very easy for ANY community with an ERC20 token (there are 500k ERC20 tokens) to start their own fork of Autonomi where their own token is the network token.

This could be terrible (for token holders) if it means some projects with a much bigger following and budget quickly become the most popular network, leaving the official network in the dust.

E.g. if an Autonomi fork that uses ETH on Arbitrum as the network token were launched, it might be hard to compete with due to scale of users whoā€™d be on it quickly, and the fact nodes could be earning ETH rather than what to most will be an unknown token.

Or, this could be amazing, if many projects dabble, innovate and solve issues that Autonomi can benefit from, and get a huge number more developer & user eyes on the project, further increasing the value & status of the official Autonomi Network.

It will be very interesting to see how this dynamic plays out, but I think itā€™s inevitable that very many ERC20 projects will add a data network that uses & adds value to their tokens once the code is out there, even if just for their internal files / documents / possibly blockchain data.

While thereā€™s a risk to token holders with this, all being well, this makes me feel that Autonomi might be about to revolutionise the crypto space far more quickly than I had previously imagined.

8 Likes
691

I used to not be so worried about forks, because of technically superior token, first mover advantage and prospering community.

But now that the door is opened to other, possibly more vital & greedy communities before the network is even movingā€¦ :cold_face:

7 Likes
692

Yeahā€¦ unless Iā€™ve misunderstood something it seems like that.

But I see massive opportunity as well as threats in this, so Iā€™m trying to figure out what outcomes are more likely, and how Autonomi might take advantage of opportunities and reduce risks.

As Autonomi have been aware of this for far longer than us, Iā€™m hoping theyā€™re well aware of this & have plans to make the most of it.

2 Likes