In order to learn a few things I’ve been trying to work on the Safe Web App, and have now added the features I was working on, if anyone’s interested. The main one is just saving the randomly generated MD address in the app’s own container, so that it can be returned to. I think some of the other language tutorials have this anyway. The app also has the ability to edit entries, and includes some UI bits to help with this, although the UI is deliberately left a bit clunky to best reflect the code.
I know some of the Maidsafe guys were asking for feedback on the main forum, and I think I, and others I’ve spoken to with more experience, would have appreciated a little more high level explanation of how things fit together, partly in relation to JS helpers, dependencies etc. and also, particularly for those more used to working with servers, how the Safe network fits into things. I imagine the web app would be the first port of call for many people starting out on Safe, so it seems particularly important in this case.
I’ve got various ideas of where to go with this, including eventually writing some tutorials, but in the meantime if anyone’s struggling like me this might give a few clues to getting a step closer to something useful. I can’t promise the code is ‘good’, but I think it’s all at least reasonably clear, and it worked the last time I checked.
Thanks! Looks like that’s a remnant of when I was printing out everything to check each step!
On that note, am I right in thinking that another app cannot access an app’s own container? (the only reason I thought it might be is that the ownContainer address is derived from a known source, as far as I can tell.) Obviously it would be helpful for security if it was hidden, but it might also be nice to be able to give access to another app, eg. a native version of the same app.
The app’s own container address is kept in the account’s Root Container (both are private MDs, i.e. all entries can be encrypted). The Root container is a map of containers names to their priv MDs locations, this is how the API allows you to fetch them by name. Thus they are hidden, i.e. stored at random locations.
I agree with this, I think in some use cases when you want to perhaps use a different app which internally uses the same data format for its data (e.g. RDF) it should be possible for an app to get permissions and access to another app’s own container, just like any other default container. cc: @nbaksalyar
With the push toward RDF, maybe the app containers could be deprecated to discourage apps from not sharing data? Or I guess it’s still needed for app specific settings? Maybe any and all such settings should also be shared for use across apps?
This is how I personally see it at least, data which is not really what is managed by the app but things like settings.
I don’t think apps having a container which can be fetched by its ID (app’s ID) goes against RDF or sharing data, it all comes down to exposing API to easily share these containers among apps, there is no really a differene between this container and any priv MD the app creates, but it’s just a way to allow apps to find the pointers to data (or settings as we are saying).
BTW, you might already be able to share the app’s own container with other app, either by using the app ID in the containers permissions list in the auth request, or perhaps by grabbing it xorname and then sending a sharedMD auth request. I am aware of a bug for mock and test/fake login raised some time ago though: https://github.com/maidsafe/safe_client_libs/issues/710