Always brave itās my nature, I think my country makes us like that
I just posted text in the in house channel regarding this.
" we could all get agreement on the crdt/dsb etc. pattern and how that fits with SectionChain (BLS) as a Section Actor?
If we get the pattern sorted for routing then all other data types are simpler. So we have
Secured CRDTās
Lazy messaging (to handle out of order anything)
Clean definition of Actors
Then our whole code base can be analysed and where we have data not using these patterns then we consider that data inconsistent unless we can prove itās not and prove it with no edge cases (se Blobs/SectionChain etc. are OK).
This can give us the implementation rules of the network. It lets us then define test rigs (no seeded RNGs etc.) so proptest/fuzz testing and also firm down the Error handling etc.
I hope this gives us provably correct everything and an impl anyone can recodnise to extend it."
So we are at clean up and code check all algorithms are consistent. i.e. now we can formalise the methods. So while we may have internal testnets working again (Friday) and maybe the community very soon. I am focussed solely on ensuring formally provable rules on the whole code base.
This member of the community is happy that they are getting on at maximum speed, and prefers that to spending time updating the website and docs which few people will encounter until thereās something to attract attention.
This is , I think, mostly due to the team consisting of 98% engineers and one admin person to make sure wages get paid and absolute essentials.
Unfortunately the folk who would normally have looked after these documentation/communication functions are no longer around.
It MIGHT be something the community could pick up on, but I suspect whoever volunteered to do it would spend so much time asking David and the others āIs this what you really meant?ā etc that we would distract them from what they seem to be geting on so well with.
So maybe we just have to shut up and wait, cos by trying to help we actually delay the introduction of a testnetā¦ Incredibly frustrating but as I said earlier, we are well over the Florida stateline and heading directly to DisneyWorld. Traffic remains light. Some say signs for Disneyworld long-term parking have been spotted
I get that all the effort is going into the build, but also whatās the point of a weekly update if the context of the work done, and remaining work is so difficult to follow because thereās no fixed point relation to a roadmap (even if it sounds exciting, Iām not sure how excited to be!). Grouping things into high level goals (like Davidās last post), takes only a couple of minutes. and can be just included at the bottom of the weekly updates. Now thereās no need to update the websites or documentation. Because we are all aware in plain English what the overall outstanding goals are.
Updating the website might be something a community member could do. Shouldnāt be too hard I wouldnāt have thought. I have a profound dislike of out-of-date documentation and tend to use the state of public documentation as a proxy for the health of a project, and Iām sure Iām not alone in that. Iām crazy busy at the moment otherwise Iād offer to have a go.
And Iād help you - as I am sure would many others, BUT none of these docs could be released without getting the technical approval from team members - who IMNSHO should just be left alone for the next week or two - I feel we are really getting to the tickly bit now.
There are 2 types of documentation. One kind is internal, that is to assist the devs in keeping track of what they are doing. That you can do however you want.
External documentation is for the public. In a fast moving project, there should not even be much external documentation. Having to update after each little change slows down the project and people always worry if the documentation isnāt updated. Bureaucrats love documentation and that should tell you how unimportant it is. I would cut out all the documentation for the parts of the project that change and provide only very high level objectives that are easy for the public to understand. You can always provide more technical details on request.
I think the fundamentals are the critical high level docs. Then there can be levels of more technical docs below that. I really hope the recent work will simplify all of this a lot.
Modern Silicon Valley companies will generally do docs as code so community can PR updates where needed and take the burden of the core team and have it auto deploy via pipelines upon merge. This is essential for quality public facing websites with docs these days. I really like how konghq does theirs for the API Gateway product: GitHub - Kong/docs.konghq.com: š¦ Source code for docs.konghq.com website.
Building on that, just want to point out that the websites are open source as well as the rest of the project. If any of the docs arenāt current/detailed enough for your taste and you are inclined towards web development, thatās the link to the safe network tech GitHub page for anybody reading this whoās interested
It is better to have working software without GUI, than non-working software with GUI. So I prefer to see it just working. Without any requirement for UI at this moment.
Working (without crashes) decentralized network is a huge milestone. Even if it will have usability problems and large parts of it will require rewrite.
A trivial search replace of "vault with ānodeā .
Obviously the references to PARSEC will require more work.
DM me if you want included in the team that netlify has encouraged me to set up or just grab this and make your changes.
Im very busy at the moment and donāt have the time that Iād like to do this properly.
This is something I feel maidsafe needs be responsible for. Iām keen to help out with the safenetwork.tech website but feel managing the website sorta comes with the territory of running a project so have not submitted PRs etc (even if itās just reduced to a geocities style āunder constructionā page Iād be fine with that, but I guess thatās a little too drastic and not representative of the actual progress being made).
One thing that has bugged me for a long time (just a quirk though) is the site is blank/empty with javascript disabled (it depends on loading react). Using react-static leads to strange stuff like the content residing in javascript, which is really odd to me. I reckon it makes a lot more sense to do the site in a static generator like Cobalt or Jekyll or Hugo etc. I started transferring it from react-static to a less javascripty static site platform, retaining the sass and separation of components etc, but felt since maidsafe deploys the site they probably are in the best position to maintain it so itās not wise to pursue it further without at least some discussion.
Overall it feels like thereās not much that needs to change on the site to bring it up to date with the current progress.
Remove the social media links
Remove the press kit stuff
Remove parsec
Remove the newsletter signup form
Add crdt and at2
Anything else?
fwiw parsec is in these places of the source code:
$:/tmp/safenetwork.tech (master) $ grep -ri "parsec"
src/constant.js: parsecWhitePaper: 'https://docs.maidsafe.net/Whitepapers/pdf/PARSEC.pdf',
src/pages/HowItWorks/content.js: 'These rules ensure that computers reach agreement on what is and isnāt allowed, and the order in which they happen. Decisions are made by computers in standalone Sections that have a history of good behaviour and thanks to a cutting-edge DAG-based consensus algorithm called PARSEC, the Network is guaranteed to reach agreement despite vast numbers of events taking place simultaneously every second around the world.'
src/pages/PressKit/content.js: id: 'parsecWhitePaper',
src/pages/PressKit/content.js: title: 'PARSEC Whitepaper',
src/pages/PressKit/PressKit.js: parsecWhitePaper: {
src/pages/PressKit/PressKit.js: url: CONSTANT.downloadLinks.documents.parsecWhitePaper,
src/pages/FAQs/content.js: question: 'What is PARSEC?',
src/pages/FAQs/content.js: 'PARSEC is the consensus algorithm which allows decentralised networks to reach agreement on a series of events, actions or activities in a secure and reliable manner that is not only highly asynchronous but also Byzantine Fault Tolerant. In other words, the Network is mathematically guaranteed to reach consensus (provided no more than one-third of nodes are malicious or unresponsive for whatever reason).',
src/pages/FAQs/content.js: '[Read the whitepaper](https://docs.maidsafe.net/Whitepapers/pdf/PARSEC.pdf)',
src/pages/Roadmap/content.js: feature: 'PARSEC',
src/pages/Roadmap/content.js: 'Ensures that a global decentralised, permissionless Network can reach agreement about events that are permitted and the order in which they are to be recorded. A DAG-based algorithm that achieves the highest standard of security possibile, invented by MaidSafe in such a way that it ensures it is mathematically certain that every part of the Network will reach eventual agreement. In Fleming, weāll be releasing a highly asynchronous version of PARSEC, with full asynchronicity to come later.'
src/pages/Roadmap/content.js: url: 'https://hub.safedev.org/parsec/'
src/pages/Roadmap/content.js: 'Each node on the Safe Network is given an age by the Network itself. The node age increments every time that a node moves between Disjoint Sections, with only the most senior (Elders) entitled to vote during the PARSEC consensus algorithm.',
src/pages/Roadmap/content.js: desc: 'Preventing malicious nodes subverting the consensus algorithm, PARSEC',
src/pages/Roadmap/content.js: url: 'https://github.com/maidsafe/rfcs/blob/master/text/0050-malice_in_parsec/0050-malice_in_parsec.md'
src/pages/Roadmap/content.js: desc: 'Replace our concrete coin with a common coin to make PARSEC fully asynchronous',
By doing it ārightā I meant pretty much your list
All I am after is something that is somewhat up to date - development is proceeding at such a pace that the website can never hit that moving target.
Iād be happy if safenetwork.tech reflected the state of the project at say end Sept -not end March 2020 as seems the case at the moment.
Iām for offering a small bounty to tick off your bullet points now in 7-10 days timeframe rather than a full rewrite. That can come later, hopefully following a rise in the price of MAID post Fleming and the possibility of the company (re)hiring staff to do this work,
Once safenetwork.tech has had a makeover we could organise a tweetstorm where we can tweet the following 20 fundamentals from the primer
## 20 Fundamental Principles of the SAFE Network
There are a number of core ideas that have driven each stage of the design of the SAFE Network. These can be distilled into the following 20 fundamental principles.
The SAFE Network will:
1. Allow a person to create an account and login anonymously and without intervention.
Creating a new account and logging into the Network will never require a third party.
2. Enable users to securely and with no controlling intermediaries share information and messages.
The SAFE Network will never allow third parties to either read or store the information sent by a user without that userās consent.
3. Allow the transfer of the Network currency Safecoin to any user free of transaction costs.
4. Enable Users to anonymously create and share data worldwide. The Network will always ensure that the user has the ability to send transaction messages and posts with a temporary single-use ID that is not linked to any known identity on the Network.
5. Let anyone browse content anonymously and free of charge and without the need to create an account.
6. Allow users to associate multiple identities with their account.
7. Let users utilize any of their identities to send/receive Safecoin.
8. Store data in perpetuity. All public/published data on the Network will be immutable and available on the Network indefinitely.
9. Never require passwords to be stored on the Network or on machines used to access the Network.
10. Allow any user, on any machine, to access the Network leaving no trace of their presence or activity on the machine.
11. Scrub Client IP addresses from the first hop.
As soon as you have connected to the network, your IP address is wiped.
12. Only accept more Vaults (networked storage provided by users' machines) when it needs them.
This is to prevent a bad actor from flooding the network with poorly performing or malicious Vaults and also to enable the Network to balance its resources automatically according to demand.
13. Increase farming rewards when it needs more resources (e.g. more Vaults to increase storage capacity) and decrease rewards when resources are plentiful.
This is the primary mechanism for balancing supply and demand.
14. Rank nodes over time and increase trust in higher ranked nodes.
The aim is to maximize performance and defend against certain attacks.
15. Not have servers!
The SAFE Network will never rely on servers (as the term is traditionally understood) as to do so introduces a third-party weakness that undermines the entire Network.
16. Digitally sign all transactions.
To ensure that the transactions have been authorized in accordance with the rules of the Network.
17. Ensure that Client-to-Client direct messages (i.e. those not transmitted via other nodes in the Network) are free.
18. Never use time as a network tool.
There can be no concept of time in a truly decentralized network without reaching out to centralized servers and services.
19. Only use encrypted services and encrypted traffic.
20. Allow real-time upgrades in a secure manner.
The Network will refuse upgrades that could break it.
Each of these points - with tweaks to #12 and the usual twitter contractions - could make a good stand alone tweet - with sufficient chars left to put a link to safenetwork.tech and a selection of carefully chosen hashtags on the shorter points
itās my nature, I think my country makes us like that 
