Inox: A new pod browser by Digita

Hi all,

I just wanted to let you know that yesterday, we, Digita, released our pod browser Inox.

We would be happy to receive your feedback!!

Kind regards,
Tom

7 Likes

It looks really good! I understand it is not open source, so unfortunately I can’t go looking myself, but I’d also be interested to know a bit more about the tech stack. Especially when it comes to Solid-specific tools you’re using, of course :slight_smile:

And here’s some observations I made while trying to use it that might inform your UX, but feel free to disregard:

  • When I create a new Pod, it says my password “must be over 10 characters long and contain at least an uppercase letter, a number and a special character.” However, it also rejects if it does not contain a lowercase letter.
  • It does a HEAD request for every character I type for the username. A debounce might be a good idea there.
  • It says my WebID is https://<username>.inrupt.net, but that’s just the root of the Pod. On inrupt.net and solid.community, the WebID is usually located at /profile/card#me.
  • When I browse an empty Container, there is no difference between the loading state and the loaded state. A message like “This folder is empty” could be helpful.
  • If I edit a file, I get no feedback when it has saved my changes.
  • The logo in the top left-hand corner appears to be clickable, but clicking it does nothing.
2 Likes

I created a pod with inox on Inrupt.net but was unable to get to your dashboard. The pod was created on Inrupt server but, I was unable to browse the pod using Inox. Does Inox have access to the data I exchange with the pod? By creating the pod using Inox does that automatically list Inox as a trusted app in the pod I created on the Inrupt server?

Actually, I just checked to see if the pod I created on Inrupts server listed Inox as a trusted app, it did not. I went back to Inox and tried to log in again and was prompted for trusted app at that time. Could not find a logout button either.

As the timeline feature seems to be our main innovation I’d like to know how you expect this to work out.

I’ve seen that it creates an /events folder, where it stores all the events that this app made. But, as it can’t track other apps, it only shows the events of the inox app. How would I get the information, that “An Online Retailer used [my] address information to send an online order”?
Is this something that every app is expected to provide to you? Something you would like to see standardized / in the specification?

Apart from that:

  • I like the use of the monaco editor. Looks nice with convenient shortcuts
  • if you want it closed source you probably shouldn’t include source maps
  • error handling could be improved (e.g. saving file if the app only has write permissions)
  • you could try matomo/plausible/… instead of GA
3 Likes

Great App! I like that I can connect multiple pods, but why only one per provider?

2 Likes

Hey everyone,

Thanks for taking the time to provide feedback, really helpful and well appreciated.

We’ve already fixed most of the (initial) feedback provided to us by the community. Among others

  • We drastically reduced the initial loading time.
  • We added notifications, for example when a file has been saved or when an error occurred.
  • We improved the responsiveness of the application (like debouncing when searching for username).
  • We improved the user experience (like making a clear distinction between an empty container and the loading screen).
  • We fixed other minor bugs and typos.

Furthermore, regarding A_A’s question about the timeline. Our goal is to provide the user with a comprehensive overview of what happened to their data. At this time, it’s up to the client apps to register these events. Obviously, that’s not a great solution. A much better solution would be if Solid servers would log these events in the user’s pod. This could be achieved by adding it to the specification, or leaving it up to the individual providers so they can offer it as a (differentiating) feature. But standardization would be necessary either way.

Finally, we weren’t able to reproduce the issue reported by @Adventure. But as you say, you need to connect to the pod before you can access it in Inox. You should be prompted to do so once you created the pod. Also, you’re able to disconnect a pod by clicking the “+” button in the navigation rail, and clicking the disconnect button. Let me know if you still experience issues.

We’ll continue to invest time and love to make Inox awesome. Our roadmap is still packed with many great features, such as connecting multiple pods per provider (@Aveltens). Let me know if you have any further suggestions by using the forum, or reaching out to wouter@digita.ai.

Kind regards,

Wouter

1 Like

Hi Wouter, perhaps a better solution would be that a user has the possibility of adding a new (architectural) layer to his Pod, which in this case is provides logging. (other layers could trigger actions, manage errors, etc). The spec should allow user’s to ‘plugin’ their own Pods.

ps. I really liked the feature of having a ‘bird’s eye view’ of all your pods.

This looks very interesting.

I could evaluate further based on the fact that Idp binding appears to be hardcoded.

The usual pattern is as follows:

  1. Present a default Idp
  2. Allow users to enter their preferred Idp – for instance mine are https://solid.openlinksw.com:8444 and https://solid.openlinksw.com:8445
  3. Allow users enter a WebID – mine is https://solid.openlinksw.com:8444/profile/card#me

Looking forward to testing this properly once there is some clarity about the issues above :slight_smile:

I’ve managed to at least make a non-default IDP show up by entering a non-inrupt.net and non-solid.community WebID in the “Search for your Pod server” field. That appears to work for your IDP and WebID as well?

Yes!
It is working now.