Repository: https://github.com/solid/specification - Technical Reports: https://solidproject.org/TR/ - Code of Conduct: https://github.com/solid/specification#code-of-conduct
@gibsonf1 although the mashlib data browser was able to resolve https://frederick.trinpod.us/profile/card#me was there a reason that you designed it the way you did? was it to prevent anyone using another web browser from being able to resolve the page?
I am trying to follow your work but it is just a little bit over my head...
@mikeadams1 I just changed things such that webid remains @, the radix nodes are prefixed with t_ and the ontology exports with conceptual ids rather than radix to solve the parsing issues @namedgraph_twitter found
@mikeadams1 The goal was simply to let people have an easy to remember and type webid.
thats what i get on chrome
I get the same thing on my cell phone with safari
I had to add the explicit @base there as solid-client tried to resolve the turtle nodes with the pre-redirect @ node
So are you creating your own browser, or is it that one needs to be signed into trinpod before any of the pages will resolve to something other than code?
my only thought is...well not the only one... but, if mashlib cant resolve the page...why not?
@dmitrizagidulin how about we transfer solid/identity-panel#1 to solid/specification repo? (Need to unarchive first and then transfer the issue.) I'm not sure if there is going to be enough material or even resources at this time for a whole panel on identity, but that's for participants to decide. If you want to revive, lead it. If in the foreseeable future it is just about having the Solid ecosystem incorporate DID or WebID being compatible with DID, then maybe issue in solid/specification will suffice.
@mikeadams1 the short webid and TrinPod output are now fully compliant: https://frederick.trinpod.us/@ (fixed those pesky periods)
congrats by the way
so the subdomain represents the user
Now live in technicolour: solid/specification#217
we are a pure graph system where each node is an actual graph node - including a node that represents a file or container
I just had a discussion in app-dev about the very important need for apps to be able to trigger a Pod registration flow for new users so that many users won't be lost in the need to click another button on the IDP side to register. The flow for new users being app --> IDP registration (directly - bypassing the generic login page) --> app (logged in with new account) . To make this happen, a simple additional piece of information is needed to send to the IDP, such as landing=registration so that the IDP could go directly to that page
I'm not sure which spec needs to be adjusted to make something like this happen?
I think we should work on it as general on-boarding requirements, I don't think user should just create identity with provider suggested by an app they would like to try out.
While applications should be able to appear and disappear, identity and data should meet higher standard of permanence.