Caps Disco

[michielbdejong]

In my presentation about OCM at CS3 2023 in Barcelona I had this slide about CAPabilitieS DISCOvery ;)

Now I'm thinking if we put good capability discovery into the /.well-known/ocm / /ocm-provider document, then discovery doesn't even have to rely on the apiVersion field we have there. Older implementations will just have less entries in the capabilities object, or the object will be missing from the document altogether.

[michielbdejong]

The current resourceTypes object is weird because it seems to be used both to advertise what types of resources a server can receive, and to advertise details about how this server acts as a resource server.

[glpatcern]

Concerning apiVersion, IMHO its useful for humans, as the branding, and should NOT be relied upon to decide on caps. Yet it is used for that by Nextcloud.

[michielbdejong]

Capabilities should be about being able to process something you receive. Being able to send something or not is not so interesting to discover.

[glpatcern]

@michielbdejong can you please rebase this on top of develop, as opposed to caps-disco-base ?

[michielbdejong]

Rebased on develop.

[michielbdejong]

I think we want to start off our capabilities list with all functionalities that we introduces since 1.0-proposal1 and for which one server needs to know whether the other one supports it. I can think of the following list:

• ability to receive a federation-type share (but this should go into the share types object)
• ability to receive a share without a 'protocol.name' being set to 'webdav' and without 'protocol.options' being present
• ability to receive a share with more than one protocol (maybe merge this with the previous one?)
• ability to receive a share with a webdav uri other than the base uri from discovery (do we think this is useful, actually?)
• ability to use the code flow to obtain a bearer token (i.e. receive shares that do not have a sharedSecret)
• ability to honour an MFA requirement (this is a super important one, we don't want requirements to get lost in translation!)

Functionalities which I think don't make sense to announce (these functionalities can just be present unannounced):

• /ocm-provider being copied to /.well-known/ocm (it makes no sense to announce that in the doc itself)
• ability to send a federation share (this is implicit when such a share is sent)
• ability to send a share with an MFA requirement
• ability to send an invite (this is implicit in the existence of the invite)
• ability to receive an Invite Acceptance Request (this is implicit in the existence of the invite)
• ability to sign a http request

[michielbdejong]

so caps to add:

• honour an MFA requirement
• receive a share with new 'protocol' format
• receive a share with a webdav uri that is a relative path to added to the discovered one (not an absolute URL)
• receive a share with a code (and no sharedSecret)

webapp URI should probably also somehow be bound to the server domain name from discovery

[glpatcern]

Let's not forget:

• receive an invitation

As very first capability (in the form of endpoint)!