Launch Planning: Community Update 🚀

[drirmbda]

I’m thinking of initial or gradual token distribution, in a fair way.

[loziniak]

Ok, I get it. Farmers will get tokens from uploads, but where uploaders will get the tokens from, right?

Perhaps if the tokens had to be distributed based on declarations, it would be better to distribute them to people, who want to upload something, than to these, who want to run nodes. Farmers will get tokens in a process anyway.

My first, fast idea – distribute tokens to people, who took part in this thread: Uploads to the network

Or, we could distribute tokens to holders of eMAID, who would post on the forum a message signed with their private key, together with an Autonomi address they want to get the tokens onto.

More ideas welcome Perhaps this discussion should continue in a comnet thread?

Edit: discussion continued here: https://forum.autonomi.community/t/comnet-token-distribution/40423

[neo]

@loziniak

More ideas welcome

Just enable the test for the exchange from eMAID and don’t forget the 90% still in MAID

[loziniak]

@neo

Just enable the test for the exchange from eMAID

You mean the mechanism, that was planned for launch? Is it ready?

[neo]

Go to github and there is evidence of the code accessing the address balances. Its been a while since I saw t so cannot quite remember where I saw it. Prob in the wallet code

[Profess]

Thanks for the clarification, I have read your posts, also about doing away with the DAG component in order to speed up the work on the native token and I think it is a good idea but as David’s statement shows it would not be a solution without problems.

On the other hand, David’s work on a new type of transactional data need not be at all a constraint on the emergence of a parallel network, perhaps even testing this solution should also be easier on a network that has no constraints.

@neo

If there was two networks then maybe after a lot of testing of the merge code it might be possible. As to the moral/legal objections to who pays/paid what, well thats another can of worms to be argued about. But luckly that cannot happen since there cannot be a parallel network until the native token code is completed and then its just an upgrade to the network s/w at that time

It seems to me that bringing a highly innovative network like Autonomi to the mainstream will require a non-standard path of work, which in practice means that for the network in its original form to ever be deployed in the broad market we face a big battle with the current laws and regulations, and that means we have to find a way to play our opponent in a legal way…, how to do that?

It is precisely the two parallel networks that allow Autonomi to be deployed to the market and develop towards achieving scale, testing, creating applications etc…, while at the same time you can create without compromise the Native token, new transaction data types and other solutions that may not meet today’s regulatory framework. This, in my opinion, would be the greatest benefit of implementing two parallel networks.

I think your answer brightens the picture and now the roadmap is much clearer, but is the proposed parallel network an acceptable solution in your opinion?

[DavidMc0]

@Profess

is the proposed parallel network an acceptable solution in your opinion

In short, how would your proposed parallel network differ from being a native token testnet? Sounds very similar to me.

[neo]

The biggest issue I see is divided interests and attention. You end up creating a divided community and usage of the network. And one in 2 years (just a imaginary figure) when the native token is finally ready people will have adopted their network, and not be interested in the other.

In my opinion this division will cause problems, real problems. With some refusing to “merge” with the other network, if merging is even possible with the differences in development paths. Not to mention the complaints about how one network did did not pay to get all that great and better data and got it for free. (In a collective sense). The uploaders complaining and the node operators in the better network complain about the efforts they put into their network now benefits the other network’s node operators who in their minds were freeloaders.

Best to have the ERC20 network running and the native token / transactional data type progress with test nets.

Also what would your parallel network be, a ERC20 token network and one with a incomplete (non-native) token, which we are now using that will be replaced with the native token.

It really doesn’t make all that much sense once you get to actually thinking of how to make it work.

[tobbetj]

if a second network is launched then they will in some way cannibalise on each other, might not be good early on when trying to gain traction.

There are many questions and strategical problems to think about before a potential attempt trying to launch a second network.

[Profess]

As I understand it, the test native network will be an internal labo network where only the team will test, moreover as Neo wrote it will be iterated many times, meanwhile the parallel network would be a network run to full capacity and developed by the team, developers and users who want to help/learn etc but would have some preconceived limitations that would allow MaidSafe to control the development of the network (e.g. protect the network from hostile hard fork).

[dirvine]

My viewpoint is this.

• The transaction data type plus sybil avoidance is in place in the code (so it’ there)
• The ability to use dynamic parent checks (i.e. go back and check X parents depending on transaction complexity) is a client side issue. So essentially it’s there
• Wallets etc. are not there, but are client side things
• Exchange integration or bisq or whatever does not exist

So this is the state of play. From here I see

• Launch the network to start getting traction and importantly allow folk to economically benefit immediately
• As the network grows we start seeing use cases

A use case I see is the transactional data type being used for

• Currency
• Exchange of resources (neural network, weights and so on)
• Voting systems

And much more. Each of those can be designed, implemented and tested with the real world on a real network with real users.

If a currency appears and is well supported then people may start to say, Hey this is way faster and allows micro/nano payments for many things like tipping, data storage, digital content subscriptions and more. At this stage it gains traction and with enough traction it becomes a compelling currency for the data payments part of the network.

During those times there are likely more inclination for fiat on/off ramps and this part seems critical. If people can start to interact daily with such a currency then it gets real.

If none of that works then the currency, even technically better than existing, is just not good enough, wrong time, wrong apps or whatever, it just is not enough.

Rather than tying that to the data network, the path now is separate that innovation from the data security innovation and get data sorted first. Then we can move on to a currency innovation.

So I am not bought into the all or nothing approach, I think the current approach is good. If folk then build on the transactional data type and get traction then it’s amazing and great for humanity. But let’s not link these two innovations together in an all or nothing charge. Let’s walk carefully into this battle and choose wisely. No knee jerk, no big red button, but carefully navigate the reality of modern life and where we are and hope we anticipate where we are going effectively to progress the tech and the goals of privacy security and freedom for all.

Then of course, like it or not AI is happening and very quickly. That change can be great for a highly concurrent transactional data type and also could significantly change data management and knowledge.

[Profess]

I have tried in my earlier posts to spell out all the differences between the two parallel networks and the benefits of this, while I agree that there are many issues that need to be fixed but these are questions for David and the team, I have only put forward a proposal for a solution that could bring more benefits than problems and would allow us to stay true to the original SafeNet premise.

[Toivo]

@dirvine

If a currency appears and is well supported then people may start to say, Hey this is way faster and allows micro/nano payments for many things like tipping, data storage

I can’t help but feel the transaction data type is working against:

safecoin is the crypto currency of the SAFE (Secure Access For Everyone) network.

… meaning moving from “the crypto currency” towards “a crypto currency” of the network.

Source for the quote above.

[happybeing]

@Toivo

But now that the door is opened to other, possibly more vital & greedy communities before the network is even moving…

It would be ironic if in abandoning the biggest single advantage - the native token - in order to give investors on and off ramps, those investors lost everything.

Personally I’d be more annoyed that this left ERC20 as the long term token (which I believe is very likely one way or another now) because that will do far more damage to the fundamentals than Autonomi have admitted. The network will not be for everyone without the native token IMO and I still do not see how two tokens can exist - because almost all nodes would have to support both and most would just stick with ERC20 once it is established.

The whole thing has not been explained so it is hard to accept this has been thought through.

Questions like this need to be addressed in detail. “Trust us, it will be fine” has already proved to be false in multiple respects.

It’s not technically too late to change tack. The question is whether there are reasons we’ve not been told that prevent it.

[DavidMc0]

@dirvine

If a currency appears and is well supported then people may start to say, Hey this is way faster and allows micro/nano payments for many things like tipping, data storage, digital content subscriptions and more. At this stage it gains traction and with enough traction it becomes a compelling currency for the data payments part of the network.

Do you mean that when use cases of the transactional data type become compelling enough, it’ll make sense to go live with a Native Token for data payments that uses the same supply as the Network Token, but with the advantages the transactional data type brings?

What you said here makes it sound like in your view, the first ‘Native Token’ may be created by anyone and have nothing to do with the Network Token supply, which could completely debase the Network Token if it were faster, cheaper to use, and made the Network Token obsolete.

It also sounds like in your view there should be no priority for the team to deliver ‘Safecoin’, which was always a core part of the plan, and a big part of what most people have invested in to date.

I hope this is a misunderstanding of what you’re saying, as that sounds like a disaster for any investors / holders of eMAID/MAID/Network Tokens etc.

[DavidMc0]

@happybeing

I still do not see how two tokens can exist - because almost all nodes would have to support both and most would just stick with ERC20 once it is established.

If there’s an equivalent to a ‘Bridge’ between the two, and node software is updated to accept Native and Network token, why would it be hard for them to coexist?

Nodes should be happy to accept either if they are easily interchangeable, and all node operators would likely be keen to support the native token that could add loads more value to the Network. If demand for the ERC20 token tailed off over time that shouldn’t be a big deal once the Native Token has sufficient traction.

@happybeing

The whole thing has not been explained so it is hard to accept this has been thought through.

Yes, I look forward to hearing more… the team has said they’re preparing a paper with all the details, so we’ll see what that brings when it comes.

[happybeing]

I don’t see how a bridge between native token and ERC20 can be implemented. They are different beasts so that would need to be explained, developed and become adopted. It won’t just happen even if it’s technically feasible.

There are a lot of steps required in that and also in David’s hopeful path from ERC20 to native token acceptance.

My special skill is seeing the problems with things, David’s is optimism and vision.

So while I love David’s idea, I would not bet on it.

[loziniak]

@neo

there is a new data type called a transaction data type

This is actually an old data type, and it’s already there:

@dirvine

My viewpoint is this.

• The transaction data type plus sybil avoidance is in place in the code (so it’ there)

@neo

For the native token code work there will testnets.

I haven’t seen any info from the team about it. That’s our speculation.

@neo

I would expect the native token code will be using the ERC20 code base with modifications being done to parts of the code that can be reincorporated in a automated manner (ie conditional compile time code etc)

Again, a theory. It’s already been heavily modified, the changes are not a simple switch, but go deep into the project structure (eg. Nanos are renamed to Attos). So automating is probably not possible at this moment. Perhaps in future it would be possible, but again – nobody has told that. Even David in his recent post seems to avoid this topic.

[DavidMc0]

@happybeing

They are different beasts so that would need to be explained, developed and become adopted. It won’t just happen even if it’s technically feasible.

I don’t know how either, but I hope the team and community find options quickly.

The fact you can wrap BTC on ETH and ETH L2s gives be hope that 2 different beasts can be bridged, but of course Bitcoin is closer to Ethereum than the Native Token will be.

[dirvine]

@DavidMc0

Do you mean that when use cases of the transactional data type become compelling enough, it’ll make sense to go live with a Native Token for data payments that uses the same supply as the Network Token, but with the advantages the transactional data type brings?

I am not sure what the exact question is here. (sorry)

@DavidMc0

What you said here makes it sound like in your view, the first ‘Native Token’ may be created by anyone and have nothing to do with the Network Token supply

I think “Native Token” is very much confusing things, do we mean erc20 native or a transaction data type as native etc.

Where I am coming from is this transactional data type allows currencies (as an example use case) to exist. If people create such with them and they take off then it’s amazing.

@DavidMc0

which could completely debase the Network Token if it were faster, cheaper to use, and made the Network Token obsolete.

Again I am a bit confused. If a breed of extremely fast secure and concurrent digital cash can be created then all kinds of things will happen.

It would make sense the network (it’s not not MaidSafe’s network) would switch to that. How? there are a ton of ways that can happen, but I am not thinking we need to design that cutover here or anytime soon. But the cutover is simple compared with getting such currencies usable in the mainstream.

This is not build it and they will come, it is more difficult IMO, the huge hurdle is political and not technical. Seeing Ava have to give up on a non blockchain and better tech says a lot. We cannot ignore the difficulty there. It’s NOT being technically even 1000X better, it’s much more that than.

@DavidMc0

It also sounds like in your view there should be no priority for the team to deliver ‘Safecoin’, which was always a core part of the plan, and a big part of what most people have invested in to date.

Not at all, safecoin was not always what folk bought into IMO but some will have.

Surely data matters here? Security privacy and freedom for all digital use?

@DavidMc0

I hope this is a misunderstanding of what you’re saying, as that sounds like a disaster for any investors / holders of eMAID/MAID/Network Tokens etc.

We are looking at ways to launch and get economically positive returns for fatly these people. If w turn round and say, “no it must be safe coin” and there are no FIAT on/off ramps then that’s the point where all investors are wiped out.

They stay wiped out until there is a fiat on/off ramp and that might never happen (Ava spend millions trying to get listed) and no economic advantage for nodes running, no way for folk to buy storage credits and the rest kills this project.

So in terms of safe coin, what I am repeatedly saying is allow it to happen, not only from the team, but the tech is all in place for anyone to push that currency. If some team makes it work and it takes off then we all benefit.

Or we screech to a halt and get the the ready with no way to pay out investors in the meantime. No deliverable date as it’s no longer a tech issue (as it’s not) but we wait on politics changing and exchanges listing this unknown coin and so on.

I know I am not getting through, but it me we go and go now or stop and tread water for an unknown time.