Name Redirections + storage/reuse conditions during the non "invite flow" discovery methods.

[456dev]

From my understanding, once a OCM address is specified, it may be retained by the server (as well as the display name from the share creation response) for future sharing to the same identity.

this falls apart if the OCM address is temporary or might change.

my suggestion is that in the share creation response, the following fields should be added:

• optional: canonicalRecipentAddress, the canonical OCM Address that is more suitable to be stored persistently (e.g. the user id, or could be a different value per sender)
• optional: addressExpiresIn, hint to the sender that this OCM address should not be persisted as a suggestion for future shares past the specified number of seconds. (e.g because its a "privacy" / virtual OCM address that might not exist past this time). 0 could be specified to prevent persisting at all, while a number like a day could be sent for short-term rotating addresses that implementers might generate.
• optional: shareWithEmail, basicly to mirror the invite flow, if a sender wanted to create a contact for an outgoing share (although the sharer email etc is also not present in the request body, so maybe not)

additionally, I've got some other questions

• shareType in the request being user or group doesn’t really make sense to me, as how should the sending server know the type. surely the receiver is the authority for that? i've probably missed something, but wanted to check.

alternatives:
This is done using the create share response. but could also be added as separate name resolution/address info endpoint or "binding" step, to go from whatever random string a user enters into a share sheet into a solid user identity that could be reused (or not?)

usage example

I see a couple of use-cases this unlocks
say we have bob on server B as the sending server
and Alice on server A as the receiving server

server A uses an external identity provider, which issues a unique, unchanging id to each user, as well as a human-friendly slug/username/handle, which may change

so canonically, Alice's cloud user is 8e286c0e@cloud.serverA.example, while her email is aliceA@servera.example
alice want people to be able to share to them using alice@servera.example
server is configured to accept shares towards aliceA@, while specifying the canonical, so that in the future new shares will be directed to 8e286c0e@cloud.serverA.example. if Alice changes her username, e.g. to aliceB, then existing shares should keep working (identified by providerId instead of shareWith), and new shares added via provider autocomplete will work (stored the id version instead of the fragile username version)

later, Alice wants to accept a some shares from Eva, who she doesn't trust, while revealing the minimum amount of information.
she uses her provider to generate a time-restricted share address tmp.mGrXJIiL@cloud.serverA.example, which expires in 1 hour. Eva pastes it in, the server creates a binding. This hints to Eva's server that additional files can be directed to this identity for 1 hour, so comes up in autocomplete for that period, and should disappear after that time. (since its just a hint, Eva’s server can ignore it, but shares after that point can be automatically rejected anyway)

[mickenordin]

From my understanding, once a OCM address is specified, it may be retained by the server (as well as the display name from the share creation response) for future sharing to the same identity.

this falls apart if the OCM address is temporary or might change.

my suggestion is that in the share creation response, the following fields should be added:

* optional: canonicalRecipentAddress, the canonical OCM Address that is more suitable to be stored persistently (e.g. the user id, or could be a different value per sender)

* optional: addressExpiresIn, hint to the sender that this OCM address should not be persisted as a suggestion for future shares past the specified number of seconds. (e.g because its a "privacy" / virtual OCM address that might not exist past this time). 0 could be specified to prevent persisting at all, while a number like a day could be sent for short-term rotating addresses that implementers might generate.

* optional: shareWithEmail, basicly to mirror the invite flow, if a sender wanted to create a contact for an outgoing share (although the sharer email etc is also not present in the request body, so maybe not)

I don't think ocm-addresses are expected to be ephemeral, so what we have today is the equivalent of the "canonical" address you propose above.

And to be honest, I don't see the point of having an ephemeral address and the simultaneously a canonical address. The situation is the same as with email, you might want to create a temporary address for some things, but giving away the canonical address defeats the purpose in that case.

additionally, I've got some other questions

* `shareType` in the request being user or group doesn’t really make sense to me, as how should the sending server know the type. surely the receiver is the authority for that? i've probably missed something, but wanted to check.

The sharing is done by a user at a server, and the user needs to know if the recipient is one person or many people in a group. This already exists since many years in implementations in the wild,and noone seems confused :)

alternatives: This is done using the create share response. but could also be added as separate name resolution/address info endpoint or "binding" step, to go from whatever random string a user enters into a share sheet into a solid user identity that could be reused (or not?)

usage example

I see a couple of use-cases this unlocks say we have bob on server B as the sending server and Alice on server A as the receiving server

server A uses an external identity provider, which issues a unique, unchanging id to each user, as well as a human-friendly slug/username/handle, which may change

so canonically, Alice's cloud user is 8e286c0e@cloud.serverA.example, while her email is aliceA@servera.example alice want people to be able to share to them using alice@servera.example server is configured to accept shares towards aliceA@, while specifying the canonical, so that in the future new shares will be directed to 8e286c0e@cloud.serverA.example. if Alice changes her username, e.g. to aliceB, then existing shares should keep working (identified by providerId instead of shareWith), and new shares added via provider autocomplete will work (stored the id version instead of the fragile username version)

later, Alice wants to accept a some shares from Eva, who she doesn't trust, while revealing the minimum amount of information. she uses her provider to generate a time-restricted share address tmp.mGrXJIiL@cloud.serverA.example, which expires in 1 hour. Eva pastes it in, the server creates a binding. This hints to Eva's server that additional files can be directed to this identity for 1 hour, so comes up in autocomplete for that period, and should disappear after that time. (since its just a hint, Eva’s server can ignore it, but shares after that point can be automatically rejected anyway)

It might be interesting to have a canonical contact/address book entry for a user, but this is not something we should solve in OCM I think. I know there is ongoing work in the IETF for this, where you could have a jscontact advertized somewhere and where you can update your contact information when it changes. That is probably something we can look at if/when it becomes a thing, but I don't think we should do someybespoke in OCM about it.