Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor the usage of containers for an account #1061

Open
lionel1704 opened this issue Nov 5, 2019 · 2 comments

Comments

@lionel1704
Copy link
Member

@lionel1704 lionel1704 commented Nov 5, 2019

Currently, every account has a number of default containers. The access to these containers is maintained in the access_container. As discussed the following changes are proposed:

  • Remove the creation of the default containers.

  • When an app requests for a container, the authenticator will prompt the user about the request and depending on the existence of the container either of the following will happen:
    - Container exitsts: The app is given access to the container
    - Doesn't exist: The container will be created and the app will be given access to it.

  • Add a containers-list entry to the access container.
    This entry will hold a vector of the different containers available. This entry is not encrypted so that authorised apps can read the list of containers available.

Additional nice-to-haves:

  • Restrict the creation of the access container until the first container is created.
@lionel1704 lionel1704 self-assigned this Nov 5, 2019
@lionel1704 lionel1704 added this to Needs triage in SAFE Client Libs - vNext via automation Nov 5, 2019
@lionel1704 lionel1704 moved this from Needs triage to High Priority in SAFE Client Libs - vNext Nov 5, 2019
@lionel1704 lionel1704 moved this from High Priority to In Progress in SAFE Client Libs - vNext Nov 5, 2019
@theWebalyst

This comment has been minimized.

Copy link

@theWebalyst theWebalyst commented Nov 5, 2019

Nice for efficiency, and maybe makes creating new account cheaper?

Possible downside is more containers created than needed such as Pictures, Images, Photos, Drawings (as per app developer preference) rather than the developer seeing that Pictures always exists and deciding to use that rather than create their own.

Another possible issue is localisation. I'm not sure if it's colonial to 'suggest' English names by having them created by default (as now) or have apps developed in Russia, China, Vietnam and of course France 😉 using their own language for standard containers which Devs from other countries won't recognise.

Maybe this is something that RDF can help with? For ex, by having a semantic label which helps an app identify the purpose of a container regardless of the name. But if they are created by apps on first access that's unlikely to happen unless the API has some way to nudge in that direction. I'm not sure it would be picked up anyway, just a thought.

@lionel1704

This comment has been minimized.

Copy link
Member Author

@lionel1704 lionel1704 commented Nov 7, 2019

Yes @theWebalyst. Account creation is now cheaper.
You make a good point about the possibility of unnecessary containers as well. The reason we're introducing this is to increase the flexibility for developers and to prevent users for paying for containers they don't necessarily use. For example, a user might create an account just to manage his safecoin.

RDF will definitely help with this. Once we introduce RDF, there are endless possibilities and I for one am super excited about it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
2 participants
You can’t perform that action at this time.