solid / notifications

Solid Notifications Technical Reports
https://solid.github.io/notifications/protocol
MIT License
11 stars 7 forks source link

Why does notification negotiation happen through an endpoint rather than in a resource-oriented way? #14

Closed RubenVerborgh closed 2 years ago

kjetilk commented 3 years ago

My main concern (in fact, the only concern I have with the present proposal right now) as that it raises the question: Who controls the URI space? Is it the owner of a storage, is the server admin (which is an entity we don't currently define), is it whoever as a Control privilege?

These endpoints may end up (and would probably usually do so), within the URI space of a storage, and so, their naming may collide with other usages that the storage might have for the same names, it has to be managed somehow.

This suggests to me that the storage owner should have the authority to name the endpoints. Therefore, it is awkward to have the discovery of the endpoints in a server-wide endpoint, that essentially transfers the authority of the URI space from the owner of a storage to some other, unknown entity.

I think we should be very restrictive about letting a "server admin" have control of the URI space.

In https://github.com/solid/specification/issues/310 , I suggested we make the discovery of storage easy and thereby place further management of the URI space of a storage into the hands of the storage, which is where I think it belongs.

And, BTW, given that we should be restrictive about a "server admin"'s control of the URI space, the request body won't be large, and therefore should be suitable as a payload to an OPTIONS * response. We shouldn't need out-of-band knowledge of .well-known URLs.

elf-pavlik commented 2 years ago

To what extent #29 addressed this issue?

acoburn commented 2 years ago

Resolved via #29