Concepts for apps in a decentralised web

Hello folks,

I originally posted this on the Solid Community Forum and Mark @happybeing suggested thatt I should post it here as well as it might be of interest to some of you.

My name is Sergej Spomer and I’m an UX Designer from Berlin.
I based my Thesis on Solid and what Ruben Verborgh proposed in his article “paradigm shifts for a decentralised web”. I tried to see how decentralised apps that would be build on Solid work and more importantly, what the new possibilities of data-ownership and the split of data and applications would mean for the interaction between people and apps. How people would manage their own data and how they would decide who could access what data from where.

As I’m a developer myself I challenged myself to only propose interaction patterns that would be, as much as possible, technically feasible with the current technology. I tried to come up one possible way how we could design decentralised apps to allow users to have control over their data without the requiring technical knowledge to use it. I also came up with a couple ideas and concepts for shared data structures that would allow users as well as applications to recognise data sets more easily.

I’d love your opinions my thesis and hope that maybe they can help someone. What do you think about the ideas proposed here? Is there something that I completely forgot?

The whole thesis might be a bit lengthy because I also talk about the problems it tries to solve and the technological background. As you probably know this already you can just skip those parts :wink:

You can download the thesis here: https://ln.sync.com/dl/619f85ef0/xgaf5te9-ta9iadci-jvfn7eaj-cqunvya8

I also created basic prototype to demonstrate those principles. if you like, you can have a look at here:

https://www.sketch.com/s/0c2f4020-a8aa-412b-a778-3dfa042f7b85/a/W2GG4w/play

If you have any questions let me know and I’ll try to answer them to best of my abilities.

P.S.: @JimCollinson Mark mentioned you specifically and I hope it will be of interest to you

32 Likes

Thanks for taking the trouble to join us here and post this @sergejspomer!

I’ve looked through Sergej’s thesis and can see there’s a lot of interesting information there for decentralised applications, not just Solid, so asked him to post here.

I recommend at least downloading and browsing this because there are several things which will be of interest to the community. For example:

  • identifying and characterising different kinds of potential user
  • understanding user needs and barriers to adoption
  • proposals for how to meet those needs with
    • guidelines for design of apps, general UI, onboarding
    • wireframe mock-ups of UI/UX ideas which have been tested on users

There’s more, that’s just some key parts from memory. I haven’t read through it all! I hope some folks here read, give feedback to Sergej, and comment on any relevance you see to SAFE Network - both core applications and for app builders.

PS Sergej I visited your website URL as show in the document but it doesn’t work with the ‘www’ on the front. It works when I remove that, but you might want to fix your web hosting settings so it works as shown.

15 Likes

Hi Sergej,

Thanks for sharing! Will read your thesis later this week.

For now, i can’t seem to access your sketch prototype? There seems to be a problem.

4 Likes

Hi @sam1 - as per @happybeing - try without the www, ie https://sketch.com/s/0c2f4020-a8aa-412b-a778-3dfa042f7b85/a/3Wwwba/play

7 Likes

Hi @sergejspomer - great to see someone putting some serious thought into making this stuff easier from the end users point of view. Because Solid is still very much a MVP I find it very hard to visualise in my mind how it all fits together for the user and your paper demonstrates this very clearly, so thanks for sharing.

While the workflow diagrams look complex, the prototype shows that processes can be made quite intuitive, although there are still quite a lot of steps. I imagine a lot of the settings could be stored as defaults in the user’s pod so changing apps or pods becomes quicker second time around?

Can you tell me how the four different archetypes responded to the concept of the decentralised web and the practicalities of setting up a pod and connecting an app? What did you learn there?

9 Likes

tldr; but came to note a thought just now that one useful app would be for artists to charge micropayments. Big greed and media© copyright, is broke in the same way it always was; cryptocurrency always promised to offer a simple way to transfer small payments and the promise of that the majority of people are willing and just not enabled atm, has me wonder that it could work well… one of those build it and they will come.

apologies if off topic!

3 Likes

Hi @sergejspomer,

You are most most welcome here. If it’s one thing this whole decentralisation space needs is more UX designers, so I’m very excited to have more minds on all of the very tricky problems.

I’ve finished reading your thesis. I have lots of thoughts, and observations, largely stemming from the differences in approach between SAFE and Solid, even though the projects that are highly complementary in nature of course.

But what is helpful for you? Would you like me to share them here, or are you looking for specific feedback on how you’ve approached the problem in your thesis, given the specific technical constraints of the Solid stack?

12 Likes

@JPL Thank you! Presets and default should definitely be saved to make it easier for users to connect or change apps. Maybe apps could automatically create what they need in your pod. I think a main focus should always be to make it as simple as possible for the user but still allow him to change every little thing if he wants to.

Generally everyone that I tested it with or talked with about the ideas behind this were really interested and like the ideas. It took a while for me personally to find a way to explain it to people in a short and simple way so they could understand it. The first test were quite interesting because people are just not used to managing their data in this ways, they have no mental model for that. But they all like the ideas behind it.

So the biggest learning for me was that it had to be as simple as possible so that people could just get started right away. The more I could reduce the friction the more likely people would be to actually create a pod. Which resulted in creating the concepts for data types and pot type presets.

@JimCollinson I would love if you could share your thoughts and observations here. I posted this thesis here in the hopes that it would spark discussions and help create new ideas or approaches. I based my thesis on the Solis stack so I had something to build upon. But maybe there is a way to formulate more general design principles or guidelines for decentralised apps, regardless of the tech stack.

8 Likes

:+1:

This was my hope and I’m very pleased you think this Sergej. We’re all trying to find solutions to the same set of issues, and I agree that with regard to usability a lot of the learning will apply across different systems.

5 Likes

Cool cool, sounds great! Let me breakdown some of my thinking then, and try and explain some of the differences in approach we’ve had, so we can compare notes…

Data Access Controls vs Data Sharing Controls

The main thing that occurred to me when digesting the solutions in your thesis was the difference in approach we’re taking to controls over access to data. Certainly worth some discussion. There is some subtlety here, so let me try and lay out solution we’re proposing.

While it’s often touted as a selling point of the decentralised web that users with have fine grained control over access to their data, this is very much a double edged sword, and if we don’t take advantage of some of the inherent data security features of something like SAFE, and simply provide more controls over existing clearnet mental models, then we will end up with quite a painful experience for users. A continuous stream of authorisation requests, decisions, alerts, and ultimately permission fatigue resulting in increased risk; the opposite of what we want.

It’s for this reason, after a great deal of discussion, our starting point for how to tackle these controls was based on putting deliberate controls in the places where there is most risk to a users data: when it is to be Shared or Published.

I noted that you haven’t dealt with granting permissions to Apps within your solution, only access controls for other humans/organisations. Is that to do with a Solid implementation, or some other reason?

While it is absolutely true that apps are much much more like software of old: a user is simply using software to manipulate her own data—an app is merely a view, or window over a set of data—there still remains some potential for malicious apps to do malicious things, like stealing or leaking personal information, or publishing things when I don’t want them to be published. Hence the need for some controls over what an app can do, and when.

We’ve taken the view that by default (I’ll come on to some of the nuance of this later), a user should be able to have an app freely create, view, and edit private data, without any intervention required, but explicit authorisation would be needed before the app could be used to share data with other people (or send anywhere outside of the users private space), or publish it.

So this means that if a user wants to Publish any data, share any data with a 3rd party (e.g. allowing a friend to access a photo I’ve uploaded) , or ‘send’ any data anywhere (e.g. sending an email) then they would need to specifically allow this via the Authenticator.

You could see all this as a users Private, Unpublished data space on the network being like hard drive on their old-skool air-gapped desktop computer. They can insert a floppy disk and install some software, and use that software happily to read, create, edit any of their data on the machine, without ‘granting the app permission’ for them to do it. It’s a given.

The risk comes (and therefore the explicit authentication) when they connect that computer to the Internet and want to send that data somewhere, or publish it, or share it with someone else. That’s opt-in, and driven through deliberate consent.

Varying degrees of intervention

So, in order to give a low friction, understandable experience when placing permissions controls where the risks are presented, we’re proposing varying degrees of intervention into the user’s journey, or flow. This is all just what we a sensible default (a user could choose to to configure these levels of intervention to suit their needs), a balance between control and usability. Let me lay them out:

No Intervention: Authorisation granted without notifying the user.

This would be used for actions that carry low, or no risk to the user’s security, or privacy.

For example, an App could be granted Read and Write access to private data that the user has created via that app, without the user being notified in real time, nor providing up-front consent. (This is enabled via ‘data labels’ which I’ll explain more on later, as it’s handy for other things too.)

Passive Intervention: A user is alerted or otherwise made aware that an authorisation has been granted, but does not need to take a specific action.

These interventions can be used in circumstances where the risk to data security is low, but there is still the possibility for bad or malicious app to cause inconvenience or moderate expense.

For example, writing private data somewhere is low risk to the user’s security, but incurs a data storage cost.

So, if for example, there are per-App and Global spending limits, giving a soft, self dismissing alert to the user when a new App begins incurring this data storage cost the user is kept informed and able to make a direct intervention, without the need to interrupt their flow. Like this…

A passive intervention such as this would be expected and cause no alarm if you’ve just hit the edit button in a new app, but if you’re working away on something else, and suddenly a dozen new app notifications flash before you, then you know you have a problem.

Explicit, Just In Time Interventions: App usage is blocked until the user takes action.

This is for the actions where the risk is high, such as Publishing or Sharing data, or when an action might incur a significant expense.

A user is interrupted and asked to make a decision before they can proceed.

Here are some screens to give you an idea of how that is intended to work:

What you see above there, is a device we’re calling (internally, as it’s a useful metaphor) a ‘permissions manifest’. It’s something that’ll reappear a fair amount, and also the same device we’re exploring for granting access to other users.

I have actually made a YouTube Video walk-though on this that might be helpful, if you can put up with my monotone ramblings that is!

Upfront Permissions: Allowing a user to make decisions on what permissions an app has, ahead of time.

As I mentioned earlier, the in the interests of balancing total control, with experience friction, we think a sensible approach is with a mix of passive notifications and Just-in-time consent. However, some users might prefer (and indeed have requested) to be able to set, or just check, permissions for an app upfront, before it’s used the first time.

Or indeed a user might want to do this only for a specific set of data.

So that’s where a user could opt-in to upfront permissions. And then it would work thusly:



As I said, this sort of upfront intervention is unlikely to form part of the experience by default, as simply giving users lots of choices upfront may appear to give them more control, when in reality it may reduce it, due to ‘pop-up’ fatigue and choice paralysis. We should be aiming for a secure, low friction experience that gives users meaningful choices, so while upfront permissions could be part of the overall suite of tools available, they need to be treated with care in their deployment.

Setting Rules for Permissions

Something I go into on that video, but I notice is not something you’ve proposed in your thesis (unless missed it) was setting specific rules, for example a duration, to permissions. Is that down to a limitation of Solid, or out of scope?

Let me explain what I mean, and we can discuss its merits, and if it might also be useful when considering access for other users as well as apps.

When I’m granting a set of permissions for some data, naturally I can choose what actions the other user, or an app, are able to perform over for a specific set of data.

But at the same time for each, I’m able to specify rules, like so:

Here, I’m about to add a permission to Publish to this manifest, but I’m including the rule Ask Every Time which means I’ll be given a Just In Time permission request each time this app is used to publish any of my data.

Which would then look like this:

The rules we are working with for the moment are Always, Ask every time (as above) Check first time, Until I log out, or a specific duration like ‘3 hours’ etc.

This is for a user’s own app access, but the same kinds of patterns and rules could be extended to access for other users. For example, I give a friend permission to edit a file, but I have to give explicit consent each time they want to publish the revisions they’ve made.

Righty, I’m getting close to the character limit one replies here… so let me break things up into separate posts, more to on user permissions and data structures.

Love to hear your thoughts so far though. Did you consider any of these kinds of ideas, or test any?

21 Likes

As a wee side note on terminology, and mental models around what “Apps” are, and how the user perceives them in the age of the ‘platform’. I note you say:

From Sharing on Platforms to Sharing with Contacts
In the current system users share their content on a particular platform with users on that platform. The decentralised web changes this paradigm. User share directly with other users or groups which can then access the data regardless of the application view they’re using. This is necessary to allow users to exchange one application with another and still being able to view the data they already have been granted access to. It is important that this paradigm shift is communicated to users.

I totally agree. And this is something I think we need to work on through design and language guidelines when constructing these systems.

What a language can be used to indicate this difference?

For example, when designing the UX for SAFE, we are aiming to not anthropomorphise Apps. There is no set of eyeballs behind an app anymore, no company able to take a sneaky peak at your data. This will be a hard idea to shake I think, but the nunaces of language we use will help.

For example, rather than saying “This app would like to access your photos” we might say things like

“Using this app, you’ll be able to access your photos”
“This app needs permission so you can edit this image”.

It’s tricky! And we haven’t got it totally right yet, but hopefully it is something we can be mindful of, and refine as we move forward.

13 Likes

How about:

“Use [app name] to access your photos?” Permit | Deny
“Use [app name] to edit this image?” Permit | Deny

10 Likes

Yeah, that’s a good example. There are many places where this type of language crops up, and there isn’t a one size fits all solution. It’s just something to be aware of, and actively mindful of when writing for UX, as all these small things add up.

It can be tricky as the language has to be short, natural, and easy to digest. And It’s surprisingly easy to slip into the existing mental models, if you’re not on the look out for it.

9 Likes

My thinking there is that the wording implies the user is in control rather than the app, and it shifts the permission part to a button.

Language around permissions is a bit deadening so best to ‘outsource’ it to a control, IMO.

4 Likes

@sergejspomer another area that stood out…

Flat vs Hierarchical Data structures

Another thing I’d like to catch up on, is data structures. I realise that perhaps some of the this is down to the current workings of the Solid stack, but I think it’s well worth discussing, both to get more eyes and suggestions for what we are working on, and also potentially to take some thinking back to the Solid crew too, for I feel there are some real benefits to be had here.

In your work you say:

To give users’ flexibility on how they share their data and enable them to structure their data as they like, all resources are stored in a hierarchical container structure.

With this approach users’ have complete control over where their data is stored and are able to find it more easily if needed. Furthermore, it allows users to how more freedom in how they share their data. They can create different containers for different groups of people they want to share data with. For instance, people can create a container for their family and one for friends and by choosing which social media posts should be stored in which folder, curate which content the different contacts and groups will be able to see.

We started with a purely hierarchical structure to data, in a similar vein, however, there is real benefit to be had in flattening this out, and not binding the access to data to specific locations. I think there is real merit in this, and it may help you with some of the issues you highlight, as well as have the potential to reduce the complexity of the experience over all.

The solution we’ve come up with is also really useful when it comes to reducing risk of more open data permissions, while keeping a much more simplified default permissions setup for apps (as I mentioned in the Data Sharing post above).

Let me try and explain.

On top of a traditional file and folder structure, we have what we call labels. You can think of this like a ‘tag’ on a bit of data or folder.

The first way this becomes really useful, is that every has its own unique label, and any data that is created with that app, automatically has this label applied.

This is super useful when it comes to permissions, as we can apply specific permissions and rules for that label, which in the case of the app label, means a user can have much more permissive controls for data which is created via that app, and tighter controls for other data that exists outside it. That way, I know I can happily install a new app and having it running away doing its thing, with out fear that it is sneaking off in the background and deleting my important files, or stealing my crypto stash. It can only view and have access to data that the user has created via that specific app.

Here’s some screens that hopefully help illustrate some of that:

So above you can see that the o the Typedart app screen there are three rows which each represent a manfest you can click through too. As you’ll see from the wee summary, I can happily use TypeDart to create, edit and share data via the app itself, but it has no access at all to my other data. It’s a mock messaging app, so I’ve decided I don’t want to be able to send anything other that what I’ve typed in the app itself.

It also has access to use some of my Safecoin (which is the currency/token system the Network runs on) to pay for data storage—and creating these messages—but it cannot be used to view my balance, nor send any payments anywhere.

It also allows me to maintain permissions for a given app, but store my files in any structure that makes sense to me. Indeed, that app could be used to create and edit data in any number of locations, and I can move them anywhere I want, yet still maintain control over the apps access to it.

Also along side this is an exception I’ve made for a specific file. TypeDart can be used to View and edit that. But I’ve also made the decision that all new apps I install, will have no access to this file by default. It’s a very important picture of a lion that, so I’ve decided that only Apps I deliberately, manually, opt in can access it. And it doesn’t matter where I move this file, that will remain true.


In addition, labels can serve more traditional purposes too. For example, they can be automatically generated and applied from metadata.

An obvious example use case would be if I wanted to share all my photos with a family member. I don’t have to maintain a folder structure to do this, I’m free to store my photos anywhere, or use any App to edit them, without affecting that linkage.

And users on the other side of the transaction could equally choose too maintain their own structure too, and not worry about breaking anything.

Likewise, I could block users or apps from accessing certain categories of data, and again not have to worry about moving that data having a nasty surprise.

We still have the traditional file/folder/directory structure too, of course, and we can apply all the same types of rules and permissions there, but it works in parallel with labels.

There are areas where a more ridged hierarchy makes complete sense, like a website directory tree for example, yet you get the best of both worlds here, as you can choose flat views of the same information when that is useful, and apply permissions and rules to those as well.

Does that make sense to you? Happy to explain our thinking further if it helps.

13 Likes

Agree that language is really helpful here, and I also think the SAFE App in itself is a huge step towards this problem.

If a user can easily access their files through the SAFE App as well as through the app with which they created them, then that in itself shows they own the files, (as opposed to the 3rd party app,) much in the same way that if a photo is in the photos folder in my OS, then I know by default that I own it, rather than Instagram or whoever. I think the idea of the SAFE App being like an online Operating System is really powerful in subconsciously communicating these ideas.

6 Likes

Thank you @JimCollinson for your extensive reply! A lot of interesting thoughts and concepts here. I’ll try my best to answer you questions and explain my reasoning behind my ideas.


That is indeed a problem which I haven’t given much thought to be honest. My ideas were all based on the idea of access by location. When a person or an app requests access they would say what type of data and what access rights they want. You can see it in my prototype here: https://www.sketch.com/s/0c2f4020-a8aa-412b-a778-3dfa042f7b85/a/z3ooQo/play

That’s where my Idea of data types comes in to play. An app or a person let’s just call them an Agent here, sends a request they specify the data types they would like to access. You can then point them to one or multiple locations if you want. If you have set default locations for this data types they would also be shown here. And of course the level of access.

In this scenario that would mean that you could get a request from every agent at least once. Which still might be a lot. It’s a very interesting problem that I have to think about a lot more.

I did think about it but maybe not quite as much as you did. In my concepts when you connect an app to you pod, you have to give the app permission for the location you want the app to access. you can see it here: https://www.sketch.com/s/0c2f4020-a8aa-412b-a778-3dfa042f7b85/a/4Wqq93/play

When you first connect an app it shows you what data types it wants to access and/or create. Then you select the pod (of you have multiple that is) where you want to data to saved and accessed from and in the last step you can select the locations where this app would have access to. If you have default containers for those data types they would be shown here for easier and faster access. Apps could even provide presets to create new containers for you.

Also, in my approach there is technically no such things as an app that publishes something. Publishing implies, at least to me, that you send it to a server or upload it somehow which you don’t do via SOLID You give access rights for a file or location to agents and then they access it directly from you pod. “Publish” in this sense would mean that my pod would have to notify all agents I just gave access to so that they know they can access it.

What do you mean by an app wants to publish data? Will it be send to a different server or stored somewhere else?


Wholeheartedly agree. I believe this is one of the main problems that data ownership brings with it. The user has to understand that they’re in control of their data, they have to understand which agent has what access rights and they have to deal with a lot of access requests.

In my approach the user would grant access to a location to a agent and that’s all they would have to do. Because there is no “publishing” user would not have to answer request for that. As you can see in my prototype, the user can decide on creation of the data which agents would have access to that data. They could also choose if they wanted to save it in a different location.

The only times, at least what i can think of now, when the user would have answer access request is when a new agents asks for permission ( like a new friend request) or when an app that already has permission creates a new bit of data, saves it i you pod and then wants to give someone else access to it. But I haven’t thought about this case at all.


Setting Rules for Permissions

I think I touched upon some of that briefly but due to the time constraints for my thesis I it was out of the scope. I believe there is the possibility in solid to set duration for permissions but I’m not 100% sure. Definitely something that needs to be explored in more detail!


From Sharing on Platforms to Sharing with Contacts

I totally agree! I tried to do this by shifting away from the concept of apps that create and access certain types of data and more towards the idea of sharing by location. Just like with dropbox or any other cloud storage provider. Like I mentioned apps don’t publish anything by default. So by trying to focus the user on where they store what data instead of “this app does this” like you said. Saying things like

“Using this app, you’ll be able to access your photos”
“This app needs permission so you can edit this image”.

is in my opinion in the right direction and something that is a good candidate for an platform agnostic design principle.


Flat vs Hierarchical Data structures

It’s an really interesting approach.
Because a base assumption or goal in my concepts is to allow the user to switch apps whenever they want without any inconvenience I focused my attention on access based on location so that you can just point a new app to that location and whatever is i there, if the app can handle that type of data that is, is there for the app or the user i granted some permissions to.

My idea behind the hierarchical folder structure and granting permission based on the location was that separate folders would allow more control for what I share with whom.

I also wanted to disconnect the data that is created and the apps that create it. If I created something with one app I want to be able to access it directly with a different one. My idea behind the data types was that it should be more like a universal standard like .json, .pdf or .jpg. So it’s not tied to any specific app. In your example:

While it is true that it would be easier for me to just share all photos with my family because they’re tagged. It would make it harder for me to share specific content with specific groups of people.

Let me give you an example behind my thinking.

One idea I had was that you could have one folder for you social media posts that you share with your friends and family and one with your only work colleagues or professional connections. The folder for you friends and family could contain the folder or container that you share with you professional contacts. In that way, I could just add some data to a specific folder an share it with the people that have access to it. I could also just use different app to create let’s say videos or something and by saving them in the same location I know it shared with my friends.

Because apps or people have only access to specific locations, there should be no possibility for them to snoop on other files or data somewhere else.

I used the analogy of a cloud storage provider like dropbox. You share a specific folder with people or specific files and they can only access them.

Can you provide more detail about your tagging or labelling system and how it works?

In my thesis I mentioned briefly that SOLID has way of handling that problem via redirects. If a user choses to move data, they would be prompted with a message that some agents have access to it and by changing the location that would break. The user can choose to create redirect that would point the agents to the new location of that data if they like to. That redirect can also be set for a certain duration. Due to time constraints this was one of the things I could develop further.

But I definitely see the benefit of having tags for every bit of data. It works great with my idea of data types. Those tags could specify that data in more detail and linked data allows you to do that quite easily.

The problems that come to mind, but also didn’t have much time to think about it, is that when I want to share larger amounts of data with different people. Say I don’t want to share all my photos with my family so I would need to differentiate between them somehow. Maybe with more tags? But then I would have to go through all of them and tag them if I didn’t do it on creation. Maybe I’m not seeing something here, Have you thought about those scenarios?

There are certainly different problems that arise because of the differences of SAFE and SOLID. It’s definitely interesting to see how you approached this topic here and how different it is in certain ways.

I hope it makes sense, happy to explain things in more detail.

9 Likes

Sorry @sergejspomer, I had a rely to this, but totally spaced on hitting send :upside_down_face:

Ah, maybe that’s the part i’ve missed… can you explain what data types are, in the Solid model? It’s perhaps similar to our labels… are they metadata driven?

I’m not sure what ‘Photo Sharing’ is in this context, is this just allowing the Agent to access any photos within the sopecified loactions?


Ah sorry, perhpas I should have explained a bit more about SAFE and the way our different type of datas work.

With the SAFE network, there are no servers really, it’s all just one giant server, but all data on this huge server is encrypted, and access to data is controlled by the owners. I can keep a file private to me only, share access to it with a subset of users, or make it public by publishing it, in which case anyone can access it, and it is perpetually available on the network.


I’ve actually be pondering a bit more on this over the past couple of weeks—and I’d be interested to hear everyones thoughts—but perhaps the term permissions should be reserved for other users/agents, and the term capability could be used for Apps.

So I give an App certain capabilites, like the ability to edit my existing spreadsheets, but I grant permisson to a friend to view them.

Might be worth a test.


I guess much of this is stepping into new territory, and we won’t fully understand in the implications until we can see many more people using these tools, and also see what path developers take too.

My fear is that hinging too much on file location for both data sharing, app utilisation, and user organisation, might end up being too blunt an instrument to satisfy all three sufficiently.

Granted, we have the advantage witn SAFE of not being bound by a file location on a server from the start. It’s a flat file structure by default—really more like a Content Addressable Storage, rather than location based—so each data simply has a random address, metadata, and then keys that enable access to for users and apps.

It’s from this base that we can build the UX, so maybe a slightly different starting point from where you have been working from, so perhaps landing on different solutions.

My assessment was that hierarchical file/folder structure should be there to deal afford users personalised organisational structure, which is highly individualised.

Then when it comes to seemlessly switching apps, but utilising the same data, the user shouldn’t really need to think about the underlying structure or location of that data—which in the first instance, might have been defined by the developer—really their goal here would be something like “I’m getting tired of this FaceGram app, I’m gonna switch over to TwitSpace as it seems much easier”. If I had to understand how things were being structured the scenes on these two apps, before taking the plunge, and those smae structures were also being utilised to manage sharing with other users, I think the task migh become a lot more onerous.

I’m not saying we’ve got the complete solution here yet BTW, we’re just taking baby steps, but starting with a flat file structure, plus metadata, plus labels (both automated and manually applied), plus file/folder structure, an I think we’ve got a pretty flexible base to work from.

I’ll try!

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).

The first usecase for this that we are utilising labels for is allowing people to give a new app quite open and permissive access to data that has been created with that app, and yet restrict access to other data. This label would be unique to the app, and automatically applied. Doing this allows me to use the app to store and read data from in location in my chosen file structure, safe in the knowledge that the app cannot be malicious and access existing data without my say so.

Yeah, so the next set of scenarios would be around sharing of data with other users. The thing you have to bear in mind is that I can set permissions based on both labels and file/folder structure. And the other thing to remember is that labels will be predominantly automtically applied, but the can also be manually used too.

So, if I wanted to share all my photos with a family member, but exclude a certain folder, I can do that. Or perhaps I want to share access to only my music files in a large media folder, but I don’t want to have to manually sort things into media/music I can do that too. And also, it doens’t matter if I rearrange things later, it won’t affect the sharing permissions in an unintended way.

Or perhaps I want to share my health related data with a doctor, but only data that has been created with two different apps, and I also want to exclude location data, I can do that too. And those two different apps could have very different file structure for the data the produce, and it won’t matter. Or could organise that data totally according to my own needs and understanding, and my doctor could do the same, and it won’t affect the access to it.

To my mind, it can be a pretty powerful set of tools, and I’m excited for possibilities!

14 Likes

I’m finding this thread very helpful. One thing that reading this is suggesting, is that starting from the right underlying capabilities means that with SAFE we can build anything, well pretty much anything like other systems, on top. Whereas starting from a higher level, in Solid case the Linked Data Platform (LDP) and then adding permissions is limiting.

You can still implement Solid/LDP using different backends (file system, graph store, SAFE Network, AWS etc) but you have to shoehorn them all into Solid/LDP and find ways to do this using the features of your chosen backend, which in some cases is tricky, and has I suspect lead to compromises in the design of the permissions system of Solid.

I haven’t thought about it, but for example, I wonder how feasible it would be to try and implement capabilities for Solid/LDP based on a file system server. It seems likely that if you start with a file system view, you would tend towards a permission based model because that’s already there in roughly the right form. So maybe this has constrained thinking about the permissions design. I believe that the first Solid server implementations were file system based, and think this is still the primary focus, in order to make it easier for people to adopt and deploy Solid servers. So things like this may well have influenced the Solid permissions APIs as well.

SAFE on the other hand is driven from the bottom up. Designed to meet key design goals, then to provide a capable platform, and now to work out exactly what features to offer for developers, how best to express different kinds of use, and how to present this to application users.

Whatever you want to sit on top of this gets the benefits of those first level design goals, and can be implemented at the platform API layer, or a standard protocol layer on top of that (key/value store, RDF, JSON, or Solid LDP and so on). :sunglasses:

9 Likes

Not sure how things would differ under the hood. Are you simply proposing wordage changes or imagining something deeper @jim ?


Aside:
I do hope eventually we get rid of a lot of the differences between an app/user in terms of the ClientHandler layer, and the authenticator becomes an app managing keys. But that (in my mind at least), doesn’t necessarily touch the UI layers at all and is more about simplifying what’s going on in the background (and making the auth and its data structs an ‘app’ in itself… which it sort of is, but sort of isnt as things stand).

Maybe too much bg details for this thread, but just wanted to drop that in in case it impacts thinking from anyone!


Yeh, that’s in line with my thinking. Our goal, IMO is to make sure data that we put up can be easily identified / converted. That will likely be via RDF. But that’s seperate to integration w/ solid etc which is much more a server spec and focussed on clearnet use/integration. So that’s some app layer that you’d put atop SAFE as a storage medium (where ideally, all the data is ready for SOLID consumption) :+1:

6 Likes