Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 16:09
    justinwb assigned #408
  • 09:41

    csarven on main

    Update solid-oidc reference. Ba… (compare)

  • May 19 14:37
    acoburn synchronize #408
  • May 19 01:36
    acoburn synchronize #408
  • May 18 16:23

    csarven on main

    Add 2022-05-18 minutes (compare)

  • May 18 12:33
    matthieubosquet synchronize #408
  • May 18 10:07
    matthieubosquet synchronize #408
  • May 18 10:00
    matthieubosquet synchronize #408
  • May 18 09:45
    matthieubosquet synchronize #408
  • May 18 09:34
    matthieubosquet synchronize #408
  • May 18 01:55
    matthieubosquet commented #408
  • May 18 01:51
    matthieubosquet synchronize #408
  • May 14 12:25
    acoburn edited #408
  • May 14 12:17
    acoburn synchronize #408
  • May 13 19:56
    acoburn opened #408
  • May 13 16:13

    csarven on main

    Add privacy-principles (compare)

  • May 12 17:03
    csarven commented #407
  • May 12 17:02
    csarven commented #407
  • May 12 16:39
    csarven review_requested #407
  • May 12 16:39
    csarven opened #407
vinnl
@vinnl:matrix.org
[m]
Oh that's great Sarven, thanks! I'll relay that back to CSS.
@csarven Ah, one thing that's unclear to me from that blurb is what "the target URL" is? The user's WebID?
Jeff Zucker
@jeff-zucker
@csarven so if I have a random URI and want to find the pod root, I walk up the Containment tree doing HEAD requests until I find one that has a space:storage Link header?
Sarven Capadisli
@csarven
@vinnl:matrix.org For example.
@jeff-zucker rel=type http://www.w3.org/ns/pim/space#Storage .
Jeff Zucker
@jeff-zucker
@csarven, ok, but there is no requirement to put that link header anywhere but at the root itself?
Sarven Capadisli
@csarven
Right.
vinnl
@vinnl:matrix.org
[m]
Thanks all. I suppose CSS will then need to be updated, and hopefully down the road all Solid servers will implement Shape Trees
Justin Bingham
@justinwb
@ericprud and i are just about to start working on CSS support for shape tree validation :smile:
vinnl
@vinnl:matrix.org
[m]
🎉️
Jeff Zucker
@jeff-zucker
@csarven - one last question on storage - can you show me an example triple using pim:Storage that the storage root should return with a GET?
Sarven Capadisli
@csarven
@jeff-zucker <> a <http://www.w3.org/ns/pim/space#Storage> .
Unless you meant Link: <http://www.w3.org/ns/pim/space#Storage>; rel="type"
Jeff Zucker
@jeff-zucker
I mean "Clients can discover a storage by making an HTTP GET request on the target URL to retrieve an RDF representation [RDF11-CONCEPTS], whose encoded RDF graph contains a relation of type http://www.w3.org/ns/pim/space#storage. The object of the relation is the storage (pim:Storage)."
Fred Gibson
@gibsonf1
I thought that #storage was a predicate only for the webid lookup?
Sarven Capadisli
@csarven
Property and Class:
http://www.w3.org/ns/pim/space#storage
http://www.w3.org/ns/pim/space#Storage
Fred Gibson
@gibsonf1
exactly, where right now the only place we currently show the property #storage is a predicate against the webid uri
Sarven Capadisli
@csarven
Anything can have a storage.
Jeff Zucker
@jeff-zucker
But the part of the spec I quoted above wants a triple, can you give me an example please?
Sarven Capadisli
@csarven
The recommendation in the Protocol does not limit its use to WebIDs.
Sarven Capadisli
@csarven
@/all There will be a 5 minute slot for a status update from the Solid Community Group at the next Solid World. Here is a dry list of stuff I've drafted that can be mentioned: https://hackmd.io/RbcQL4SVQM6S17xVgYPyvA . If I've left out something significant, please do propose it for mention.
vinnl
@vinnl:matrix.org
[m]

@csarven (Sarven Capadisli) so above, when I asked how a client should discover a storage root given someone's WebID. You responded with a blurb mentioning how a profile can expose it using pim:storage. However, you now said that a profile might not expose it.

So that means that reading pim:storage is not a reliable way for clients to determine the storage root. Clients can walk up the tree to find a Resource with a Link header indicating that it is a pim:Storage, but that doesn't work if the WebID is on a different server than the storage root.

Is a reasonable conclusion for me to draw that there just is no reliable way to determine the storage root, given only a WebID? In other words, while clients can use the above heuristics to try to find a storage root, if they want to be foolproof they should also be able to ask the user to manually enter a storage root if those heuristics fail?

vinnl
@vinnl:matrix.org
[m]
@matthieubosquet (Matthieu Bosquet) appears to say the same here: https://github.com/solid/solidproject.org/issues/607#issuecomment-899418343
Matthieu Bosquet
@matthieubosquet
@Vinnl: I think that is correct: clients need to always provide an option to enter a storage root (or rather something that would not necessarily be a storage but rather a base URI for the client app to use for its data).
vinnl
@vinnl:matrix.org
[m]
OK. Well, as a client app developer, it might possibly be useful input to the spec to know that I will not do that: that user experience is not acceptable, and not worth the extra effort of implementing it. In practice, if my apps encounter WebIDs without pim:storage, they will at this point in time just not work. I'll look at adding an error message stating that unfortunately my app won't work with their Pod server software. Hopefully at some point there'll be a reliable solution I can implement.
Sarven Capadisli
@csarven
@vinnl:matrix.org pim:storage as you know is what something can refer to. But, if you want to know the storage in which the WebID profile is located in, then that's the container that's pim:Storage.
Matthieu Bosquet
@matthieubosquet
It is one of the most important selling points of Solid that a WebID would not be tightly coupled to a Solid server/storage. I don't think it is an unacceptable user experience to allow users to store data in a location of their choice. It is minimum requirement.
vinnl
@vinnl:matrix.org
[m]
csarven (Sarven Capadisli) I don't want the storage in which the WebID is located; I want the storage in which my app should store data. So I'll keep following pim:storage for now, and throw an error if that is not found.
@matthieubosquet (Matthieu Bosquet) Users can store data in a location of their choice, as long as they refer to that location in their WebID (using pim:storage).
Matthieu Bosquet
@matthieubosquet
@Vinnl, by that, you're forcing users to publicly disclose the location of their storages. I maintain that it would be good, and I'm sorry that it is unwanted burden, to provide an input for users to manually add base URIs for them to store data.
vinnl
@vinnl:matrix.org
[m]
Yes. Happy for the spec to mandate a way to expose those in a private location. But anything other than automatic discovery is too far removed from the UX and minimisation of cognitive load that I strive for.
Sarven Capadisli
@csarven
Where your app should store data can vary though. It also depends on what specs are used in context of whatever is being done..
Take the Web Annotation spec.. for example
Possible to use annotationService
and if your implementation wants to annotate, that'd be one option.
Another could be the typical pim storage.
Or ActivityPub's outbox..
vinnl
@vinnl:matrix.org
[m]
My minimum is to support users who think "this Solid thing sounds nice, let's get a Pod somewhere and try this app here". They've never heard of the Web Annotation spec.
Justin Bingham
@justinwb

@Vinnl: I think that is correct: clients need to always provide an option to enter a storage root (or rather something that would not necessarily be a storage but rather a base URI for the client app to use for its data).

This is the purpose of data registries in the app interop spec - there’s a pathway from the identity to any number of data storage areas which may or may not be spread across N number of phyiscal storages

vinnl
@vinnl:matrix.org
[m]

@matthieubosquet (Matthieu Bosquet) to respond to this comment (since it's about the spec): if something's "quite fundamental", I think the spec should specify it. If the spec says servers should advertise a storage root using owl:sameAs statements and advertise it there or whatever (and servers actually implement that), I will support that in my apps. If the spec says I should create a Container inside that root to store my apps data, I will do that (in fact, I'm already doing that usually - but I need the storage root for that).

As long as the spec says nothing and servers haven't implemented anything, I will continue relying on whatever works for most people. Or, at some point, give up on Solid apps altogether, at least until it's become practical (but possibly forever). I can't predict for sure what others will do, but having seen what people do with websites over the years, I think it's a reasonable prediction to expect others to do the same.

@justinwb (Justin Bingham) Yes, and that's great once that's finalised and reliably implemented in different servers. But I'm looking for solutions for the apps I'm writing now - and hoping the conclusion isn't that I shouldn't be writing apps now.
Justin Bingham
@justinwb
totally fair point @vinnl:matrix.org - fwiw we’re moving really quickly. there actually isn’t any server-side support required to build apps this way, but without server-side validation you won’t have the protection from other apps that might violate schemas.
vinnl
@vinnl:matrix.org
[m]
@justinwb (Justin Bingham) That's hopeful. Though without server support, I don't see how I could create a data registry as a client app - how will I know what physical storage to point to when I create a data registry? (Not sure if I'm using the correct terminology, but you get the point: at some point someone needs to come up with the URLs that should hold my app's data, and a client app cannot figure that out by itself.)
Justin Bingham
@justinwb
yeah you can still store the discovery pointers in the pod, it’s more about the server being able to validate the contents of data as conforming to shape trees / shapes
you can do validation on the client-side, which is useful if other clients do that same, but you need the validation on the server for real interop in a more open ecosystem
vinnl
@vinnl:matrix.org
[m]
I'm not sure what there is to validate? Imagine my app is the very first app to store data in a user's Pod. There is no existing data yet. I can come up with shapes and shape trees for my app's data, but if I don't know where they should be stored, I can't really store them.
Justin Bingham
@justinwb
so if you use the pattern in the interop spec, you would bootstrap pointers from the profile document at the URI of your webid, to a data registry, and then store that data in that data registry