Follow-back in invite-accept response about cs3apis

[glpatcern]

Indeed, and #196 + #197 should do!

[gmgigi96]

@michielbdejong Do we really need to keep track which invite token the user used?

[michielbdejong]

Ah right, I missed that sorry. There is a nuance here though:

Say Einstein send an invite to Marie via WhatsApp.
This only has Einstein's site ID ("provider domain") and a token that has no meaning beyond request-response linking.

Now Marie accepts this invite.
In the old protocol, she would include the token for request-response linking, and share her own site ID ("provider domain") and user ID ("opaque ID").
In the new protocol, she also includes her email address and display name.

In the http response to this,
In the old protocol, Einstein's server shared nothing.
In the new protocol, Einstein's server shares Einstein's user ID, email address and display name.

So the situation after this is:
In the old protocol, all that happened was that Einstein discovered Marie's site ID and user ID.
In the new protocol, Marie also discovered Einstein's user ID, and Einstein and Marie also discovered each other's email address and display name.

I would probably have made the email address sharing optional, because some people may not have email addresses, or may not want to share their (personal) email address in the context of specific OCM collaborations, but that's a side note.

So here comes the nuance:

The fact that Marie gave Einstein her user ID implies that she is OK with receiving shares from Einstein. It's not just information discovery, there is also a "let's collaborate" gesture from Einstein and a "yes, you can send me stuff" gesture from Marie.

In the opposite direction, in the new protocol, information discovery is dealt with, but there is no "and I also want to share stuff with you" gesture from Marie, nor is there an "and I am also OK with receiving shares from you" gesture from Einstein.

The follow-back flow is more about giving Marie a third option; in addition to "accept" and "reject" she can also gesture "accept and follow-back". This is basically how Twitter works; "follow" is a one-way relationship, but follow-backs are a common pattern.

Another option would be if Einstein, from the start, gets a choice to send a one-way or a two-way invite. There could even be two types of one way invite:

• Einstein follows Marie
• Einstein sends Marie a connection request
• Einstein invites Marie to follow him

This is basically how LinkedIn and I think also Facebook work (the 3rd option is basically advertising for companies, events and pages).

[michielbdejong]

Can we read back the design discussions from 3 years ago somewhere, to understand how this was all envisioned originally and why the CS3MESH4EOSC project proposed the invite flow as an addition to OCM in the first place? Was this to avoid spam, or to help people to manage their addressbooks, or to make information discovery more flexible?

[glpatcern]

@michielbdejong we're digging out with Hugo the docs from the time (I was not much involved back then), but to answer you on a couple of nuances:

• In the new protocol we also have Marie discover Einstein's display name. That is both of them know the full (email, userID, displayName) tuple of each other.
• I fully agree we're changing the gesture and users would need to be made aware of the workflow, but IMHO this is all about collaboration, not just Twitter-like "following", so I think the concept still makes perfect sense.

For what I remember, once I stepped in as part of my contributions in the CS3MESH4EOSC project (early 2020), we tested the applications over OCM shares and it was immediately apparent that running twice the workflow was detriment to the user's experience. The context there was that E created a share for M to use E's apps at his site, but M wanted to also create a share for E to use M's apps at her site!

[michielbdejong]

Marie discover Einstein's display name

Ah, that was a typo yes, sorry. I edited my comment to correct it.

(early 2020), we tested the applications over OCM shares and it was immediately apparent that running twice the workflow was detriment to the user's experience

OK! Well, it's (almost) never too late to fix it! :) I do think implementation will have to be after the CS3 conference probably. We can use the conference to discuss this issue.

[glpatcern]

This was eventually all fixed and implementation tested