MVP is mainly backend right now. So we will have vaults from home (Fleming)that can upgrade (Maxwell) with a minimum viable farming algorithm in place. Whatever the frontend guys manage to push forward in that time will be what is released.
So best not to look at all teams doing the minimum. As frontend keep pushing forward it won’t affect release of an MVP.
Hope that makes sense?
@dirvine ok thanks, that makes sense. Though I do wonder if it can be helpful to spell that out on the roadmap somewhere.
So in this light, perhaps an Index on PUT is not an MVP requirement? I don’t see it in Fleming/Maxwell roadmap items nor in safe_vault github issues.
You won’t see much of the front end in the roadmap. There is a separate frontend roadmap that is being updated. As we approach launch the teams are merging with increasing overlap and that is great to see.
I am not sure how we would put that in the roadmap. Frontend guys are super focussed and very fast indeed. They would need a decent backend timeline to know what to include or not, so what they are doing (and I love it) is flying through as much as possible. Not so many new features though, much more tidy up, ease of use improvements and also driven a lot by UX work that is happening.
I hope that gives you a better idea. I hope much more of this is more visible very soon.
Yes. Doooooo iiiiiiiit!
Maybe I missed this in the (quite long already!!) thread, but how would the index work for private data? I.e., would the index be private as well, and therefore not searchable publicly (but still searchable ‘privately’, as in if an app makes use of the index, then it would still access that data for private use?)
Yeh you’re right there. In house we’re talking also about minimum viable experience for users. So there’s the functional networ, a traditional MVP, and there’s what’s useful for most folk. I’m talking of the latter here, so I should be clearer on that front, sorry.
And this MVE would almost certainly be coming later on then any base network release eg. So it’s with that in mind that we’re looking at this.
Tags (or labels in this case) are always nice, makes it easier to block files you don’t want to see, assuming people add the proper labels.
However, if any whistleblowers upload images anonymously, and someone gets acces to their account, probably trough the rubber hose attack, it would be in their images label, resulting in some more torture.
Maybe labels should not be applied automatically and instead be the responsibility of the app/owner, preferably automatically using secondary apps.
I’d say it’s the reverse. Auto-indexing for most things (as noted above, there are a lot of situations where this will be needed), and those cases where you want anonymity you grant an app permission not to index.
Oh so you can remove the labels, then it would be better to do so automatically yeah.
I think the index is private, at least as a first version of it, then I’m imagining you could share/publish it entirely or partially if you wanted to, but I think the main use case that brought this idea up was more for private use of users with their own data.
I’m at position that maybe it’s not a problem. Apps always act on behalf of user. For me it’s not a problem that app A uses app B’s data, since it’s all MY data finally. And apps are only my tools that help me automate my work. It’s a little hacky, but I don’t see a big privacy issue here. Unless you don’t trust your apps. But even in super-safe Linux nobody can stop you from doing sudo rm -rf / or downloading some spyware from beyond your distro’s repository.
This question about deleting indexes with app was under an assumption, that individual multi-indexes will be built as needed. But I understand what you already said, as it’s not the case, and that multi-indexes will be just views of sets of individual labels, so this question is not more relevant 
Does frontend team manage client_libs and safe_api? I see a lot of work there if you want to implement labels. From my experience, most frontend features end up requiring some backend work. I hope it will not turn to be the case.
More reading I’m afraid! But not too much, quite a short document describing the data discovery mechanism for Solid. The aim is very similar to that for labels, but uses a different approach. Conceivably both could live side by side or one be added later alongside the other.
One difference is that they envisage the ‘labels’ being applied to the containers if I read it correctly, rather than the individual resources.
It seems to rely on app developers to adopt and reuse RDF types for different data, although it would not be hard to automate the process of adding to the index where different types are similar, or indeed to automate creation of the index from the RDF resources themselves.
Here’s part of the intro:
The Type Registry is mainly intended as a Library discovery mechanism. We recommend that coarse-grained library types are registered (usually types that match containers as opposed to every RDF Class written by an app).
Specifically, the Type Registry provides a way for a client application to discover where a user keeps data relevant to this app, without either:
a. Prompting the user to select the location of every relevant instance or container, or b. Scanning through the entire dataspace/root storage of the user.
For example, when a user installs a new Contacts Manager app, the app does not need to scan all of the containers in a user’s storage, looking for relevant Contacts or AddressBook resources. Instead, it can query the Type Index registry and discover only the resources and containers it cares about.
thanks @happybeing, seems like a similar impetus indeed. I’ll give it a read the morn’ 
Kind of a stream of consciousness below… I hope it makes some kind of sense.
So as I think about all this, I see a conflict between labels that are private and those that are public. I also wonder how or if the public namespace of labels will be curated.
For public labels, it is nice to standardize on a common vocabulary/set. Eg file/mime types for starters, or really any existing curated vocab. (Though that is limiting when applying a label, and requires UI for choosing, if not automated)
For private labels, it can and should be anything because the label has personal meaning. Though automated labels can be applied here also.
I think this has always been one of the biggest problems for RDF also… coming up with a meaningful shared vocabulary.
There are also privacy issues with sharing labels. As such, I think that labels/indexes should match the privacy level of the data being PUT.
I’ve noticed that some public tag clouds allow organic growth/addition of the tags, but only by people that have some reputation or performed some significant actions. Maybe relevant?
Still though, I worry about duplication of public labels that are identical in meaning but different in spelling, phrasing, language. Realistically, can an organically grown public RDF graph solve this over time by linking all the semantically identical duplicates together? Would such a graph be efficient enough to traverse in practice?
Do we want a walled garden or a wild thriving forest?
Good thoughts.
I have to say I hadn’t really considered labels in the public sense, myself. For me it was more about organising a user’s data for their own use (and apps).
But yeh, it could be that you publish an index pointing to all your public data with a given label, with the label having RDF connotations (ideally).
Indeed an index of published data is probably very useful, so such indexes for Public/Photos could be automagically maintained. And then it would be up to a user to publish them…
Interesting ideas
ok, if labels are only for private data, that simplifies things a lot.
I am just a lurker here but my 2c:
You are building a DATA layer. In MVC, the data is in the model layer, the app is the controller layer. They should not be coupled.
Obviously, it is far more flexible to tag resources with labels than to have at most one container for them.
But keep in mind that you need to solve the namespacing and access control issues. As far as I understand it, each container has its own namespace? So now each label would have its own namespace?
Why not just broaden the idea of a container to encompass what you want labels to do — ie to have an additional level of indirection:
Container … Mapping … Resource
And any app would have access to any container as long as the owners of the container allowed it?
This way the developers of the app wouldn’t automatically be the owners of the container. But there would be some more general interactions between Containers and Apps.
Then this whole thing becomes a bit like Domains, except since they’re not human-readable there are no politics about reserving container names.
Hey @joshuef
I’m curious if these labels will be for (or maybe just initially) any data type or only for mutable data as the containers were to be implemented, for now at least?
I think it’d be really great to have it for any and all data types.
Say an app could help a user store some data in a particular way (using a combination of AppendOnlyData and ImmutableData) and on top of any default MIME type labels, the app could encourage the user to label or “hashtag” the data, and after upload then the app could display, organize, filter, query different labels from any users public data that has granted the app permission.
Could really extend the Patter example app’s functionality 
if that gets revisited at some point.
Is this part of the idea? I think I understand the concept behind the initial example. Something like multiple photo apps could have access to photos with certain labels rather than just plain access to ALL of your photos. I’m just not sure how far this goes or if I’m just dreaming things up 
You’re on point yeh. Labels for all the things!
Instead of Jams using its own container to store music, and other apps needing to know jams exists to then go and grab the user’s music, you just label ‘music’, and anything can ask for permission to see this index/access to ‘music’ files.
Couldn’t ‘public’, ‘private’, and ‘secret’ just be labels for mutable, immutable, and appendable data types then? Would this make the code a lot more streamlined or easier to work with?