Continuing the discussion from MaidSafe Dev Update - March 30, 2017:
I think a lot of people here rather not use OAuth. Maybe one of the mods should create a spreadsheet, and have people sign up for it.
In the spreadsheet, each - is separated by column.
approved (checkmark (MOD ONLY)) - your name - how many accounts do you want (up to 5?) - safenet account link (for message)
Thoughts?
Did you read this part of the update? 
Right, but mods probably would get a lot of message. Which is my proposal of using google spreadsheet. Have users put their request on the sheet.
But I guess that would expose too much information. I dunno.
Might it be equally easy to spawn PMs to forum usersā¦ one per account ā¦ or at least to those accounts that have existed for a while. Perhaps one invite by default and a few invites to respected members.
I think a Google Spreadsheet might be a bit hard to manage if we let everyone edit it. I think using a forum topic and asking people to comment if they want an invitation would be fine. People could also PM mods directly if they donāt want to post in the public topic. What do you think?
Sounds good. --20charā
Ohw, weāll figure something out. My idea would be 1 topic where people can request a token using the reply button. If a mod gave a token to that person the mod could simply ālikeā the reply to show he handed out 1 to that person. Something simple like that. My personal view is not to hold any list of people with who has how much tokens and bla bla bla. This is just SAFE and we should hand them out to those who donāt like to use a google_account or something.
Indeed. Amusing that some donāt want to use OAuth and in the next breath want to use Google spreadsheetsā¦
I didnāt mean to suggest google sheet. I implied it as a mean to use spreadsheet. To me, I thought maybe no one would understand what I meant, so I wrote it down, āgoogle spreadsheetā to make an emphasis of what being said.
Ah OK misunderstanding cleared up then
Sounds good and if limited to level 1 or above we wonāt see a flood of new users trying to get account invites. This slows down abusers registering new forum accounts in order to get invites.
And this
This could be the default:
Trust Level 0 - no invites (has to be Oauth or manually requesting mods)
Trust Level 1 - 1 invite
Trust Level 2 - 2 invites
Trust Level 3 - 3 invites
Just automate the PMs in the forum, much less work for the mods.
I see no problems with anyone getting 2 or 3 invites. Especially with Alpha it might even be 5 invites is reasonable because of the time the network is up.
My reason for limiting it to level 1 is that new members who just joined do not even see the topic offering invites. This prevents google/etc indexing from even seeing the topic so internet searches do not show it.
The automation would be a lot of work since there isnāt a feature in discourse for doing it. I am happy to be corrected on this.
Itās good if the test network can be battle tested with lots of accounts created, but if itās too much to handle I guess the number of accounts need to be limited at this stage.
This seems over the top. The mods and MaidSafe being in the loop should be enough to spot any potential abuse.
Despite the popular opinion supporting invites, I have to express my disappointment in this strategy (although I do understand the motive).
Applying the word āattackā to the action of filling the network is premature and needlessly dramatic. Thereās no indication of the intent behind it, nor whether it would be repeated.
Being invite only creates a perception directly opposite to what SAFE stands for. Itās not just cosmetic or temporary; people-in-passing will hear safe is now ācontrolledā and ātrackableā and this can form a lasting impression which misrepresents this great project.
My main opposition to invite only is itās a knee-jerk reaction to a valid use of the network. The filling activity engaged a valid and difficult-to-produce state (the error seen when the network is full). As far as I know, this had not previously been triggered. Presumably this is the test working as intended, right?
If any activity taken during the last testnet is seen as ānot testingā then I feel the test network serves no purpose any longer and it may as well be private testnets. Filling the network is a totally valid use of the test network. Itās there to be used. Developing stop-gap features which detract from time developing the actual network is a bit backwards to me.
Itās amazing Alpha 1 lasted as long as it did without this sort of activity. Alpha 2 certainly will be exposed to occasional heavy use and I feel it should not be released until it can sustain that (even if thatās months away). I feel that invite only in alpha would be a disaster, leading to reduced testing and damaged reputation.
I would rather see testnets continue to be released without invites and continue to fill up, supplemented by private testnets when required.
As a compromise, perhaps the network configuration for the next testnet can be released only to a certain class of forum members for a week, then released publicly after that. This negates the need for developing an invitation system and still achieves the āopen testingā that testnets seem so valuable for.
Anyone can get a so-called invite in the launcher itself or by requesting it. Invite is perhaps a misuse of the word in this case. I do understand your point though, but do not completely agree.
If you read the test topic you will see that it indeed was handled correctly by the network. So in effect has been tested for this round of tests.
One issue you might want to consider is that test 16 is going to become alpha2 if all goes well. The alphas are more than testing they are there for people to try the network and to test their applications against. If the network is full early on then the purpose of the alpha is somewhat defeated.
The tests are not meant to test the network under ācompletely liveā conditions yet, so some control over the network is required to be able to test the areas that need testing. So it is reasonable to limit them in various ways, like the rate of filling. (500 PUTs, not unlimited accounts)
Most projects I know of (not many crypto ones though) limit who can be involved in their test/alpha/beta stages. SAFE is only limiting users to a reasonable number of accounts for the time being to help slow down the network full situation. The same is the reason for the 500 PUTs per account. Those two limits are really part and parcel of each other with the same purpose.[quote=āmav, post:17, topic:13010ā]
Itās amazing Alpha 1 lasted as long as it did without this sort of activity. Alpha 2 certainly will be exposed to occasional heavy use and I feel it should not be released until it can sustain that (even if thatās months away). I feel that invite only in alpha would be a disaster, leading to reduced testing and damaged reputation.
[/quote]
Remember the alphas have dual purpose, long testing and for developers to work against + users to play with. The limiting of accounts is really an extension of the 500 PUT limit, and hopefully by limiting the accounts we might see the PUT limit raised.
Because of the dual purpose of the alphas (long test + develop APPs against) there certainly is scope for limiting the rate of account creation.
Remember that
My point was to offload the flood of inquiries of invites to the mods. By automating the distribution of invites to trusted members of the forum, the mods can focus on checking the individual requests from untrusted ones and sporadic requests of extra invites from trusted members.
Yea I havenāt had the time to think about it much, but I definately donāt like it. It feels wrong. It feels centralised.
And why is everyone so concerned about space? Iām certain that if we the users know that space will be an issue, we will provide it. So far nobody cared because there was nothing to be concerned about. How about reduce the bandwith restriction a bit instead of this centralised approach. A single user will likely be able to offer a couple of hundred GB, if not more.
Isnāt there a better way to resolve this @frabrunelle (and others)? Or maybe Iām just looking for every excuse I can find to reduce bandwith restrictions 
I just want to see if your concerns about stability are well funded, because I think youāre wrong lol