Yeah just talking about verbiage, in reference to earlier discussions about not anthropomorphising apps. Apps being just for me to access and do stuff with my own data—and having certain capabilites—whereas users are given permision and a level of autonomy.
6 Likes
Whats the TLDR?
No, not joking.
One thing that would be nice to know is if I can choose to who an app is allowed to share data with.
One problem I have with permissions in todays world when downloading using apps is that I don’t know if the app uses the permissions for functionality, to share data with other users or if the app copies every document/picture/sms and sends it to 10 third party servers, where I no longer have control of the data.
To know if an app uses your data for functionality, share with users or sends the data somewhere else would be nice to know.
Example you could grant permissions for functionality, share with choosen friends or allow the app to send data somewhere else.
1 Like
For the whole thread? 
Well, there’s quite a lot covered here, but it mainly boils down to this…
TLDR; Both Solid and SAFE aim to put users in control over their own data, how it’s used, and who can access it, but they differ in how this is achieved. With Solid, access to data is based on where it is located. Whereas with SAFE, it is based on what the data is.
There are numerous implications to this, and the bulk of the thread is discussing what this will mean for the user experience.
7 Likes
Absolutely. This is the premise of the SAFE Network when it come to apps. Apps are software that I use to manipulate my own data, with no 3rd parties peeping, and I am in control of when that is shared with another entity, or published for everyone to see.
We can acheive this because all data you add to the Network is encrypted, and only you have the keys to it. You can choose to send this data elsewhere, and let other people (or entities) see it by sharing it or publishing it. That is the express purpose of the share and publish permissions/capabilities you’ll grant an app, and the rules and controls we are trying to carefully design.
This is precisely what we are making, you’ll be glad to know. I did a wee video about it a while back, I go into some detail on the overall expeience, but in particular you might want to watch this bit, where I mention give share permissions to an App, and adding a rule for that, and then here where I show the consent screen a user would be presented with each time that app needed to share or publish a specific bit of data.
There are still some risks in terms of malicious, or poorly design apps leaking data (although not clearnet levels of risk of though), and this is one of the reasons we have conceived the data labelling scheme, as a was to ringfence an app’s level of access by default, while still making things usable, and then putting the user in the driving seat when it comes to widening out those permissions.
And there are also other nifty elements, such as account level defaultys and exceptions (also touched on in that video IIRC) which would allow users to wall off certain data entirely, if they choose too.
Yes, this is coming down the pipe too… although I don’t have any screens to show you yet, as this bit of work is slated for the next phase. It’s already begun though, as you can see in the feature tracker. I think we’ve got the bones of the design already with the manifests and controls we already have, but there is fair bit more nuance to it, and it starts to span into other areas such as contacts management etc, so will end being a fairly chunky bit of work.
9 Likes
5 Likes
5/5
(sorry hat to post multiple times because only one image per post was allowed for me and it messed up the order of the posts. @JimCollinson I added numbers to them so you should ideally read them in order)
Having these data types allows the user to learn what kind of data an app can create and would like to access as well as have an idea where to store those different types of data.
The apps could also leverage this information because it would make it easier to choose the proper visualisation (I explain that in more detail in the paper I wrote)
Also Data Types would allow to create what i called “default containers”. the idea is quite simple. Users can define a container or folder as a default for a specific data type and every time they would be asked where they would like to store that data the system can show them “hey here are your default folder for social media posts, want to save them here?”. That makes the decision easier and faster for the user.
There are a lot more benefits this data types system would bring in my opinion. I tried to show that in my thesis and it was the first try to formulate how this could work. I think if the community could create those standards together, much like we decided collectively on jpegs, txt, json, etc we could extends the same ideas to new types of data structures that would make it easier to move data freely between different apps.
If I need to explain it in more detail please let me know
I think the file systems of our operating system work quite well and people are already used to them so they don’t have to learn something completely new. And we use it already to share data easily (more or less) with other people, to access and modify data with different applications based on their use case.
We don’t care if some created a PDF with word, excel, google drive or acrobat, as long as we know what data it is and where it’s stored we can use it. I think the same would work for different types of data such as social media posts, tasks , projects and so on.
But maybe I’m missing something or didn’t understand you correctly
that’s why the user should decide how their files are structured and not the developers. Like I said before, I think it works well for most people when they use their computers and they are already familiar with the concepts.
So, you can think of a label like a tag, or a bit of metadata applied to data either in an automated way, or manually be a user. These labels don’t care where the data is stored, they follow it about regardless of where a user moves it (and bearing in mind that more than one user might have access to a file, and choose to ‘store’ it in different ‘places’ on in there own file system views).
I agree that a combination of tags, data types and a folder structure would a pretty powerful toolset.
I also strongly believe that we need something like a shared understanding of data be it in the form of my proposed data types or something else. Without that it would be really difficult to enable true data ownership and help people to actually understand what data different apps create and need to access. what apps I can use to modify this specific data and so on.
But I#m also interested to see what other people think here
5/5
4 Likes
Some examples for data types
Those data types here a just an example that I created to test and work with and the general principles have at least worked well for me.
4/5
2 Likes
1/5
@JimCollinson sorry for the delay. Was quite busy the last couple of weeks.
(need to post multiple times because I can add only one image per post ._. )
So my Idea of Data Types is maybe a bit similar to your idea of tags. I try to explain it briefly.
There are a couple of problems with handling data created by different types of apps. Because every app can structure they data how ever they see fit it gets incredibly hard for users and for the other apps to know what is in that “piece of data”.
An Example:
In the image you can see that App A and App B call the “piece of data” a Document but the information it contains is different. App A and App C call the data differently but it contains the same information or has the same structure if you will.
This makes it confusing for people or apps to reuse data across different apps and display it correctly they never know the structure.
1/5
1 Like
2/5
To solve this problem I created “Data types”. Data Types are very similar to files types in regular OS like a PDF or a JPEG. I thought of a couple of basic rules or principles for them.
- Terminlogy: Every data type should have simple and distinct name that is always the same in every app
- Structure: Every Data type should have at least a basic structure as a foundation. (e.g. a data type called “article” has always a “title”, a “description” and “content”)
- Extendability: Apart from the base structure more information can easily be added to data of a specific type. (e.g. you can add teaser images and author to the data you call “Article”)
- Modularity: One data type can contain other data types as their definition. (e.g. a data type of “project” can include the data types of “Note”, “Task”, “Author”)
- Specificity: The more specific a data type is the more information it should contain
So with that you could create a hierarchy if data types like his one. The deeper down you go into the tree the more specific a data type is.
2/5
2 Likes