Noooo… another!
On Content Addressable Storage page,
“The hash of a chunk of data serves as the XOR address on the Network where it will be stored, which in turn determines the which nodes will manage it”
should read
“The hash of a chunk of data serves as the XOR address on the Network where it will be stored, which in turn determines which nodes will manage it”
lose the last instance of “the”.
In the next para
They are expected to hold replicated a data as a condition of participating in the network and having the chance to earn.
replicated a data
should simply be replicated data
Nitpicking perhaps, but I feel a slightly longer explanation would be best for
Nodes cache data when a new close node appears and they share some of their primary data store with that node.
Such that we explicitly explain (perhaps with a worked example) just how a new node with an address that is closer to one of the chunks becomes responsible for data previously looked after by the original node … I feel a diagram could be worth a thousand words here.
Also nitpicking, on the Encryption and Authentication page, consider a comma or dash between chunks
and provided
The original content can be recreated from these chunks provided we have a map of where
Further down in Keeping it Simple
When content is made public its containing folder is decrypted, meaning anyone can reassemble the chunks.
Consider a comma between public
and its
Lastly, should the final word not be Autonomi
, rather than MaidSafe
?
It does not have to be one provided by MaidSafe.
On the Self Encryption page, would a diagram of a very simple datamap be appropriate?
Or should that be a detail left for the Primer?
On MultiSig Credentials, “something you have” should be similarly italicised. (IMHO)
Also - is this the first mention of “creating a Safe”? Something which we OGs know about but is a novel concept to most .
On the Resources and Currency Supply page, I think this statement needs further explanation…
Tokens will be emitted during an upload event and become available to either the client or node operator.
How does a token become available to a client? Other than being purchased externally or as a result of an internal transfer from another client?
Fantastic. One place for docs and easy to remember the address
This is the primer now!
Seems there is some disagreement in the ranks LOL when i asked if this replaces the primer above. See
in reference to the primer still having a place
Well, this is combines the content from the primer, and the white paper, and some other elements. Primer is a subset.
If you feel there is anything specifically missing, lemmie know!
That is what I was thinking and why I asked you if the primer still had a place. But you can see the response above LOL
Does autonomi have ranks -They’re autonomous aren’t they!
There are some sections and explainers still being written, and they will be dropped in. (e.g. emissions technicals, more on double spend protection etc) but we didn’t see any reason to hold up the rest.
Plus it’ll be great once we start to get more of the developer docs up there, and also the user facing guides too
Jim, are you able to generate static versions of this and any other Autonomi sites?
If so we should talk, if not, it might be something to aim for so they can be hosted on Autonomi.
@JimCollinson is the driver here, so go with him
Hi, I noticed that docs are not linked from the project main page https://www.autonomi.com/ .
Bumping this, as I was just about to share the main page with a friend, but find it lacking without the link.
Zero-knowledge : The Network’s protocol employs multilayered encryption, protecting the privacy of users data both during storage and during transit. Nodes cannot determine the content, nor origin of data they hold or transmit, even if it is their own,
This seems misleading to me, in at least 2 ways:
-
afaik, the network is not using “zero knowledge” math/cryptography as the term is commonly used in the industry. The statement strongly implies that it does, though totally vague on details.
-
Last I checked, nodes absolutely can determine the IP address of clients that send them data unless the client is using obfuscation such as VPN, Tor, I2p, etc.
Maybe slightly misleading but wouldn’t it be specifically zero-knowledge proofs?
In terms of what is being sent it should be accurate. Also aren’t relays back with the original network design? That’s been unclear since so much has been happening. It would be nice to know if IP is scrubbed from first hop.
That is why its unclear. From replies I’ve been given they want to get Autonomi working first then address the obscuring of IP address.
Any one really wanting to scrub their IP address even from the (relay) node they contact to start upload process should get a reliable VPN anyhow. Most of the public will not be caring like we are. There are vpns that can handle 100’s of Mbps connections and if used for client uploads then that at this time is prob more than most would want.
YEs, obscuring (totally) IP addresses is a goal we must strive for. There is just no tech today that can do that effectively. TOR/VPN etc. all have issues beyond usability. They are all hackable or depend on trust on a 3rd party.
To be clear for now there is no IP obfuscation at all, however there is no centralised collection or monitoring of IP addresses. So bad actors (nodes) can do that (in their nodes, so not centralised, but distributed), but they are on their own.
Wording probably does need a little tweaking…
Might need to get to it tommorow though. Quite a lot on today