Default Containers and the location of public data


#1

I’m trying to visualize the options for accessing data and wondering about an app that allows a user to update a mutable data attributed to them alone; and then that being publicly visible to others.

Do users have a UID by default or does the creation of any useful public data suggest a user has a PublicID to make data visible?

From https://hub.safedev.org/discover [Default Containers]

Does [Immutable Data] have an owner noted or not as that is just a static that exists unowned?

Does [Mutable Data] have a read only option for Public access?

_public which is used to store unencrypted data (the container is encrypted even if its content is not)

Is unencypted data stored in _public, accessible to anyone?.. and as above how is that referenced… is there UID or PublicID… and if many PublicIDs are there multiple or do all those point towards one _public folder?

_publicNames which is used to store references to the Public IDs owned by the account.

Is the reference of a PublicID in _publicNames, proof of that account owning it?.. can it not be spoofed and therefore can be trusted??

I’m still not immediately recognizing the format of an Apps store of data - it seems a bit low level atm and needing a higher simpler description. I understand Apps data exists and expect I could create it but it’s not visual in a clear way that sets out the limits. So, I have the impression Apps can access other Apps’ data where that’s been made available but I’m not clear if that’s controlled.

Can my App-A access my App-B, without App-B being accessible to all other Apps?.. or is the simple answer for that to encrypt data?

How does an App navigate data - how does it make reference to other data on the network - can Apps call directly on URIs; and can they call Immutable data?


#2

Hi @davidpbrown, thanks for your questions!

I’m not exactly sure what you mean by a UID, but usually a user’s public signing key is used as their public ID. All apps know this key under the name of an ‘owner key’. And all Mutable Data objects created on the network by apps must have an owner set to the user’s public signing key.

It does not, and it really shouldn’t, because the Immutable Data is just what it is – it can’t be removed from the network, it can’t be changed, so it doesn’t really need an owner or permissions.

All Mutable Data objects are readable at all times, so it doesn’t really need any options for public access. If you know an address (XOR name) of the Mutable Data, you are free to read it.

Yes, it’s available for reads by anyone, and GET operations are free on the network.

You mean the multiple ownership? This is planned as a feature, but currently it’s not implemented.

Yes, it is recorded in the owners field of the Mutable Data struct.

It can’t be spoofed because it’s held and checked by a group of Vaults. :slight_smile:

That’s a very valid point, and currently we’re working on improving the documentation, both for core and app developers.

Yes, it’s really a combination of data encryption and permissions on the level of Mutable Data. If you want to make your encrypted data accessible to a certain app, you’ll need to share an encryption key through the access container, and it’s controlled by the SAFE Authenticator (the thing you see in the SAFE Browser where you register your apps, etc.).

If I understood your question right, that’s exactly what the XOR URLs RFC addresses. You can join the discussion here :slight_smile:

I hope this helps! Please let me know if you’re interested in more details or have more questions.


#3

Thanks for the explanations @nbaksalyar I am a bit fuzzy on all of this too. When my username-password-secret combo is used to generate my keys is it just one pair of keys (one public and one private)?
If so, what’s the public signing key? Isn’t signing normally done with a private key? :thinking:


#4

Ah, they do not generate your keys. One is a location of a blob and the password decrypts that blob. The blob is where your keys are stored. so these are just generated with the system random num generator and the appropriate algorithm. this is why you can have a great many keys, they are not linked to your username or password at all. Then you can start a session on the network with different keys (where pub key is another identity), even though you logged in with unique name/passwrd.


#5

Does that suggest that XOR address will be known for PublicID/_public/filename without knowing the content of the file?.. I take XOR URLs to be like static pointers to what is known but wondering more about finding what is under a public name - that certain apps are going to want to draw off a moving target, or call files that flux.

I wonder XOR URLs are good, if you know what you are looking for. Dynamic options follow from finding what you do not know. An example is a PublicID/_public/.plan which could be made into the most basic kind of twitter; subscribe to the PublicIDs… but need method to call at those and know which exist.

Edit: better perhaps is users_public_signing_key/.plan as that negates need to create a PublicID.

With the SAFE app client API, I’ve yet to see with an obvious option to call on URLs and public data, outside of a browser (which allows flex in the language used to solve a problem) and unclear if that’s just a temporary limitation. A commandline is what I imagine as the simplest app and useful for a proof of concept, before getting around additional complexity, the like of generating a mobile app shell just to test that idea or creating an App in some other way that’s not so obvious. I guess just keen to see the existing and future limitations, made clear to help imagining what is possible and practical.


Will XOR addressing be a route to knowing an address… can I predict what an address will be from knowing the contents?.. and test if that exists or not.


#6

Not sure what you mean exactly, but yes, you don’t have to know the contents of a file to use XOR addresses. For Immutable Data objects their addresses have to be derived from contents, but still, it doesn’t mean you need to know the contents of a file to request it from the network, only its address. You might need to have a data map though, if a file is self-encrypted & chunked – but the data map by itself can be stored in a separate Immutable Data, so most likely you’ll still need to know just one address.

This is correct.

Yes, if a XOR URL is pointing to Mutable Data, the contents can change. So it can be e.g. a website or a blog which doesn’t necessarily need to have a short public name (as in DNS).

Yes, it’s indeed a temporary limitation. Currently, you can’t use XOR URLs outside of the SAFE Browser to fetch data from the network, but we certainly plan to add it to the Client Libs API.

This is a good approach in my book. :slight_smile: We’ll be providing more of such examples for the Client Libs, most likely including a demo for fetching data with XOR URLs. Still, there are many details to be fleshed out, so I can’t yet say when it’s going to be available.

For Immutable Data, yes. That’s the idea behind the data deduplication on the network: files/chunks with the same contents will be stored at the same addresses. :slight_smile:

I’m a wee bit rusty on some of the self-encryption details though, so @ustulation might correct me if I’m wrong.


#7

As @nbaksalyar says, even that this is still not possible using the safe_client lib API yet, this is already possible as part of our experimental APIs in safe_app_nodejs and therefore also with the API exposed in the browser. Remember you need to have the experimental toggle on.
For a concrete example please look at the post we published when released SAFE Browser v0.11.0: