Focus: A Solid Task Manager


Hi there,

I just completed a first version of a Vue-powered task manager using Solid, I’d welcome some feedback :).

I plan to add more features in the future, but the thing I’m not too convinced about is the RDF types I used. I’m also wondering if it’s a good idea to combine multiple ontologies to increase compatibility with other apps.

If you want to dive into the source code, you can find the Solid integration in this two files (besides the login):


When creating a new workspace I’m not able to select a storage. Where are you getting this information from? Are you relying on pim:storage?


Actually this is one of the doubts I had when I started working on the app. The example application I used to learn Solid had this choice of storage, but I didn’t understand what it was, since I only had one and it seemed to be the root of my pod. If you look into src/utils/Solid.ts there is a function that parses the user and gets the storages from the type you mention, I’m implicitly using the first item from that array. So it’d be really easy to add a select in the form.

I read LDP specifications and as I understood if you want to create a container, you can do it just in the root. I’ve already tested that using the same name creates unique urls anyways, so there shouldn’t be a problem with collisions with other apps.

When would a user have more than one storage, and what are them? Can you point me to documentation on the topic?


Hi, works well. I completed a task and it auto hide which is fine. I guess a red [ x ] to allow deleting a completed task would be nice too. Anyway nicely done Noel~!

Some apps suggest “default” pods which are generally; [user], [user], and [user], but i think it’s more a convenience.

Typing the location is fine as our browsers often remember the form inputs second time round. (on this app that seems disabled - a security feature perhaps). Logging out and entering another Pod cleared the workspace, and returning to the first Pod recovered the workspace fine here as well.


Yeah, I still have to add a lot of features, that is one of them :D.

Actually I removed it on purpose (the solid-auth-client library already does that using the modal login). I don’t like the fact that some platforms are given more visibility. Although I can agree that it can be easier for users, so I’ll keep that in mind for the future to find a better approach.

I haven’t done anything special for that, it’s just that being a JS application I’m not using a “name” attribute for the form input. Maybe it’d be a good idea to have one so that it remembers previous inputs as you mention.


Thanks @NoelDeMartin, this is a great app, both to show what can be done with solid and to actually use. I am happy to see it developing further.


You could have a look at this thread I started earlier.


Awesome work, I have just some UX pointers if you are interested to hear them, PM me on Gitter or LinkedIn.


Great app, @NoelDeMartin, very nice work! I think starting with the Schema types, as you have is good - likely to be widely recognized. As you add more features, you’ll need to look at more specific ontologies likes calendars and events.


Nice app!

Question, can I save tasks to my Pod?

A key pattern with Solid-based RWW apps is that the WebID-Profile doc of an authenticated User Identity should inform said app about about Data Storage location. Here are some WebID-Profile doc relations that are currently associated with this pattern, via my WebID-Profile doc:


As far as I understand, as long as you login with a solid account (instead of using the offline mode), tasks will be stored on your pod, right? My understanding of “pod” is the solid server. For example, one account in

This is something I don’t know about and I think it may be related with what @pheyvaer was talking about. I’ll look into it and if I’ve got some doubts I’ll let you know. Thanks for the links :slight_smile:


Yes, this works fine. When creating a workspace, it shows my storage and then I can choose a name for it. I can then find the data at<name>/


When I am logged in I should be able to see my WebID as a hyperlink that anchors my literal label.

The pattern for this is <a href="{webid}">{object-of-foaf-name-relation}</a>.

In addition, it would be beneficial to inform the user about default storage via pattern:

<a href="{webid}">{object-of-foaf-name-relation}</a> default <a href="{object-of-pim-storage-relation-or-ldp-inbox-etc}"> storage </a> .


Can you elaborate what’s the benefit of doing that?

About the storage, I still have to read a couple of links that have been posted on this thread to learn what storages are. Once I know them, I’ll see how to approach your suggestion :).


It takes one mouse-click or a mouseover to see what Identity your application is working with :slight_smile:


Shouldn’t that be seen with the name already? Unless you have the same name in different servers (which I guess is common).

The problem I see with placing the link on the name as it’s implemented now, is that it is displayed on the navigation drawer at all times. And I’m not sure if I’d want to add a link in there just for this reason. Maybe what I can do is include it on a “settings” panel or others that I plan to include at some point. Basically I agree that this information should be accessible somewhere within the app, but I’m not sure if the navigation drawer is the most appropriate place.

Thanks for your feedback, I’ll think about it and let you know once I’ve added this :).


Key thing is for a WebID (an HTTP URI) to exhibit the characteristics of this kind of URI :slight_smile: