Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 24 10:58
    bblfish commented #315
  • Sep 24 10:57
    bblfish commented #315
  • Sep 24 10:43
    kjetilk commented #310
  • Sep 24 09:02
    csarven transferred #167
  • Sep 24 09:02
    csarven transferred #166
  • Sep 24 09:01
    csarven transferred #53
  • Sep 24 09:01
    csarven transferred #52
  • Sep 24 09:01
    csarven transferred #51
  • Sep 24 09:01
    csarven transferred #168
  • Sep 24 09:01
    csarven transferred #278
  • Sep 24 09:00
    csarven transferred #155
  • Sep 24 08:59
    csarven transferred #300
  • Sep 24 08:59
    csarven transferred #299
  • Sep 24 08:59
    csarven transferred #296
  • Sep 24 08:59
    csarven transferred #295
  • Sep 24 08:58
    csarven transferred #294
  • Sep 24 08:58
    csarven transferred #289
  • Sep 23 12:22
    elf-pavlik commented #315
  • Sep 23 11:11
    csarven edited #315
  • Sep 23 11:00
    csarven edited #315
Justin Bingham
@justinwb
PoLP is a guiding principle of the the Application Interoperability spec design. Data is fully compartmentalized, and ensuring information isn’t leaked through indexes is just as important as not leaking the data itself.
For example - the private type index as documented would allow any application i use to scan all registered data types, so that it can find what it's looking for. This means that any piloted application will have full visibility to every registered type of data stored in the pod, regardless of whether or not it can access that resource. If I have "Prescription" as a registered type, my Photo Manager knows that I'm medicated, even if it can’t access the resource.
Justin Bingham
@justinwb
Consequently, for private data, while a private type index approach can work functionally right now with the application interoperability specification, it wouldn’t preserve the integrity of the data compartmentalization that we worked so hard to maintain.
Given these considerations, the discovery pattern for private data is handled differently in the app interop spec. The application or agent expresses the kind of data that it needs access to, and then are told what access they have been given based on a conscious decision by the controller.
Justin Bingham
@justinwb
So - circling back to the beginning… While the pure nature of how the data is organized in the interop spec can provide basic discovery as a simple function of how it is structured - it is ultimately meant to be paired with an indexing scheme to be performant and responsive. Many indexing schemes (including type indexes) are suitable and complementary. Some indexing schemes introduce privacy implications that we have to be very cognizant of.
Henry Story
@bblfish
Hi @mwherman2000, re your comment on issue Self-Sovereign Identity Model Principles: Identifier and Identity Data Usage Licensing. You dropped in some very large high resolution pictures in there, which is great for those with glasses, but it also takes up a lot of real estate, making the flow of the ideas a bit difficult to follow. Some pictures are clearly much larger than they need to be, such as the phone screenshots.
I think you can get the best of both worlds by wrapping the images with an <img src="..." height="100" width="..."> code. This is part of the github raw html extensions capability. It does not actually give an example with img size. But I found an issue jgm/pandoc#2554 and I have tried it previously on some other markdown pages of github.
1 reply
Aaron Coburn
@acoburn
@bblfish FYI, trellis intentionally ignores certain parts of LDP. One example is that CORS conflicts with LDP's requirements for OPTIONS requests. There is a lot of good stuff in LDP, but by requiring it for Solid, you end up inheriting the mistakes, too. Plus, there is a compelling argument to be made that it should be possible to build a Solid server on top of platforms that dont attempt to implement LDP at all
Henry Story
@bblfish
Understood. Still, I think it would be good to have a wiki or set of "LDP-divergence" tagged issues where these problems are listed. It would help people like me with an LDP background to understand what is going on, allow us to provide feedback to the ldp community, and perhaps recognize that some of those are not really problems but just extensions, or perhaps even mistakes on the Solid side. (I don't know)
Henry Story
@bblfish
That would be very useful when running the LDP test suite for example.
Eric Prud'hommeaux
@ericprud
@acoburn , if you have specific erata for LDP, we can stick them in the errata document
Henry Story
@bblfish
perhaps worth opening an issue before popping them in there. I'd be happy to review those.
Aaron Coburn
@acoburn

The LDP test suite is an interesting topic. There are problems with it (aside from the fact that it will not compile on any currently supported version of Java). Basically: the test suite project is no longer maintained.

With Trellis, I made the decision years ago to fork that codebase and maintain that fork independently. https://github.com/trellis-ldp/ldp-testsuite

As for divergences with LDP, the Trellis project publishes test reports for BC, DC and IC conformance. The BC report is here: https://www.trellisldp.org/ldp/report/basic.html. You can see the MUST failures all relate to OPTIONS requests (which is intentional). The SHOULD and MAY failures are also intentional, but those are more in the category of design decisions than a problem with the spec. For example: w/r/t changing containment triples via PUT, rather than return a 412, Trellis just ignores those triples; it is a pragmatic decision to make client interactions considerably less “picky”. Consider, for instance, a client does a GET of a container and then modifies a dc:description triple, and then PUTs the resource back. If, in the meantime, another client has added or deleted a resource in that container, the PUT would technically be trying to modify those triples even though that’s not the intention. If the client wants to avoid any “lost update” data, the client can use ETags. Plus, LDP explicitly says that a server can ignore server-managed triples that a client sends.

Henry Story
@bblfish
great idea to fork that!
@acoburn I opened an issue on this solid/specification#224 perhaps you can just paste the above text, as it will otherwise get lost in the stream here.
I'll be able to get back to it more easily then when the time comes. (right now I am reading about access control)
Eric Prud'hommeaux
@ericprud
@acoburn , if i understand, Trellis won't respect containment triples on a Container PUT even if the client sends an appropriate If-Match header?
Aaron Coburn
@acoburn
that is correct. containment triples are server-managed, so a client is not able to manipulate them at all. Hence, the server just ignores any attempt by a client to set them

for instance: for the resource:
</container/> ldp:contains </container/a>, </container/b>, </container/c> .

if a client sends a PUT with:
</container/> dc:title “My container” ;
ldp:contains </container/d> .

The resulting resource will be:

</container/> dc:title “My container” ;
ldp:contains </container/a>, </container/b>, </container/c> .

(the containment triples will be unchanged)
Henry Story
@bblfish

That seems a reasonable difference. Would probably be useful to provide feedback and see if that MUST is really necessary.

(((I can't remember precisely, but I have the feeling that at the end of the LDP WG life there was a discussion about container triples being in a different linked to resource, to avoid having to PUT anything into the container. )))

Aaron Coburn
@acoburn
Internally, containment data is managed in a separate named graph, so there is already some level of partitioning happening. When a user manipulates data via PUT/POST/PATCH those operations only apply to the user-managed named graph.
Eric Prud'hommeaux
@ericprud
yeah, i like a bright line there
it could barf if it sees membership triples inconsistent with its metadata, but that's a fair amout of effort
Aaron Coburn
@acoburn
on write, there are consistency checks around ldp membership triples. Otherwise a 409 Conflict is triggered
Eric Prud'hommeaux
@ericprud
gotcha, tx
Sarven Capadisli
@csarven
Servers MUST NOT allow HTTP POST, PUT and PATCH to update a container’s containment triples; if the server receives such a request, it MUST respond with a 409 status code. [Source]
Sarven Capadisli
@csarven
So, @acoburn I thought we agreed that server will reject if request is trying to change the containment triples through the container. The only way to change the containment is indirectly by either adding or removing a member of a container.
Especially with PUT, it shouldn't do partial update. That's different than ignoring.
Sarven Capadisli
@csarven
I'm hungry and sleepy. Is it weekend yet?
Justin Bingham
@justinwb
:laughing:
Eric Prud'hommeaux
@ericprud
not for justin
Quit slacking, @justinwb !
Aaron Coburn
@acoburn

@csarven the key phrase is “trying to change the containment triples”. A client may very well not be “trying to change” these triples. It may be that between a GET and a PUT the containment triples have changed because of the actions of some other agent.

The issue largely boils down to architecture — if you have a distributed storage layer and if you want to be strict about this, you kind of have to lock your entire cluster, which results in a huge performance penalty.

Alternatively, the server can ignore containment triples and there is no need for locking.

If a client explicitly wants to avoid the “lost update problem”, that’s what ETags are for

Henry Story
@bblfish
that makes sense. So people are trying to do a PUT to add metadata? I would tend to think that that should be fetched from the resources themselves. A simple idea would be to add a SPARQL query to fill in those details.
Perhaps the metadata of those resources should be in their Link: <doc.meta>; rel=meta resource.
The only thing I think that makes sense in editing the container is adding properties on the ldp:Container itself. The way it is done with indirect containers.
Sarven Capadisli
@csarven

@acoburn The request semantics of PUT is simply that client intents to replace the resource state. What may happen before their PUT (eg. change of containment information from their last GET) is orthogonal. I used "trying" informally in chat for "requesting", but let's stick to the language in the current spec for now -- am open to paraphrasing.

Re your example requests in https://gitter.im/solid/specification?at=600ae96c36db01248a95544b , servers must reject the PUT request because it is an attempt to modify/update the containment triple set. 409. If server were to allow changes to the containment (with direct update to the container) the resource state would end up either having a) orphaned resources (by removal of containment statements), b) reference to non-existent resource (by adding containment statements, or both. a) conflicts with another requirement, and also unclear (unspecified) whether those dangling resource are completely unmanageable (re lifecycle) from here on end, b) although seems harmless, it creates additional burden on server eg. needs to respond to these non-existent resources (and possibly their non-existing auxiliary resources).

My understanding of the prior discussions (especially in the PR) was based on the above - happy to rephrase if choice of words can be better. What I'd like to know right now for starters is 1) if we have the same interpretation of the current spec text, and 2) whether there is a request to change the current requirement in light of implementation experience or better understanding of the matter.

If we need to clarify between the updates: 1) modifying existing containment statements 2) adding new containment statements or removing containment statements, I'm open to that as well. The text "update a container’s containment triples" intended to cover both cases ie. the change to the set of containment statements.

Alain Bourgeois
@bourgeoa
@csarven I feel that a problem lies in the use of the word containement could something like turtle image/description/representation of container content be easier to understand.
Sarven Capadisli
@csarven
I don't follow. Containment triples are only really about statements including ldp:contains - that's deemed to be server-managed. Client can't directly alter them.
Aaron Coburn
@acoburn

@csarven my position is that a resource’s state consists of two things: server-managed data and client-managed data. A client can manipulate all of the client-managed data (with some restrictions) and none of the server managed data.

For the most part, server-managed data becomes part of HTTP headers while client-managed data is RDF. The challege with containment triples is that they appear in the body of the RDF so they look like client-managed triples.

If we dealt with quads, it would be more obvious that the data were partitioned, but it’s ambiguous with triples.

What I think we both agree on is this: a client MUST NOT be able to change a target container’s containment triples via PUT. The difference is really about whether attempting to do so results in a 4xx or just ignoring that part.

I would argue that both patterns should be possible. Requiring a 4xx response is basically a non-starter for implementations with a distributed storage layer because you’d need to lock on the entire container on every write. In the worst case, you’d need to lock the entire server on every write.

Sarven Capadisli
@csarven

@acoburn "Ignoring" may not be accurate, especially if 200 or 204 are used for the response. That tells the client that the representation it provided is now the latest resource state - which would include the requested changes. I can see that "ignoring" could work if the response status was along the lines of a 202 so that there is an out of band step that can make sure the integrity of the resource state is maintained - I'm not saying this is a good idea or making it a proposal.. just want to illustrate but perhaps something of a consideration for implementations that need to lock the container state.

Another approach is that if servers allow PUT to update containers then they are willing to handle potential conflicts. If servers don't want to get into that, they can simply omit PUT on containers.

"Ignoring" may require a 200 with payload as response because server may need (or want?) to indicate the state as the result. Perhaps in addition to ETag.

Sarven Capadisli
@csarven

Does anyone have any new suggestions or preferences re solid/specification#215 -- need to make this happen very soon.
Sarven Capadisli
@csarven

@/all To get the most out of spec/panel meetings, I propose to prioritise meeting agenda items along these lines:

  • Announcements: General announcements, agenda review, call for scribe..
  • ReviewMinutes: Review/approve previous meeting minutes
  • ContinueDiscussion: Continue unresolved items from previous meeting
  • PullRequests: Review open pull requests
  • Issues: Take up existing issues
  • Discussion: Community feedback and discussion

This is not a strict order and there is no strict time allocation for each. The group should make reasonable effort to touch all items with sufficient time, make sure to mark unfinished discussions to be taken up in future meetings..

If there is something else that should be covered or handled differently, please say so. We can update when there are significant changes to the way meetings are held.

Fred Gibson
@gibsonf1
@acoburn & @csarven I think state level permissions are needed to solve problems like system vs user data on the same resource, where a state is a uri representing a triple. For example, the following triples (and others) are standard for a solid user:
<https://frederick.trinpod.us/@>  
    solid:account <https://frederick.trinpod.us/> ;
    solid:oidcIssuer "https://trinpod.us"^^<xsd:string> ;
    solid:privateTypeIndex frederick:t_72 ;
    solid:publicTypeIndex frederick:t_6x ;
    space:preferencesFile frederick:t_8d ;
    space:storage <https://frederick.trinpod.us/> ...
A user can easily destroy their pod by editing triples like these, so in our case we put system acl control on these states and give public read permission
Sarven Capadisli
@csarven
@gibsonf1 That's fair. I've noted https://github.com/solid/specification/issues/67#issuecomment-766962934 -- @acoburn WDYT?
Fred Gibson
@gibsonf1
On a similar note, - how would a system set an acl on system required containers like / and /inbox/ etc such that user could not delete the container and destroy their pod?
It would be great if user could have append/read on those containers, but current solid spec would not allow user to create subcontainers etc in that case