Should Solid Apps have pretty urls?

Build a Solid App
1

I’m a big proponent of using pretty urls in websites, so when I started making Solid Apps I used them out of habit. But recently I’ve been having some discussions and I think it’s a topic worth discussing.

Imagine that you store recipes in your POD, and you’re using an app to browse them. If you have a recipe called “Pizza”, when you open it in the app the url could be something like https://my-app.com/recipes/pizza.

Similarly:

  • https://my-app.com/recipes/pizza/edit could allow you to edit the recipe.
  • https://my-app.com/recipes/create could allow you to create a new recipe.
  • https://my-app.com/recipes could show all your recipes.
  • etc.

And that’s how I’ve been doing it thus far. However, when it comes to Solid, we have some problems with this.

For example, what does the url https://my-app.com/recipes/pizza mean? If you’re logged in, that’s the “Pizza” recipe in your POD. But what if you’re not logged in? Also, if you copy&paste the url and send it to someone, they will see a very different page. If they’re logged out, they’ll get a 404. And if they’re logged in, they’ll see a different recipe.

The way I’ve been resolving this is having a separate page for sharing, which I call “the viewer”. So if you were to share your recipe, this is the actual url you’d be sending someone else: https://my-app.com/viewer?url=https://my-pod.com/cookbook/pizza#it.

In terms of architecture, this is a lot better. And it makes me wonder if I should make my entire app like this, thus removing the idea of a viewer altogether. But I’m still not convinced that this is the way to go, because I can see some drawbacks to this type of url:

  • It’s too long, and not easy to remember.
  • The most meaningful part is on the query string, which may be removed by some software.
  • Sending a url in the query string means you need to take special care with encoding special characters.
  • I don’t like it >.<.

And yet, I cannot come up with a better solution :/. But I’m still hesitant to go into this direction, because I don’t think the UX is great. And this would make Solid Apps even more quirky for users.

One idea I’ve had is do something like https://my-app.com/recipes/{base64-encoded recipe url}. Which solves some of the problems, but worsens others and introduces more (like obfuscating the recipe name).

So yeah, I’m torn on this and I’m not sure what the “best practice” should be. What do you think?

2 Likes
2

I would typically just encodeURIComponent(uri) and put it into the path:

`https://my-app.com/recipes/${encodeURIComponent(recipeUri)}/edit`

This has all the issues of your base64-encoded solution, minus the obfuscation (almost :sweat_smile:).

In any case this is a great question, and i’m looking forward to reading other people’s ideas…

2 Likes
3

Hi Noel,

Interesting question!
What do you think of this scenario:
Perspective:

  • Applications are only views on data, your data in your POD is the starting-point and as a url more consistent for sharing.
  • Applications can change, be revoked, or multiple applications can be used as a view on the same data
  • Social sharing in a more decentralized way could be more data/pod focussed instead of app-focussed, thus could better start from a POD-url

In a context of social sharing, sending your recipe with the view my-app.com could be something like:
https://my-pod.com/cookbook/pizza/view?url=https://my-app.com
https://my-pod.com/cookbook/pizza/edit?url=https://my-app.com

Basic scenario

If you share this link with someone else (Alice):

  • Share as view - Alice is not logged in or logged in
    Alice visits link and see recipe as a view generated via my-app

  • Share for edit - Alice is not logged in
    Alice visits link and is being asked to log in

  • Share for edit - Alice is logged in
    Alice visits link and can edit recipe as a view generated via my-app

Advanced scenarios

1. Multiple apps

You use multiple apps for viewing and editing this recipe: my-app1 and my-app2
https://my-pod.com/cookbook/pizza/view/url?=my-app1.com
and
https://my-pod.com/cookbook/pizza/view/url?=my-app2.com
should take Alice to the the specific application.

https://my-pod.com/cookbook/pizza/view/url?
could show a list of applications to Alice you have granted access to view/edit.

2. App stops or is revoked

You previously shared with Alice the link
https://my-pod.com/cookbook/pizza/view/url?=my-app1.com

After that my-app1.com stops its services or you revoked access-rights to this app, and currently you use my-app2.
When Alice visits the above link she gets a notice this app isn’t used anymore by you and Alice can be redirected to
https://my-pod.com/cookbook/view/url?
which shows the applications you currently use or just the raw view generated from your POD-OS.

3. New App

Alice has found a new useful recipe app (my-app2), but you only know my-app1.
Alice could of course send you a link to the actual website, but could also use the following link to suggest my-app2:
https://my-pod.com/cookbook/pizza/view/url?=my-app2.com
When you visit the link, you are redirected to the application and if you want the Solid-OIDC process starts.

Curious to hear what you think of this scenario?

Cheers,
Gijs

1 Like
4

In many regards, I think this is where we’ll start to see my traditional apps just storing data in solid, rather than using solid in the browser, everything happens server-side.

It also depends on what problem you want to solve for? Should your application have shareable URLs? Do you need the URL to encode the resource being operated on (this could be stored in localstorage for instance)? Does 100% of the data need to be stored in the Solid pod? (E.g., session identifiers are often stored in cookies as JWTs or opaque identifiers in redis)

It could be valid to have an architecture where the data is stored in solid, but the server stores a “short identifier” for the longer resource URL, much like a link shortener. You may also have the session cookie/state store the pod IRI such that you just need to work with the path segment in your application, and then have an explicit “share/copy link” functionality

1 Like
5

I agree 100% in theory, but in practice I worry that most people won’t know what to do with a plain Solid url. And if they visit the url directly, with most POD providers nowadays, they’ll be met with some gibbersih.

It’d be nice if some day this were possible. But as things stand right now, I don’t think sharing just the Solid url is an option.

The main problem I see with this approach is that this depends on the Solid POD. Until this type of thing is supported by the spec, it won’t be possible. And I think we’re very far from that. I’m trying to learn how to do apps today, not what to do in an hypothetical future.

One note on this, though. I don’t think I should grant any applications to view/edit. I grant Alice, and she should be able to use any application she likes (including applications I don’t even know exist). Which is already how Solid works today, so that’s nice.

The use-case I’m trying to solve is that I’m using a Solid App, and I want to share some content with someone else.

In this example, I’m using a recipes manager and I want to share a recipe. Ideally, I would share only the recipe, without referencing any app, and the person I’ve shared the recipe with could open it with their favourite recipes manager. But that isn’t feasible today (because most people wouldn’t know what to do with a Solid url), so I have to share an app url pointing to the content.

The problem is that I think the most intuitive way to share something is copy-pasting the url of the page you’re viewing. But currently I’m using a separate url for all the reasons I mentioned, and that’s what I’m pondering.

In a way, I think this is what I’m doing. But I don’t like the idea of storing data in my server, even if it were only for shorter ids. So far I’ve been making apps that live completely in the frontend, and that’s one of the things I like the most about Solid.

1 Like
6

What is already possible in the spec is to save html and js content into a pod. This admittedly has security implications that are currently being dealt with by trusting apps entirely. However, what could be done is for the app to save a landing page on the user’s pod and sharing the link to that landing page.

What would happen when visiting is therefore that the file view.html was saved by the app and includes logic to read its query parameters.
The simplest behaviour could be to use a refresh to load the corresponding recipe in the app.

https://my-pod.com/cookbook/pizza/view.html?url=https://my-app.com

Rather than having a landing page for each recipe, you would probably instead use:

https://my-pod.com/cookbook/view.html?recipe=pizza

This is then consistent with a data-centric viewer pattern, which has the advantage that it knows it’s own RDF namespace.

It’s up to the app creator the extent to which they advertise competing apps, and up to the user if they’re happy with how the app deals with it. In principle they can use another app to override the landing page behaviour.

7

Regarding this, I’ve written a post now about why I think it is not secure to use html files on pods: Is it secure for pods to serve html files?

If you have thoughts on this, I’d be happy to hear about them!

8

Thanks! I’ve answered there, but in short, no it’s not secure, but executable code is part of the read-write web and solid does eventually need to settle on a security model to allow it.

In the mean time, umai could clearly disclose what JS capabilities it is using in the landing page and ask consent from the user before adding the view.html to the relevant folder.

It could also mention that some pods may prevent this capability and provide a link to a view.html file that could be sideloaded to the pod if necessary. Perhaps this could be thought of as an add-on to the pod, which happens to only require saving a html file to the right place.

1 Like