Send a notification to a trusted service: enumerate legal values for "type"

[moscicki]

POST /notifications

I think we should at least standardize type by enumerating legal values. “SHARED_REMOVED”.

If there is a user for some other values then the process should go via the spec. Leaving it to implementations would not standardize much.

[dvh]

I agree, but my domain knowledge is not sufficient enough to come up with all the possible values. If one can provide me a list of common usecases I'd be glad to add them. Also, if a specific implementation would like to use an own notification message, it would be best practice to discuss it with this community so other implementations could reuse it.

[schiessle]

If there is a user for some other values then the process should go via the spec. Leaving it to implementations would not standardize much.

As said here https://github.com/GEANT/OCM-API/issues/34#issuecomment-281103310 I'm also not really happy with the current state of "notifications". I also wonder if, from a API point of view, such a collection with completely independent actions is better than dedicated calls like /shares/{id}/unshare ?

[schiessle]

@dvh

If one can provide me a list of common usecases I'd be glad to add them.

In order to be feature complete with Nextcloud I see following missing actions which could all be a "notification" or dedicated end-points. As said, I'm not sure what's better...

• unshare
• accecpt/reject a share
• permission change
• ask owner back to reshare the resource
• revoke re-shared file (from the owner to the person who re-shared it or the other way arround so that he can remove it from the shares list)
• exchange auth token (used for syncing user lists across trusted servers for auto completion)

[dvh]

@schiessle

I'm also not really happy with the current state of "notifications".

I think the intention of the notifications endpoint is not quite clear. I agree that this endpoint conflicts with strict API contracts between client and server and it is not a best practice if you just provide a public API. In this case however, we are trying to come up with a flexible model to let different implementations communicate with each other. Imho there should be a clear separation of the 'convenience calls' (e.g. /notifications) and 'system calls' (which are required to make sharing possible at all). If permission communication is essential for OCM to work, then it should never rely on the /noticiations endpoint. Therefore I think it's so important to do use a compact list of enumerated values which are allowed with /notifications and maintain them within this project.

I also wonder if, from a API point of view, such a collection with completely independent actions is better than dedicated calls like /shares/{id}/unshare ?

Because /shares/{id}/unshare requires a effort from the receiving party, while it is the complete responsibility of the sharing party. The sharing party can not rely on the receiving party to actual delete the share or change permissions, other than just informing the receiver that something changed.

[michielbdejong]

The list documented in the current spec is:

• SHARE_ACCEPTED
• SHARE_DECLINED
• SHARE_UNSHARED
• RESHARE_CHANGE_PERMISSION (undocumented)
• REQUEST_RESHARE
• RESHARE_UNDO