[Telepathy] Spec meeting: Facebook server messages, protocol objects, RequestedPresence, Anonymity, Mute, Conn.Iface.Cellular

[Will Thompson]

Hello world,

Simon, Sjoerd and I went over a bunch of bugs and proposed additions to
the Telepathy spec today. Non-trivial topics:

• Server messages on Facebook Chat don't make it to the UI for two
   reasons;
• Protocol objects;
• Better feedback from setting RequestedPresence;
• Anonymity (aka hiding your caller ID);
• Mute;
• Cellular-specific properties on Connection.

== Trivia ==

• clarifying when MessageSent should be emitted
   <http://bugs.freedesktop.org/show_bug.cgi?id=27282>: yes
• labelling message parts which are thumbnails
   <http://bugs.freedesktop.org/show_bug.cgi?id=27262>: yes, but also
   specify that 'alternative' shares a namespace with 'identifier'.
• Use handler capability tokens to indicate support for audio and/or
   video on Call, rather than needing three handler filters
   <http://bugs.freedesktop.org/show_bug.cgi?id=27335>: yes.
   · Later, Sjoerd noticed that this means that to express "I support 1-1
     video calls, but only audio in multi-party calls" you need two
     handler heads. But this is an edge case, and you can't express this
     at the XMPP caps level either.

== Server messages on facebook ==

<http://bugs.freedesktop.org/show_bug.cgi?id=26696>: Message from
Facebook Chat when it disconnects you for signing in from a new location
doesn't reach the UI

First problem: Gabble doesn't think chat.facebook.com is a valid handle.

• Should Gabble let you request a handle for JIDs with no node part? If
   so, then if you mistakenly try to contact 'will.thompson' rather than
   'will.thompson at collabora.co.uk', the failure will occur much later
   than it currently does (since at the moment Gabble won't give you a
   handle, or a channel, for the former).
• Idle is a bit more tolerant of contact IDs it receives from the
   network than those it receives over D-Bus, because bip uses a nickname
   that's illegal per the IRC RFC. This would be an acceptable stop-gap
   solution in Gabble, too.

Second problem: what do we do about channels appearing as the connection
closes?

• this could be a property of the disconnecting state in hypothetical
   Telepathy 1.0?
• add a flag for "i'm well behaved, i'll close up my own channels"
   · problem: then you have to ack all the messages before you can
     reconnect
   · here's a bad idea: uniquify channel paths across connections, make
     channel outlive connection. rejected: you need the connection to
     look up aliases and do other useful things with a channel.
   · here's another bad idea: re-use connections, rather than having them
     die when they become Disconnected.
• we punted on this for now.

== Protocol objects ==

<http://bugs.freedesktop.org/show_bug.cgi?id=20774>

Implementation details:

• the tp-glib implementation involves subclassing TpBaseProtocol. it
   supports CMs like haze which discover their own protocols at
   run-time, as well as CMs that have one or two staticly-determined
   protocols.

IdentifyAccount:

• This makes it possible for MC's account path to be sensible, and be
   the same if you delete and re-create account so that your old logs
   match up.
• Also solves the problem where you can create two accounts for the
   same JID and then can't actually connect them both at once, as Siraj
   mentioned on #telepathy today.
• We could add an "IRC Network" parameter which Idle ignores but uses
   to generate responses to this? This would mean that if you switch
   between two servers on the OFTC network, the account path could
   still be wjt at OFTC or something.

NormalizeContact:

• Needs explanation of why it's best-effort only, with reference to XMPP
   where foo at conference.bar/bong.hits would be normalized to
   foo at conference.bar by this method even though that's wrong.
• Why might it raise NotImplemented? Salut.

Guaranteed vs. Possible {Interfaces,ChannelClasses}:
• Why would you ever care about anything other than the union?
• Should we distinguish between channel classes that every contact will
   have, channel classes that some contacts may have, and channel
   classes that the whole connection might not even have when you sign
   in?
   · Again, what would the UI do differently in each case?
• Possible route: just have one list for each, we can reintroduce
   Guaranteed later if needed.

Agreed that presets such as settings for well-known SIP providers,
Google Talk, Ovi etc. don't live here; they should live outside the CM,
so that you can install extra files to describe (e.g.) your company's
SIP or XMPP service.

VCardField:
   · as a first step, if you have a vCard and it's got an x-jabber field
     and you want to know how you can contact this person, you can just
     go through your protocols and find them.
   · this is stolen directly from MC's profiles as used on Maemo 5, and
     is valuable there.
   · this is not for getting a contact out of a protocol and turning it
     into a vCard field, because a protocol might support several.
     Example: SIP supports tel and sip. this use case is further work.
   · nitpick, explain what "telephony" means, exactly: it's Ye Olde POTS,
     not IP Telephony.

DisplayName:
   · This is a really overloaded name; can we call it EnglishName?

Icon:
   · "system's icon theme" is a bit of a cop-out. can we say xdg icon
     spec names?

Protocol.Interface.Presence:
   · Maybe guaranteed vs. possible makes sense here?
   · Counter-argument: what's the UI meant to do if you say "you might
     be able to be invisible? i don't really know?"
   · Will reckons we should just make Gabble support invisible
     everywhere which removes the one case where possible ≠ guaranteed

Sidecars we'll ignore for now; the rest seems fine.

== Setting a not supported presence state to a Telepathy ==
== account does not deliver any failing feedback.        ==

<http://bugs.freedesktop.org/show_bug.cgi?id=26752>

Simon wants a RequestPresence(...) method, which:
• Sets RequestedPresence accordingly;
• Waits while the account signs in;
• Ultimately returns one of:
   · success,
   · i had to fall back to this other presence, or
   · bzzt, network error.

Here's a possible use case:

  · Foo is a presence tray icon
  · Bar is a demo application that just tries to sign in an account as
    'dnd'
  · Bar tells my account to sign in as 'dnd'; Foo starts blinking
    because RequestedPresence changed from 'offline' to 'dnd'
  · The account signs in, as 'available' because the protocol doesn't
    actually support 'dnd'.

When should Foo stop blinking? Answer: when the ActualPresence changes.
Transitions of RequestedPresence away from values other than 'offline'
shouldn't make the tray icon blink: apart from when you're signing in,
presence indicators should display ActualPresence.

We think that the use case in the bug would be solved by the
RequestedPresence() method described above.

== Anonymity ==

<http://bugs.freedesktop.org/show_bug.cgi?id=24909>

Connection interface:

• SupportedAnonymityModes should be documented to only be stable once
   you've connected. Should x-ref the type.

• Should SetAM just be a writeable D-Bus property? Maybe not if it
   involves talking to the sky on GSM. But it needs to be a writeable
   D-Bus so that it can be a connection parameter which is also a D-Bus
   property using the DBus_Property Conn_Mgr_Param_Flag, allowing Mission
   Control to update it on the fly when you change the corresponding
   Account's parameters.

• Will wonders if this interface might be overly tinfoil hatty and
   support features no-one will ever use, and maybe we should just have a
   HideCallerID: b property?
   · Others think that supporting these other flags is fine, but we
     should order the flags by how obscure they are, so that the one you
     actually care about — OriginatorInfo, aka caller-id — is first, and
     then the introduction can say "If you just care about hiding your
     caller ID, call Set("Flags", 1)".

• Capitalization is wrong. smcv or similar needs to do an editorial
   pass-through.

Channel interface:

• Properties don't need to be Initial*, they're immutable. Should be
   AnonymityModes, AnonymityMandatory
• Should say that those two are requestable.
• AnonymizedDisplayName: this isn't a display name, it's an Identifier.
   Say that it's not requestable.

== Mute ==

<http://bugs.freedesktop.org/show_bug.cgi?id=26807>

Do we need to tell Farsight to mute things, or just leave it up to the
UI? AP: speak to Olivier about this. (Also, can we make Hold easier in
Call?)

Do we want to relay the fact that we've muted our mic to the other
parties? We don't see any harm in it: it's useful metadata, and isn't an
information leak because you can hear that someone's gone silent anyway.

If we make the UI control the actual muting (or in the Maemo case, make
it talk to s-e directly) then it could control whether not to tell the
other guy by whether or not it call Mute() on the CM. But for GSM it
needs to call Mute() on the CM because that's the thing which cares. So
two semantics here: one informational, one a request.

== Cellular ==

<http://bugs.freedesktop.org/show_bug.cgi?id=24910>

This looks fine, we should ship it.

Regards,
-- 
Will