Follow-back

[michielbdejong]

Depends on #129 and #128

When accepting an invite, the receiving efss makes a call to the receiving reva, which makes a call to the sending reva, so that the invite is marked as accepted there, and a display name, opaque user id at the receiving site, and receiving site name become available to the sender. nothing happens or is stored in the receiving site.

Nothing is saved at the receiving site though.
To reject an invite, the only thing the user has to do is to not click 'accept'.

This is fine if the only purpose is for the invite sender to gain a contact as a potential sharee.
But we could add functionality to this situation.

Mainly, what if the recipient wants to "follow back", i.e. accept the incoming invite and also send an invite of their own back to the sender? The best way to build that would probably be to include a follow-back invite id in the accept response at the OCM level. That way, the contact that is established is reused to send the follow-back to the right person.

[michielbdejong]

I created cs3org/cs3apis#193 about this.

[michielbdejong]

To describe the problem in another way:
OCM invites establish just a one-way relation. After Einstein sends an invite and Marie accepts it, Einstein will see Marie as a ScienceMesh contact, but Marie will not see Einstein as a ScienceMesh contact.

In the ScienceMesh network testing we've done over the past few years, this did sometimes feel weird and confusing, so I think this is quite a significant issue and we're probably not going to be able to fix it in the 7 weeks that are left before the CS3 conference.

[david-antos]

Well, it is mostly by design, as in this scenario, Einstein wants to share a resource with Marie, so he invites Marie. He can possibly later reuse the relationship for other resources. We didn't originally expect this to be bidirectional by default.

We have several possibilities with what Marie will see in her system. For the start, it would be great to pass the information that this particular share is from Einstein, so that it is visible for her in the listing of shares. Ideally, this should generate an item in her contact list in the category "shared by other people". It would be good also to be able to keep additional information with this contact, so that Marie can write who the contact actually is (as it can have a technical, not human friendly, primary identifier). This is all for the purpose of Marie to be able to identify originators of shared resources.

I am not sure whether it is a good idea to create the trust relationship from Marie to Einstein automatically at this point, based just on the previous procedure. Einstein sent an invite, Marie accepted it. The question is, is this sufficient also for Marie to trust this procedure so that she would want to share resources to Einstein directly using that?

From Marie's perspective, she received a mail with a link from somebody claiming to be Einstein. Using the Science Mesh, she could verify the link is genuinely pointing to a valid Science Mesh service. But still, it verifies that the mail is from a Science Mesh user (claiming to be Einstein). Marie can see an expected resource to be shared, something she discussed with Einstein before to be the case. In that case, it may make sense for her to mark the contact as verified and use it as such. I don't think it should be the default, though, as she cannot be reasonably sure about anything else than the invite came from a Science Mesh user and she needs additional verification of his identity.

It would definitely help to pass reasonable information about the users in this process, such as at least display names, associated mail addresses etc., releasing those attributes should be controlled by the user as they aren't strictly necessary for the basic functionality. I can imagine Marie would receive an invite and it shows "this is from Einstein who released his display name Albert Einstein, mail address albert.einstein@eth.ch from his system ETHBox, this information is verified by the Science Mesh. Do you wish to make him a direct contact in your contact list?". Or, if attributes are not sufficient, "this is from alb364762@eth.ch, no other contact information available as the user hasn't released additional attributes, you're advised to proceed with caution and make sure you expected this share to arrive, preferably also contact the user the way you're used to communicate with him/her".

I'm whiteboarding here, of course, but when designing the invitation scenario, the complexity of the "opposite direction" made me keep it one-directional.

[michielbdejong]

I think with cs3org/cs3apis#199 we will be able to make it two-directional now.