Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Follow-back in invite-accept response #193

Closed
michielbdejong opened this issue Jan 16, 2023 · 7 comments
Closed

Follow-back in invite-accept response #193

michielbdejong opened this issue Jan 16, 2023 · 7 comments

Comments

@michielbdejong
Copy link
Contributor

I don't remember what we said about this in during our brainstorm session at the December meeting at CERN, but if we want to add two-way contacts in ScienceMesh then the best way to do that would probably by including the follow-back invite code into the accept response

@glpatcern
Copy link
Member

Indeed, and #196 + #197 should do!

@gmgigi96
Copy link
Member

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

@michielbdejong
Copy link
Contributor Author

michielbdejong commented Jan 18, 2023

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
Copy link
Contributor Author

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
Copy link
Member

@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
Copy link
Contributor Author

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
Copy link
Member

This was eventually all fixed and implementation tested

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants