Here you can find the slides from my talk at #BlockchainSpirit yesterday, thanks to everyone who was there! #Solid https://speakerdeck.com/noeldemartin/showcasing-an-app-that-uses-the-solid-protocol-for-decentralized-storage
@noeldemartin Looks good!
On slide 11, you call
await task.save('https://my-pod-url.com/tasks');
I presume you usually do not hardcode that URL. How *do* you construct it, in practice?
@vinnl Hi there :) If you read the description of the deck I have a brief explanation of the slides. This in particular is what you'd ask users in the "log in" screen, instead of logging into your application, you ask them where they want the data to be stored and ask for permissions. I actually use this package to achieve that: https://github.com/solid/solid-auth-client
@noeldemartin Huh, that's interesting UX - even after you mentioned there was a description, it took me a while to find out I could scroll down 😀
Anyway, where/how do you store the location the user chose? (I'm familiar with how Solid works, just trying to figure out your data model 😀 )
@vinnl Yes sure :)
That's what workspaces are for, and why they are "special" lists. When users create a Workspace in the UI, that creates a new `ldp:Container` in the root of the storage that I got from `pim:storage` and I use the workspace name to create a slug. Inbox tasks are direct children of this workspace container, and you can create lists within which are also containers for tasks.
@vinnl There is a couple of things I need to improve: Adding and reading from the Type Registry and giving "power users" more control over where to store them, like /public, /private, /inbox, etc. The last one is tricky, because I don't want to confuse users who don't know much about Solid, so I'm not doing anything about it for now.
@vinnl Yes I agree :)
I wasn't too familiar with the Type Registry but I've been using it for a new app I'm developing and I'll probably use it going forward. In Solid Focus I'm specifically looking for `lifecycle:TaskGroup` containers in the root of the storage, and I use all the lifecycle vocab for relationships between tasks/containers.
@noeldemartin Right, so you just read the storage root, then inspect every Container in there, and then check whether that contains Inbox tasks?
Using the Type Registry for that sounds like a good thing going forward. Ideally, IMHO users shouldn't even have to think about "where" data lives - the apps they use just leave a trail to wherever it is from the user's profile (e.g. through the Type Registry).