Can I add to this list:
- is a container just a mutable data like any other, with the same features and limitations (eg 100 item limit), or if not what are the differences?
2 Likes
My understanding is that the app can only create one container for itself (ownContainer), but not totally sure.
1 Like
Why is mutable data limited to 100 entries and 1 mb per entry?
It isn’t 1MB per entry, but 1MB per MutableData (and 100 entries per MutableData). Those are implementation decisions - ie what the SAFE network supports. My understanding is that if you want more/bigger you will need to string multiple MD together yourself once a limit is reached.
I think that is the case with containers too, because each is just an MD, but my question is just to check that this is the case and that the API does not have code to string multiple MDs together per container.
In the case of the root container, each entry is an MD which is also a container. See the RFC referenced above.
3 Likes
I would say the only difference if the way you reference it, i.e. the containers have a name which can be provided to the API to fetch it, whilst for fetching MutableData’s you need the XoR name and tag type. After you fetch them, you interact with them both in the exct same way, i.e. using the MutableData API and NFS emulation if you prefer to.
At the moment from the safe_app_nodejs and DOM API it’s not possible to create another container but the one you can request to be created when you authorise the app with the own_container option param. But this is something that was thought to eventually be possible if the app requests permissions for it, although I haven’t explored the lower level safe_core API well enough to provide more details at this time, I just remember this was somehow mentioned in the RFC: rfcs/text/0046-new-auth-flow/containers.md at master · maidsafe/rfcs · GitHub
As mentioned above, in order to fetch a MutableData you need the XoR name and the tag type, and if you want to fetch a Private MutableData you need the encryption keys in addition to that.
If your app needs to store a reference to a MutableData it can store the required information so it can then fetch it, or alternatively it can just serialise the MutableData, store it, and then it can deserialise it to fetch it.
Correct, this is not supported yet.
4 Likes
9 posts were split to a new topic: Error on create/insert with NFS (bug discussion arising from Dumb DOM API Questions)
Hypothetically, is this possible that one instance will send v=1, and other v=2, and they both get accepted? Where can I read more about a consensus mechanism, Is there some RFC about that?
So, is it account or app? Can I restrict permissions to some app used by any user, or some user using any app? Or is it always account+app combination? Or maybe it is always a user using current app?
I think it could be done just by clever design of application data structures. You can perhaps save email={ login: “…”, content: “…”} instead of email=“…” as a mutable data entry value and ignore/delete entries that don’t have email field.
Great topic anyway, great questions, great answers. I think every question in this topic should result in a commit to documentation, or a ticket 
Or perhaps a FAQ could be compiled of it.
1 Like
The account is the owner of the MD created, and the app which requested the creation of the MD is added to the permissions list when it invokes the quickSetup function in the MD API (or using the put function of the MD API it can specify which permissions to be set for itself in the MD).
So you can restrict access to the MD entries using the MD Permissions and PermissionsSet APIs, and you can set those permissions to specific sign keys (that’d be the app’s sign key you are giving/denying access to), or you can set permissions for any app by providing a null sign key to those APIs (we’ll expose that as constants eventually to make it clearer for the developer).
2 Likes
Does the beaker-plugin-safe-app free handles automatically once the URL changes? I have a test app that uses history.pushState internally and it seems after such a page switch the handles are invalid when calling the several window.safeApp functions.
Yes, the handles are freed upon page reload and tab closing.
1 Like
I see. However, by doing a pushState, the page is neither reloaded nor closed. Consider the following example (tested this in the browser):
(async () => {
const handle = await window.safeApp.initialise({ id: '1', name: '2', vendor: '3' })
history.pushState({}, 'page 2', '/page2')
setTimeout(() => {
// Somewhat later.
await window.safeApp.connect(handle) // 'Invalid handle: 63b3e...'
}, 1000)
})()
2 Likes
Fair point and good find, @bzee. We’ll have to look at how we’re doing this 
to avoid that.
In the meantime, can you try with hash history perchance? I don’t think that will trigger the same events so might work.
1 Like
I am using a library that does the routing, and internally it uses pushState, with hashes. It still frees the handles.
Hey @bochaco, I’m trying to add a new entry to the container of my app by using the function insert but the new entry doesn’t persist when I call getOwnContainer->getEntries again. Note that I can see the new entry if I use the same md_handle, it just doesn’t persist if I reload the md_handle.
Is it ok to add an entry to a container or should containers be used exclusively as files using the NFS API?
I’m using the mock network btw, any idea?
Ah okay, but according to the doc it should commit to the network directly.
So what’s the difference between using safeMutableDataEntries.insert and safeMutableDataMutation.insert? Is mutation used when we need to do multiple changes within a single “transaction”?
2 Likes
Yes, that should be corrected.
Yes, that’d be the case, if you want/need to populate the mutations object with several actions and then commit it to the network to make it more efficient.
2 Likes