[heathjohns]

Thanks for reading!

If an app wanted to be able to switch something from public to private or back, it'd get a token with write permissions for two names, one with the prv.* prefix, and one with the pub.* prefix. And that's a good thing: it makes it clear to the user that the app is requesting the ability to make the things that they write public.

It's still just one grant request, it's just that there'd be two line items instead of one. Also, names are simple pointers to blocks of data, so, for instance, if both names happen to be pointing to the same written piece, there's no duplication of data.

[podviaznikov]

And another question. It's not possible to list all the keys under some namespace, right? `prv.app.edsu-org.prefernces-app.preferences` - I can't see what are the subkeys?

And I see that there is no multi-get request. So how would you implement your notes app if you have multiple notes, not one. Would you have a document which would store hashes of all notes and then fetch in parallel all of them (making n calls, 1 call per note)?

[heathjohns]

Names are big chunky things - you want to use them as sparingly as possible, and in general they should be "well known" - meaning a list function (which does exist as pub.srv.edsu.listings.names, though it's currently not something you can request permissions to) goes pretty hard against the grain of the protocol.

Essentially, you'd only want more than one name if there's different visibility requirements for different parts of your data, or you specifically want to disconnect the state of some of data from others. All of your structure (e.g. lists, trees, lookup tables, etc.) you want to keep in the blocks.

So in your case of having multiple notes, you'd likely want the name block to keep track of the block hash of each one (so, yes, exactly as you say). And correct, if you wanted all of them you'd need to do N block-get calls. However, due to pipelining and chaining, that's not as costly as it might sound: in terms of latency it should be costless, and in terms of bandwidth the overhead is a fraction of a percent if you're using full blocks (i.e. what you'd be doing if you're concerned about bandwidth).

A lot of this stuff is quite low level (think almost SCSI kind of low level) - it's meant to be abstracted away by libraries like basic-storage.js. In that case, having multiple notes is trivial - you put each note under a different storage key, and the library sorts out how to retrieve them efficiently and update them independently, even though they're all be under the same name.

In case you haven't run into it yet, I talk a little bit more about why names are meant to be used sparingly at https://edsu.org/use-cases/storage/

[podviaznikov]

Perfect! Makes sense