Unify social and social2 APIs

[bemasc]

The freedom social interface assumes that your buddy list is managed using some other client. This makes sense for traditional chat networks, but makes less sense as we try to expand the range of supported communications systems (e.g. e-mail, Google Sheets). It would be nice if the buddy list could be managed directly on the freedom client.

Proposed new methods:

• boolean hasRosterControl()
  • Returns false for all current social network implementations.
• boolean addContact(string introductionToken)
  • Adds a remote user, represented by a string in a format proprietary to this social provider. Returns false if the action failed (e.g. contactToken was malformed)
  • For e-mail, the introductionToken is the e-mail address, which is also the userId
  • For Google Sheets, this might be the URL of a spreadsheet that your friend has made available.
• string getIntroductionToken()
  • Gets a token that a friend can pass to addContact for this social provider. This token may be single-use or reusable.
• boolean removeContact(string userId)
  • Removes the specified remote user from the roster

@dborkan PTAL

[dborkan]

Generally LGTM, some thoughts:

• hasRosterControl seems a little weird: freedom modules don't actually return booleans but rather Promises<boolean>, so it might be just as useful to leave this method out and have the other methods return Promise.reject instead.
• addContact and removeContact wouldn't need to return a boolean, just Promise.resolve or Promise.reject
• We may want addContact to take in additional fields that correspond to the UserProfile (userId, name, image, url).
• Also we may want addContact to return a Promise with the UserProfile or userId it generated
• We should discuss with the Freedom folks whether we want this to be an extension to the existing social interface, or alternatively it could be a brand new interface. That way we don't have to worry about adding these methods to our existing social providers (even if they just return Promise.reject) or future social providers that don't support them

[bemasc]

hasRosterControl seems a little weird ... it might be just as useful to leave this method out and have the other methods return Promise.reject instead.

The trouble is that we want the program to be able to show/enable the user interface for adding contacts only when using a social network that actually supports this feature. Finding out after the fact that it didn't work is too late, and we still don't know why it didn't work. (Maybe it was a malformed token.)

We may want addContact to take in additional fields that correspond to the UserProfile (userId, name, image, url).

My theory is that this can be done in-band (through the social network) once the initial introduction is in place. Do you have a motivating use case? How do we allow this but also allow very short introduction tokens in cases where the user has to handle them?

[dborkan]

hasRosterControl seems a little weird ... it might be just as useful to
leave this method out and have the other methods return Promise.reject
instead.

The trouble is that we want the program to be able to show/enable the user
interface for adding contacts only when using a social network that
actually supports this feature. Finding out after the fact that it didn't
work is too late, and we still don't know why it didn't work. (Maybe it was
a malformed token.)

OK this makes sense. Although the alternative approach of creating a new
freedom interface rather than extending social would be an alternate
solution

We may want addContact to take in additional fields that correspond to
the UserProfile (userId, name, image, url).

My theory is that this can be done in-band (through the social network)
once the initial introduction is in place. Do you have a motivating use
case? How do we allow this but also allow very short introduction tokens in
cases where the user to handle them?

Thinking about this a bit more I guess it's not required. We do need an
onUserProfile event to be emitted for every contact, but if addContact just
returned Promise.resolve(), we could just separately emit
'onUserProfile' for the new user, and I don't think it would matter that
uProxy couldn't detect that the new UserProfile was the result of the
addContact call.

[ryscheng]

How does this interface extension affect the current implicit assumption that "buddies" involve consent to distribute presence?

One of the biggest pieces of feedback that we got during our user experience trip is just how frustrating it can be to coordinate with friends. This includes invitation to install the program, finding friends on uProxy, and requesting consent. The findings are being tracked here:
UWNetworksLab/uProxy-p2p#1535

I agree we need to do something to improve this UX, I'd wait until we have a better idea of what UX we really want and then decide if the proposal here is consistent with that. I believe Izzie plans to bring this up at the next UI sync.

One potential alternative to adding buddylist management to the interface is to just assume a global buddylist in these cases. (e.g. in Google spreadsheets). This would be consistent with one such proposed UX, where we always hide the buddylist and allow users to explicitly add users (if they're already friends & both have uProxy), or allow users to invite friends (if they're already friends & the friend doesn't have uProxy), or allow users to invite new friends (if they're not friends on the social network yet)

[bemasc]

How does this interface extension affect the current implicit assumption that "buddies" involve consent to distribute presence?

For something like an e-mail-based social provider with ping-pong e-mail liveness checks for presence, I expect the remote peer would just appear to be offline until they consent.

I think the methods listed here (and in #273) are the basic primitives needed for pretty much any user-adding design, but I'm happy to wait for a meeting to discuss it.

[dborkan]

We are starting to experiment with social networks where we need some interface to add a contact (Quiver, Firebase email). Both of these still have a lot of technical issues, and there remains a lot of political/philosophical debate on whether we should even do them in the first place, but in the short term we really do need an API to add contacts in order to move forward. Do you think until we all come to agreement it makes more sense to create a new Freedom interface (not part of the freedomjs/freedom providers definition) that supports addContact? (question for @ryscheng )

I agree we need UX eventually but I think we need to start experimenting now to see what is possible, and not wait for a completely new UX design in #1535. As much as I'd like for Izzie to come up with a great UX and us to implement it for all social providers, I think the reality is that all the social providers we know of have major limitations, and we need to make in-uProxy-but-not-publicly-available social providers to see what is actually going to be possible.

[ryscheng]

There is a 3x3 matrix of possible start and end points here:

• Does the user have the ability to send messages to the other user?
• Does the user see presence messages from the other? (potentially done in-band using the first property)
• Do both users have the same app (e.g. uProxy) installed? (invites)

Presumably for uProxy, the important thing is that all 3 of these are true. So does addContact(...) reject unless all 3 are true? How do we handle partial errors in this case? How do we deal with social providers that cannot achieve 1 or more of these properties?

Can you give me a sense of which social provider we want to have support all 3?

[bemasc]

So does addContact(...) reject unless all 3 are true?
I expect that addContact will generally only reject if the contact description is malformed or trivially nonexistent.

For example, in a reverse-engineered total-control Facebook provider, I imagine that getIntroductionToken might return a string that conveys both the initiator's userid and a single-use code, and addContact on the receiver would resolve if a user exists with the given userid, and reject otherwise. It would also initiate a friend request to the initiator, with the message containing the code. The initiator would see the friend request, check the validity of the included code, and accept the request.

Obviously I'm not proposing that we actually implement this for Facebook, but there are other social providers where this sort of flow may be appropriate.

[ryscheng]

Cool. I see what you're saying now. I think there's 2 open questions in my mind still. Apologize for the time difference/delayed responses. Wouldn't mind just having a VC about this soon.

2 questions then:

• Under what circumstances do we need a single-use introduction token? One potential option is to just assume that the introductionToken === userId. This would satisfy most cases e.g. Google, FB, email/Firebase, IRC, XMPP etc. For the Google spreadsheet case, you could imagine having the URL of the spreadsheet be something requested upon login (similar to specifying an XMPP server for generic XMPP). This would simplify the interface to just add/removeContact and hasRosterControl.
• A "buddy" in our existing social interface means something very specific: the ability to send messages and the ability to receive/send presence. In most cases, this typically requires 2-way consent (think XMPP add buddy, or FB friend req). How do we deal with approvals in this case (e.g. in Firebase)?

[bemasc]

If the token is just the userid, then how do you avoid promiscuously
accepting all friend-requests in a Facebook-like case? The idea of
single-use tokens is to protect against that. You can think of it as a
kind of bidirectional consent: the sender consents by providing the code
out of band, and the receiver consents by returning it in-band.

I said earlier that the token might just be the userid in many cases ...
maybe that was wrong. I think that might only be true if you want to run a
promiscuous node.
On May 20, 2015 8:55 PM, "Raymond Cheng" [email protected] wrote:

Cool. I see what you're saying now. I think there's 2 open questions in my
mind still. Apologize for the time difference/delayed responses. Wouldn't
mind just having a VC about this soon.

2 questions then:

• Under what circumstances do we need a single-use introduction token?
  One potential option is to just assume that the introductionToken ===
  userId. This would satisfy most cases e.g. Google, FB, email/Firebase, IRC,
  XMPP etc. For the Google spreadsheet case, you could imagine having the URL
  of the spreadsheet be something requested upon login (similar to specifying
  an XMPP server for generic XMPP). This would simplify the interface to just
  add/removeContact and hasRosterControl.
• A "buddy" in our existing social interface means something very
  specific: the ability to send messages and the ability to receive/send
  presence. In most cases, this typically requires 2-way consent (think XMPP
  add buddy, or FB friend req). How do we deal with approvals in this case
  (e.g. in Firebase)?

—
Reply to this email directly or view it on GitHub
#272 (comment).

[agallant]

So this issue is a bit stale, but I'm revisiting because it's related to another outstanding issue we should resolve - unifying the social/social2 APIs - which is basically about the same thing. Simplified arguments in favor of each:

• social2: supporting buddy invites is valuable and practical for many applications
• social: the buddy/invite idea may not be natural to all social providers we want to support (e.g. email, broadcast services w/asymmetric relationships, etc.)

Possible approaches:

• Replace social w/social2, return warnings/errors in providers that can't provide all functionality
• Support both social and social2 in freedom (closest to the status quo, officially pulling it in would just simplify specifying it elsewhere)
• ??? (i.e. suggestions welcome)

My opinion actually isn't terribly strong on this, just be good to have it resolved one way or another.