how is the plan with "public" (for different apps) containers?

API
1

since i am experimenting with python for a longer while now there are some older relicts in my code …
for example my application wants access to the _music-default-container - by now i forgot about the list of default containers and just changed the name into something else and suddenly the authenticator didn’t allow me to authenticate anymore

is this still the plan? or did the plan change? or can we create new containers (i didn’t see exposed functionality for this)

if this is still the plan and i cannot create a new container - why is this the case? whats the motivation for this? couldn’t it make sense to create a container with custom name for all my communications apps? or how is the concept there?

2

To me these containers have always felt a bit odd.
It’s like a design desicion that shouldn’t be made here, too high level, with insufficient intermediate layers. Who wants a picture or music folder that only takes 1000 items?

As to have something to show-case, I can see why this was put in place, that makes sense. But it doesn’t seem like a long-term solution to me.

So, I would prefer MaidSafe to design that intermediate level, a flexible data storage abstraction, so users and developers can be creative with that, i.e. they come up with some standard folders or what ever other thing that it enables.

3 Likes
3

this thing is limited by the mutable data size? Oo

4

Well, you could probably add links to new MDs and so on, but not sure that is built in functionality (I don’t think so) I haven’t used those containers actually so I need to look it up now

Edit: the point with these folders is to share a common protocol, so I think the point is to store the data directly to them, didn’t read anything about expansion schemes for the MDs implemented there

5

okay - but a container is just a mutable data then …? (that’s probably pretty basic but with pysafe i just dropped a random addressed mutable on the network for now and we are still architecturing the workflow with threads and callbacks and data management/copying) or is it part of the nfs (?) (or am i even mixing stuff with the old rpc interface now ? -.-" )

6

Yep, container is plainly a mutable data.

1 Like
7

hmmmmm… okay - with limit on it that doesn’t really make sense then … i think this needs to be reconsidered then @maidsafe !

(seriously … even ownContainer-address + [byte-encodedNameOfContainerName] would automatically be a place to store my files … and very low probability to be occupied already …)

… and since we’re on it …
…i know it was decided to go from 512bit encoding/address space to 256 in 2015 or 2016 … by now (2019) even mobiles have 64bit processors and until we reach beta (i don’t expect it before 2020 tbh) technology won’t step back i guess … maybe we want to reconsider using a larger address space for our data to really be able to exclude collisions …? @dirvine

1 Like
8

@oetyng is right. The default containers are just mutable data. And yes, you can insert links to other mutable data in these containers.

One of the advantages of the default containers is that it is mutable data that the user is aware of (in terms of it’s location). While using mutable data at random locations is possible, other applications will not know where to look for existing data that belongs to the user.

Keeping in mind the size limitations of mutable data. Applications that work with music files can be designed in a way such that:

  • The content in the music container can either be a music file or a link an NFS container (which is again MData)
  • If it is a music file, read the content and display it in the applicaiton.
  • If it is a NFS container, look for files or subfolders and repeat the process recursively.

This way, any music application will be able to get the music that belongs to the user.

4 Likes
9

IMO containers should be automatically expanding, like the trees of MDs that @oetyng made in C#

10

I agree as well. When the limit on Mutable Data was introduced, it was not meant to be permanent. We are considering removing the limit on MD to make indefinitely expanding.

1 Like
11

Even that I also understand the benefit of these default contianers, and from my understanding the original intention of being able to find containers by a “standard name” that any app can find, it’s probably not ideal that we use a static predefined list of names for them, it sounds to me this also should be covered by RDF and apps creating the ecosystem of shareable data.
E.g. perhaps the root container shall simply be an RDF document that can be filled up by the authorised apps, each of them adding subgraphs, my music box or Jams app may define a “Music” subgraph with the corresponding links to other containers and data spread on the network. Any other app which is expected to be comaptible with my music box or Jams app, should look for the “Music” subgraph in the root container of my account (obviously after I’ve given permission to it) and follow the links to the music files, which in turn must be using the same RDF schemas/vocabs.

In summary, having these prefixed names sounds like an attempt to achieve what RDF is/should-be expected to provide

1 Like