Dumb DOM API questions

[loziniak]

@bochaco

They will both send the request to update it, with let’s say version = 1 (let’s assume this is the first modification being made to the entry after it was inserted with version == 0), one of the requests will reach a consensus first, it’s unknown which one ofc.
So one of the changes will be applied, but the other request should be rejected

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?

[loziniak]

@bochaco

MD owner’s account/app

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?

[loziniak]

@bochaco

although I did think about the possibility of such a thing too, e.g. if I am being spammed, or if undesirable emails from an account that I want to block/blacklist.

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.

[loziniak]

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.

[bochaco]

@loziniak

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?

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).

[bzee]

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.

[Mindphreaker]

Yes, the handles are freed upon page reload and tab closing.

[bzee]

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)
})()

[joshuef]

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.

[bzee]

I am using a library that does the routing, and internally it uses pushState, with hashes. It still frees the handles.

[DavidMtl]

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?

[bochaco]

Hey @DavidMtl, are you committing the mutation with applyEntriesMutation on the container’s MD?

[DavidMtl]

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”?

[bochaco]

@DavidMtl

but according to the doc it should commit to the network directly.

Yes, that should be corrected.

@DavidMtl

Is mutation used when we need to do multiple changes within a single “transaction”?

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.

[happybeing]

What happens if applyEntriesMutation is never called?

[bochaco]

The safe_client_libs manages an object cache in memory, so those changes are actually kept there until you send a request to commit them to the network.
This cache is intended not only for the purpose of trying to make a more efficient use of the network, but it’s also required for the FFI interfacing with the upper layers (e.g. the safe_app_nodejs lib/package). Every object is instantiated at the safe_client_libs layer, and the safe_app_nodejs just manages handles provided by it (they are kept within the Javascript objects the apps interact with, so it’s transparent to them). This is analogous to what happens between the browser’s safe_app plugin and the exposed DOM API.

[DavidMtl]

@bochaco

Yes, that should be corrected.

You mean the doc or the behavior?

[bochaco]

The doc, I’m sorry about that.

[happybeing]

So what do you expect to happen - out of memory error at some random point? Might be better to have a limit on the cache and throw a specific error that this has been reached, or to force a commit (probably not!)

And if the browser tab is reloaded before the call to applyEntriesMutation those changes are lost?

It would be useful to know the expected behaviours (in the docs).