https://github.com/maidsafe/rfcs/tree/master/text/0025-launcher-direct-data-api

https://github.com/maidsafe/rfcs/tree/master/text/0017-launcher-dns-api

https://github.com/maidsafe/rfcs/tree/master/text/0009-MPID-Messaging

https://github.com/maidsafe/rfcs/tree/master/text/0013-immutable-data-naming

Some suggestions to help App developers understand this (including myself :-))...

Add a stand alone description for each API, that doesn't assume context or terminology. Define any terminology or abbreviations used - for example:

Description should make clear: What is a service? What is the effect of registering a service? What does this permit me to do once registered? Do I have to register all services (is "www" a realistic example) or are some built in?

What is DNS? I think this has lots of scope for confusion because it is like the existing DNS but different, and it isn't clear what is similar and how they differ. And those who don't know about DNS and services will be absolutely lost.

Also, I think having "www" in both the example service and at the end of "/path/to/an/existing_directory_www" is confusing. Especially because the comment makes reference to the "last token" of the latter, without clarifying what this is in the example (I assume it is referring to "existing_directory_www" but I'm not sure, and it could will be taken to mean "www" which we've hinted is "special" just above).

I'm not sure if this is the place to start this off but can't find any discussion so far - maybe because this is still a PR? Sorry if I'm jumping the gun :-)

The scheme seems very sound and versatile and well thought out (although I can't comment on implementation as a RESTful server as I don't know the details of this).

I have some observations that relate to earlier proposals, including a couple from myself. These are not criticisms, but things I want to mention as relevant or state for clarification:

• Dynamic Web Apps/Sites: I think that it would be possible to extend this approach to provide for dynamic website support in a similar way to that proposed in my RFC PR SAFE browser plugin URL handling / dynamic HTML on client side. The purpose of that would be to allow a single URL to specify both the HTML file needed for rendering something, and the data object(s) it will render. For example, in the case of a blog these would correspond to the HTML that renders a blog post (e.g. the URL for blogpost.html) and the particular blog post content (e.g. a URL containing a post-id). I suggest that we consider if there are any things needed to ensure this could be added in a backwards compatible manner, and whether it is worth including from the start if it is not too onerous to do so - unless of course an alternative scheme is available, or we make a decision not to support this kind of web application. I'm assuming we do want to, but am not aware of MaidSafe's thinking on this kind of application/website.
• Invalid URL Handling: this scheme, using a TLD of ".safenet", would I think make it impractical to have a SAFE style URL that defaults to a real but conventional website address as in the forum discussion SAFE URL: use a real internet domain such as safenetwork.net because that would require us to own and enable ".safenet" as a real TLD which I think is not feasible due to cost (~$200k I think).
• TLD Vulnerability: related to the preceding point, what do we think about the possibility that someone (e.g. a government agency) might choose to register the ".safenet" TLD as a means to snoop on users visiting SAFE URLs without the RESTful server installed/running, or to set up a rival domain space that confuses users, and so on. A way to avoid this would be for the MaidSafe Foundation to register the ".safenet" TLD, but that would be expensive and I would think difficult for the Foundation to justify.
• safe://" format URLs: As I understand it this scheme alone would not allow support of "safe:" style URLs because a browser without a special extension would treat them as a search string and not invoke the RESTful server. If at some point we provide browser plugins or extensions that can intercept "safe:" URLs and forward them to the RESTful interface they could be supported, but the "cost" of doing this would be confusion through multiple URL formats which would need to be considered.

https://github.com/maidsafe/rfcs/tree/master/text/0023-immutable-data-type-naming

RFC > https://github.com/maidsafe/rfcs/tree/master/text/0034-immutable-data-name-function

RFC > https://github.com/maidsafe/rfcs/blob/master/text/0030-secure-node-join/0030-nodes_key_as_name.md

https://github.com/maidsafe/rfcs/tree/master/agreed/0009-MPID-Messaging

The following two links have the same link text "# 0018 Launcher as a local server"

https://github.com/maidsafe/rfcs/blob/master/text/0018-launcher-as-rest-server/0018-launcher-as-local-rest-server.md
https://github.com/maidsafe/rfcs/blob/master/text/0018-launcher-as-rest-server/authorisation_api.md

And the links to the dns_api.md and nfs_api.md are missing.

Rendered

Please help to discuss and improve / debate this rfc
https://github.com/maidsafe/rfcs/blob/master/proposed/0000-Remove-Transaction-Managers.md

RFC > https://github.com/maidsafe/rfcs/tree/master/text/0027-append-by-all-structured-data-type
Forum > https://forum.safenetwork.io/t/rfc-dynamic-data-support/8471

https://github.com/maidsafe/rfcs/tree/master/proposed/0023-immutable-data-type-naming

I understand and totally agree that the way rust handles their RFCs is pretty unclear regrading the state of each RFC and see the reason behind creating the folders. However, this makes it hard to link to any RFC as their link throughout the development cycle changes significantly, one reason why RFCs can't properly link to each other directly within the document.

Coming from the Python PEP Process (which the rust RFC process is largely inspired by), how about adding a top-level field status instead like they do (and maybe one that mentions the release version once it was published)? This way, each RFC could stay in one place and be linked to.

In regards to have a good overview, I'd suggest to do it similarly as Rust does it and just link the RFCs from the Readme.md, but as sections depending their status (ordered by number, optionally descending). Changing the status then needs to be PR which also moves them from one section to another.

RFC > https://github.com/maidsafe/rfcs/tree/master/text/0035-routing-message-acknowledgements

https://github.com/maidsafe/rfcs/tree/master/text/0020-crust-refactor

RFC > https://github.com/maidsafe/rfcs/tree/master/text/0036-launcher-api-v0.5

RFC > https://github.com/maidsafe/rfcs/tree/master/text/0028-launcher-low-level-api
Forum > https://forum.safenetwork.io/t/rfc-exposing-low-level-apis-for-structured-data-and-immutable-data-handling/8546

https://github.com/maidsafe/rfcs/tree/master/text/0010-Launcher-as-a-service

https://github.com/maidsafe/rfcs/tree/master/text/0018-launcher-as-rest-server

https://github.com/maidsafe/rfcs/blob/master/proposed/0019-new-kademlia-routing-logic/0019-new-kademlia-routing-logic.md

Is it possible to setup an automatic post to https://forum.safenetwork.io/ under the rfcs category whereby the contents of a pull request can be the conversation starter and the Discussions in the within pull request or issue against it be put as posts on for the conversation.

The forum servers as a quick reminder of where you left of in following a discussion. This will give the rfcs much more traffic and followers than it currently has.

Was looking into setting up a personal notification system using zapier on the github notifications from the repo but if it can be implemented to suite everyone it would be good i think.

P.s hope this is the right way to contribute such an issue that does not necessarily impact the features to go into safe but a concern on how to handle this repo

https://github.com/maidsafe/rfcs/tree/master/text/0022-messaging_example_in_safe_core

Under conditions that requires an RFC, I would add anything that reduces interoperability (e.g. changes to the wire protocol.)

https://github.com/maidsafe/rfcs/tree/master/text/0021-MPID-Messaging-delete

https://github.com/maidsafe/rfcs/tree/master/active/0026-crust-mock

https://github.com/maidsafe/rfcs/tree/master/text/0008-UDP-hole-punching

https://github.com/maidsafe/rfcs/tree/master/active/0019-new-kademlia-routing-logic

https://github.com/maidsafe/rfcs/tree/master/text/0011-Connection_management

Refering to: https://github.com/maidsafe/rfcs/blob/master/text/0036-launcher-api-v0.5/0036-launcher-api-v0.5.md#remove-session-based-encryption-between-application-and-launcher

I'm late to questioning this sorry! It seemed a reasonable case was made for removing encryption at first, and I was perhaps too pleased to be getting rid of this encumbrance to question it properly at the time. I have now revisited this decision and after thinking about it I'd like to put forward some arguments for re-instating encryption.

From memory I think the reasoning for removing encryption was broadly as follows (@cretz please correct/elaborate where I'm lacking here):

Since the information that could be gleaned from intercepting App <> SAFE Launcher communications would likely be stored on or available elsewhere on the client machine, there's little to be gained by encrypting it just when it passes between App and Launcher. Doing so is therefore of little benefit, while generating costs in terms of performance, implementation time, and learning curve.

I think that one way or another I think that most of this is true. The information will be available in some way or other in an unencrypted form, so I don't pretend that encrypting this interface ensures protection except perhaps in some very limited cases, where (as I recall @cretz pointed out), it would make sense for the App itself to encrypt the data before transmission.

What I now think though is that encryption will still create a significantly more secure client platform and in practice will end up protecting data that would otherwise be stolen and exploited - and that this could be more than just significant, and in fact have a large impact on the data security of the SAFE App ecosystem, though how large is hard to predict or prove.

I have two reasons for thinking this.

1) General Case. Firstly, while attackers can in theory obtain unencrypted information by other means such as the filesystem, a keylogger, or indeed the memory space of individual apps, these methods are in no way comparable to the ease of some malware simply logging or monitoring all App <> Launcher communications. By leaving that channel wide open, malware can focus in on and collect everything the user saves and retrieves from the "Secure" SAFE Network. It brings all manner of attacks across any and all SAFE Apps into the scope of the script kiddie level of un-sophistication, multiplying the number of potential attackers and attack targets many fold - i.e. to anyone who can google and follow a how-to guide, and all SAFE apps that don't explicitly encrypt.

I think this alone means that we should reconsider this decision, in order to satisfy ourselves that there are other modes of attack that are as easy and general purpose as this and that encrypting App communications really isn't likely to have this much impact.

2) Specific Case. Suppose we have data that is created in the App that needs to be stored safely, but the App developer has not really considered or recognised the importance of keeping that data secure. Or perhaps doesn't have the time or skill to figure out how to use an encryption library and so skimps on security. So a problem can arise through: a simple oversight, a lack of consideration of security, lack of time or skill, or simply being unable to anticipate that certain kinds of data that the app generates might pose a security or privacy risk at some future date. Here for one reason or another the App developer has not encrypted the data before storage on SAFE network and yet the data is never available outside the App or on the client filesystem, or even through the keyboard and UI in a form that could readily be "stolen" by anything but the most sophisticated malware (ie from App memory), yet because we didn't encrypt Launcher communications it is now wide open.

I don't know how much data might fall into this category over time, but I suggest that we can't assume that it will be small, and yet by this simple omission we've left it all, wide open, to any "script kiddie" level of malware to gather and steal with ease, without any need for targeting by the type of attack, or any sophistication.

In fact, we might infer that since the user is using Apps that store their data on SAFE Network, we have helped narrow the attacker's data surface towards the very data that is more likely to be useful and valuable to steal, than it would obtain by searching many more GB of data on the filesystem, for example.

So again, I think we should re-consider the decision based on the idea that we are leaving something open with potentially large security implications, simply because we can't foresee the specific nature or estimate the likely magnitude of those consequences in future.

__
I follow @cretz' point (in the earlier discussion) that it is up to the App developer to secure and therefore encrypt data where needed, but that runs contrary to the approach of needing to try where we can to protect users (and in this case App devs) from themselves where that is possible.

I recognise that there is also an overhead that makes it harder for developers to climb the learning curve of the SAFE Launcher API, but this will surely be overcome easily with simple API helper libraries that we're already seeing arise from the community. There's also a positive side effect for those devs (such as myself) who are forced, kicking and screaming, to learn how to handle encrypted data and for which I am now grateful and in a far better position to write more secure apps in future.

These and other factors (performance) for example may need to be given more weight than the issues I've raised here, but I don't recall anyone making the above case when this was originally discussed. So I'd like these points to be considered and then we can review the decision and whether or not to reverse it while it is still relatively early :-).

Again, sorry I didn't think of this earlier and am raising this after the fact (and the point where I was planning to move my own dev work from the encrypted to the unencrypted interface with some relief), but it has only just occurred to me that this might not really be a good idea after all. Thanks for reading!

https://github.com/maidsafe/rfcs/tree/master/proposed/0015-vault-config-file

Discussing the understanding issues of #118 lead me to think that it'd be very useful to offer a Glossary for these kind of terms to make the RFCs more accessible and widen its audience. Unfortunately, markdown itself doesn't really offer any good way to do this by itself (other than linking directly), but Gitbook does. And as with #121 we now have a nice overview of RFCs as well, I played around with it a little as an alternative way of rendering the repository, you can find the results here:

https://ligthyear.gitbooks.io/maidsafe-rfcs/content/index.html

Preview:

And an example of what it looks like with their (automatic) glossary here (hover over "safecoin" or "farming" to see it in action): https://ligthyear.gitbooks.io/maidsafe-rfcs/content/text/0004-Farm-attempt/0004-Farm-attempt.html

I've to say I like this way of rendering it very much, and it brings many formats (epub, pdf) for free once set up (gitbook rerenders on every push to github). Maybe something to consider?

https://github.com/maidsafe/rfcs/tree/master/text/0012-safecoin-implementation

RFC > https://github.com/maidsafe/rfcs/tree/master/text/0033-fake-account-packet
PR Discussion > #128

https://github.com/maidsafe/rfcs/tree/master/text/0014-unregistered-client-support-in-launcher

https://github.com/maidsafe/rfcs/tree/master/text/0005-balance_network_resources

https://github.com/maidsafe/rfcs/tree/master/proposed/0016-launcher-data-types-api

https://github.com/maidsafe/rfcs/tree/master/text/0004-Farm-attempt

https://github.com/maidsafe/rfcs/tree/master/text/0015-vault-config-file

I'm just going through all the RFCs and make some general typo, grammar and formatting updates, when I found this current section in the RFC 0004 - Farming that reads:

1. PmidNodes -> tested at 100% of FR [i.e. Farming rate * 1]
2. App Developer -> tested at 10% of FR [i.e. Farming rate * 1.1]
3. Publisher -> tested at 10% of FR [i.e. Farming rate * 1.1]
4. Core development -> tested at 5% of FR [i.e. Farming rate * 1.05]

Which is clearly confusing, as 1 describes 100% as equaling 1, while two and all following describe the percentage (10% or 5%) as an additional (* 1.1 or * 1.05) – which one is it? I assume that it is meant as additional, so may I propose to the change percentages from 2 down to contain a + or the word "additional"?

(If accepted I can make that part of the bigger PR I am planning for the general wording and stuff).

I am not sure, where to suggest that, so I'll leave it here for now: I think for many RFCs a "definitions" sections on the top clearly defining words would be very helpful, like in this case what does "Farming" mean? There is a spec but it is totally unclear.

https://github.com/maidsafe/rfcs/tree/master/proposed/0013-immutable-data-naming

https://github.com/maidsafe/rfcs/tree/master/proposed/0021-MPID-Messaging-delete

https://github.com/maidsafe/rfcs/tree/master/text/0024-crust-refactor