Decouple online/offline, other app/same app, and send-invisible/send-visible in freedom social

[bemasc]

Right now, Freedom social providers can represent remote users as online with the same client app, online with a different client app, or offline. You can send messages to any of these users, but there is no way to select explicitly whether your message will be user-visible (e.g. message type "chat" in XMPP) or invisible (message type "normal" in XMPP). In effect, the best you can do is

• Online (with same app): messages are sent invisible and ephemeral ("skip-archive" in XMPP)
• Online with other app: messages are sent visible (and archived)
• Offline: Messages are sent visible and archived

However, there are more permutations that are useful. For example:

• Offline but has the app: an invisible-but-archived message could allow you to send an application state update that they will receive when they log in for the first time.
  • e.g. Facebook-Firebase can support this (both detecting that an offline user has the app, and sending a message that will be archived)
• Offline and doesn't have the app (or unsure): a visible invite message could pester the other user to install the app the next time they are online
  • e.g. Facebook (via wall post), e-mail social provider

We also need to figure out how to indicate whether a given social network can support a given type of message to a given user or not.

@dborkan @iislucas

[dborkan]

Generally SGTM, some thoughts:

• Unlike the hidden messages we are currently sending through freedom social providers, user-visible messages probably shouldn't result in an 'onMessage' event on the other side. So it might be better to create a new freedom social method like postVisibleMessage.
• Right now with Facebook we only know friends who've permissioned uProxy, so we effectively only have online_with_same_app, and offline_with_same_app. This is much better for the uProxy UX than an ambiguous "OFFLINE" status since it means we can assume offline users have uProxy and display them in the buddylist. The downside of this is that we can't get UserProfiles or ClientStates for your non-uProxy friends, and therefore can't send them any invite messages (at least not using an API like provider.sendMessage(clientId), Facebook does however have an invite popup assuming we can embed their UI into uProxy)
• online, online_with_other_app, and offline are all per client, not per user. For some users, we don't get any clients at all. We currently assume those users are offline. But if we add support for both offline_with_same_app and offline_with_unknown_app, I think we'd have to assume they were offline_with_unknown_app if we have never seen them with uProxy before.

[ryscheng]

The challenge is trying to come up with a consistent interface that works for a variety of social networks (e.g. some can queue messages, some cant. some have a notion of an invisible message, some don't). At the same time, we don't want to add so much complexity (with limited support for each provider), that it reduces the value of a common interface.

One could think of the existing interface as the minimum requirements for any social provider for the existing UX in uProxy. At a high-level, I think the overall goal here is to be able to support the user experiences that we want in the future, highly related to this issue here:
UWNetworksLab/uProxy-p2p#1535

My proposal is that we move backwards from the desired UX. I believe Izzie is working on some new mocks, which should be enlightening here.

[bemasc]

For "easy" markets, I think we can aim for an ideal UI, but for "hard" markets I think we need to enable the widest possible range of social providers, with graceful degradation when various features are not available. To me, that means parameterizing the space of social providers, with bits to indicate these various capabilities.

[agallant]

I think it is worth revisiting this, in the light of the WeChat and GitHub providers and new uProxy "private"/invite flow. I suggest we use this issue to coordinate integrating the "social2" API (https://github.com/uProxy/uproxy-lib/blob/9ebdb74427468fca1664f1e08446292541ec14f6/src/cloud/social/freedom-module.json) back into mainline freedom.

Specific questions to answer:

• Should the social API have operations that only some providers support? If so, what should the non-supporting providers do for them (error message, nop, trivial promise)?
• Should crypto be baked in somewhere at this level? (As it is, uProxy handles encrypting signaling messages, making it hard for the instanced provider itself to send messages unless they are invoked by uProxy.)
• Is it okay for uProxy to maintain its own social API (if we find we cannot resolve some issues universally, e.g. invites), and if so what can we do to make it still fairly similar/low maintenance?

@lemasque as FYI.

[agallant]

Closing in favor of #272 (the points discussed here are still relevant, but best to focus discussion in a single issue).