search

solid / specification

Solid Technical Reports
https://solidproject.org/TR/
MIT License
486 stars 46 forks source link

Creating an LDN inbox in a uniform way #375

Open mielvds opened 2 years ago

mielvds commented 2 years ago

Hi all! I was wondering whether adding the creation of inbox resources to the protocol is under consideration? The current specification limits itself to LDN compliance and the LDN recommendation does not cover this aspect.

This issue can be generalized to adding the http://www.w3.org/ns/ldp#inbox (or others, if you want to expand the scope) link when creating a container. I guess you can always add <> ldp:inbox <http://localhost/resource-inbox/> to your PUT request, but I was wondering what other uniform options there are?

E.g, the community server supports the following (see also https://github.com/solid/community-server/issues/1027):

In the Solid Community Server, an inbox can be registered for a specific resource by specifying a Link header with value <http://localhost/resource-inbox>; rel="http://www.w3.org/ns/ldp#inbox" when creating a resource.

Example request:

1 PUT /resource HTTP/1.1
2 Host: localhost
3 Content-Type: text/turtle
4 Link: <http://localhost/resource-inbox/>; rel="http://www.w3.org/ns/ldp#inbox"

It makes perfect sense that this is out of scope for LDN, but for Solid, the applications might require inboxes and therefore need a standardized way to create inboxes. Or is this something the data pod should do, and if so, how do you create guarentees that there will ever be an inbox?

csarven commented 2 years ago

I can't recall a prior discussion specifically about associating an inbox to a resource through Link header in a request but do recall wanting it to for any link relation - I may have looked into it with PATCH on linkeddata/gold server?

The main concern is that HTTP response headers are really controlled/governed by the server. Servers may accept requests with specific Link headers but it is inherently noncommittal. LDP perhaps makes it committal as close as it gets as per its interaction model. However, the Solid Protocol doesn't. Allowing clients to (in)directly control server's response headers may open up security considerations. The extent in which an authorization system may cover this also needs a review e.g., authorization rules in WAC about read-write operations against resources. Who what how.. can the HTTP headers of a resource can be patched is not specifically covered - perhaps need not be, I'm not sure at the moment.

Just to put an alternative approach on the table (FWIW, if/when we get there), the expired https://datatracker.ietf.org/doc/html/draft-snell-link-method proposes LINK and UNLINK HTTP methods to manage the relationship between resources.

LINK /resource HTTP/1.1
Host: localhost
Link: <http://localhost/resource-inbox/>; rel="http://www.w3.org/ns/ldp#inbox"
Link: <http://mementoweb.org/ns#Memento>; rel="type"
Link: <https://csarven.ca/linked-research-decentralised-web>; rel="original"

HTTP/1.1 204 No Content

UNLINK /resource HTTP/1.1
Host: localhost
Link: <http://localhost/resource-inbox/>; rel="http://www.w3.org/ns/ldp#inbox"

HTTP/1.1 204 No Content

Do you think the use cases where client needs to associate/manage the link relation is better done through a resource description e.g., self-descriptive or through the description resource (via describedby)?

I thought about the access request use case or generally on client errors: https://github.com/solid/specification/pull/253 . I can see it being useful for resource owner to specify the inbox they want to associate with a resource but can also see this being server managed.