Some might say “earn” could lead people to think of the current model underlying selling data. Who knows. Either way, I’m indifferent (maybe ambivalent) between “earn” and “farm”, and can understand arguments for both. At the end of the day, I’d let user-testing decide.
3 Likes
No one is suggesting we do BTW.
7 Likes
Does Maidsafe have a parler account? It seems like it would be a nice extra marketing channel.
3 Likes
Is it an allow_joining flag or is it a node_is_full flag?
The significance being if I set this to true when I’m not full does it stop chunks being delivered to my node? How much does this flag ‘leak’ into other non-voting features of my node? How much is it just ‘my opinion’ of whether new nodes should join?
To be super clear: I want as many nodes as possible to join as soon as possible. Can I set ‘allow_joining’ to always be true, or will that cause my node some undesired side effects?
Would we expect nodes to set this to true when they are 100% full, or 99% full or 90% full?
Or would we expect nodes to set this based on some other concept of whether nodes should be allowed to join or not (perceived attempt at a sybil attack, some political movement happening on the forums, perceived fullness of other nodes in the section etc)?
Ah ok so we can anticipate a lot of newbie questions ‘my node continuously repeats the relocating message, how long will it take to join’. The continual rejoining to eventually land in a suitable section makes sense.
I’m not actually too concerned with the early farming reward. To me it’s more a conceptual juggling problem where I want to just think of the history as consistent in behavior and expectations, not having too many if then type conditions for the early network. In reality I think starting the first node at age 32 is not a big deal, even if they don’t depart after the section seems stable and even if they earn rewards.
I feel like people will probably try to track the % of nodes owned by maidsafe, which from the start will be easy but as the network grows becomes less certain. This is just like how people tried to track how many coins satoshi mined.
Overall it feels all these features are headed in the right direction for a successful testnet. Just to get the most from the test it’s important to understand the intention and implementation of these features so thanks for clarifying.
9 Likes
Good progress all. It wasn’t covered, but can I just say how much I like last week’s name change from the controversial Safecoin to the utilitarian Safe Network Token aka Safe Token. 
7 Likes
This is an allow_joiningor at least accept_infants.
Iff you are an elder and iff majority of the elders in your group set these flags new nodes will be accepted into the section. This is quite new and we need to iron out some kinks, like many new infants are not useful as they do nothing. So a couple of small issues with that.
5 Likes
It is from anonymous donor 
Everyone can donate a cover:
8 Likes
They can take that risk for sure. Getting caught will remove all age though, so the older the bigger the risk.
5 Likes
Hello there, I was wondering how does The Network verify that the proper flag is being shown by the node?
5 Likes
It does not try to, except if the node does not flag itself full and then cannot store data it will be penalised.
6 Likes
^ This is the part that I would like to know how it works. How is does that detection of misbehavior work?
2 Likes
From a community perspective have a look at questions testnets may be able to answer. If you have any thoughts please feel free to add them to that topic. I’m slowly using those ideas to create testing processes that will hopefully give us some answers.
8 Likes
When the node replies with data it goes through elders. They can detect non compliance. Also data is periodically checked (not yet coded) where a token is sent to holders and they must prepend this to the data and hash it returning the result. That allows us to see they had or could get hold of the data quickly enough to pass the test, if that makes sense?
8 Likes
Yeah, I was just thinking more about the role of the testnet from general point of view. Like should the next testnet be “impressive & stable”, almost like a launch, or should the testnets be quick, buggy, iterative steps towards launch.
(I don’t really have an opinion on this, and I try not to form one. I have realized I follow this project far too closely. But this week I have managed not to try to make sense about Maidsafe Github, which is waste of time in it’s purest form - for me. You know, like incessant checking of parcel tracking when you order something. 
)
2 Likes
The benefits of open, less stable, more frequent tests is community involvement plus the likelihood it will pick up something you miss with internal tests, but it can slow down development if taken too far. I think we are seeing the dial pushed the other way in order to optimise developer resources - so less external tests for a while, but likely to be more robust based on lots of internal tests before release.
You can do a lot of testing and bug fixing before opening things up, and opening them up early can use more resources to find the same bugs you could have caught using internal tests. On the other hand you might think everything is fine but have missed something important that would really have been caught by external testing!
So you can’t really know which is best, but too much of one or the other creates unnecessary risk.
12 Likes
That’s a subtle point that I think a lot people miss at first. There’s a non-zero overhead to releasing incremental builds because they still need to be at some level of functionality, even if that standard is lower than official builds. Even if it’s only a few hours of cleanup prior to releasing an incremental build, that adds up over time across many build releases.
Plus there’s the infrastructural overhead of managing these builds, interfacing with open source contributors, triaging and addressing smaller bugs pointed out by the community, etc. As nice as it is to make everything open and easy to interact with, it takes up resources that devs on a project can’t always spare.
Hence the intuition behind major, minor, and patch-level versioning. It is also an expression of how much infrastructural effort the developer is willing to undergo at each release.
7 Likes
Also engaging with the community to support use, answer questions, collect and triage feedback etc. That takes a lot of developer time.
9 Likes
