I just posted a video showing what you can do with the framework I'm working on, Aerogel. Check it out! https://www.youtube.com/watch?v=JXyCH_S9efk
@noeldemartin that's looking really cool!
I think my only concern is probably the authn events.. because if you're backing to Inrupt's SDK for authn, it doesn't correctly expose state which means your application loads in an unknown state, which causes a lot of issues to say the least.
@thisismissem Hey thanks :D.
It does use Inrupt's library for authentication, although it can be configured to use something else (Inrupt's library is the one used by default).
What do you mean that it doesn't correctly expose the state, can you elaborate?
@thisismissem Hm I'm not sure I understand what you mean, but the authentication information is exposed through the $solid service. You can check if you're logged in with $solid.loggedIn, for example. And by default it initializes logged out, but you can configure it to auto reconnect on start up.
I guess you could say it is a state machine with the following states:
- Logged out
- Logging in
- Logged in
Maybe I could improve that and make it more explicit, is that what you mean?
@noeldemartin right, so when you do "restore session" you're not initially in a logged in not logged out state, nor logging in, you're in a fourth state that's a loading state.
Where the silent authentication takes place & the redirect flow happens. It's a bit hard for me to explain these days (haven't touched Solid in. ~6 months)
@thisismissem Hm I see what you mean, but I think that's not an issue in my case. There is no "restoring session" state because the $solid service is not ready until the session has been restored (or failed restoring). So by the time the app has booted, you're either "logged in" or "logged out". Services have this concept of "booted", and until they are fully booted the app doesn't even render anything on the screen.
@noeldemartin ah, okay! so you've perhaps side-stepped that issue nicely then.
@thisismissem Well it's not super nice because the UI is blocked longer than it should, which is a problem I'm aware of. But it's a trade-off I'm willing to live with for now.
Thanks for your feedback, I'll keep it in mind when I work further on this :).
@noeldemartin basically authn initialises in an unknown state, and that's not exposed, this is what made PodBrowser have a bunch of issues, compounded by the react-SDK that didn't bind to the correct events.
That is, authn should be a finite state machine, but it's actually not.