Google Hangouts and XMPP messages

[Simon Tennant]

In case you missed it, GTalk used to rely on XMPP and <message> stanzas. Google has switched to their own custom designed and unfederated protocol. In case you missed it, Hangout are really nice.

I've been long thinking and dreading how we build user-to-user messages into buddycloud. Using XMPP for federation buys us messaging for free if we use the <message> stanza. Using <message> also buys us a world of pain that need to be worked around:

• no guarantee of delivery
  
• no reliable way to share files between different clients (or to know if it will work before trying)
  
• no shared history across clients
  
• no way to reliably message an offline contact
• no easy way to turn a 2 person conversation into multiparty

MAM seeks to address parts of this. And other bits seek to work around other problems. The reality is that some of these bits will be implemented on some servers, some on other servers, and there's still no guaranteed 'it just works'.

This is why I fear working on messaging in buddycloud: building chat is opening a can of worms and and we enter a world of pain, that we'll never be able to have working reliably across all sites deploying buddycloud. And then the buddycloud client will look bad.

We'll never be able to deliver the seamless sending of messages that one sees in Skype or WhatsApp: fire and forget sending, sharing of media and a consistent user experience. I am wondering if this was also Google's thinking?

Google sets a high bar with Hangouts: they have a beautiful UI, they just work, they permit users dropping into and leaving conversations, and... are closed and unfederated.

At buddycloud we build solutions:

Ingredients:

• We have an awesome way to synchronise posts, media and followers. And it federates.
• We currently have two channel types: personal (about you), topics (about things that interest you).
• We were to add a third channel type called ephemeral channels

Ephemeral channels:

• are buddycloud channels with different application logic: destroyed by the buddycloud-server when the last follower unfollows them.
• everyone is a follower+post
• are automatically created when you use a buddycloud client to chat with another user.
• look like <UUID>@ephemeral.example.com (but never displayed that way to the client)
  
• media posting works just as before and shared media is only visible by ephemeral channel followers
• message history works
• shared history between clients works
• easy way to add more follower+post to an ephemeral channel
• can hook into the push notification service

Displaying Ephemeral channels on a client:

• The client tries to match two person ephemeral channels with the other persons channel (now you can view their channel AND "chat" with them)
• when followers >2 are displayed in a client as "chat with us...@example.com and ... and ... "

Ephemeral channels will only work in clients that support buddycloud (no Pidgin, no Adium). 

I think we're more likely to have success at producing working chat this way rather than building on XMPP's native chat.

Haters gonna hate. Still, I'd love your criticism today.

S.

--
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP

[Andreas Kuckartz]

I am not sure I understand all of this ;-)

"Ephemeral channels" use XMPP, correct? Could that feature be specified
as an XEP ?

Cheers,
Andreas
---

Simon Tennant:

> In case you missed it, GTalk used to rely on XMPP and <message> stanzas.
> Google has switched to their own custom designed and unfederated protocol.
> In case you missed it, Hangout are really nice.
>
> I've been long thinking and dreading how we build user-to-user messages
> into buddycloud. Using XMPP for federation buys us messaging for free if we
> use the <message> stanza. Using <message> also buys us a world of pain that
> need to be worked around:
>

> - no guarantee of delivery
> - no reliable way to share files between different clients (or to know

> if it will work before trying)

> - no shared history across clients
> - no way to reliably message an offline contact
> - no easy way to turn a 2 person conversation into multiparty

>
> MAM seeks to address parts of this. And other bits seek to work around
> other problems. The reality is that some of these bits will be implemented
> on some servers, some on other servers, and there's still no guaranteed 'it
> just works'.
>
> This is why I fear working on messaging in buddycloud: building chat is
> opening a can of worms and and we enter a world of pain, that we'll never
> be able to have working reliably across all sites deploying buddycloud. And
> then the buddycloud client will look bad.
>
> We'll never be able to deliver the seamless sending of messages that one
> sees in Skype or WhatsApp: fire and forget sending, sharing of media and
> a consistent user experience. I am wondering if this was also Google's
> thinking?
>
> Google sets a high bar with Hangouts: they have a beautiful UI, they just
> work, they permit users dropping into and leaving conversations, and... are
> closed and unfederated.
>
> At buddycloud we build solutions:
>
> Ingredients:
>

> - We have an awesome way to synchronise posts, media and followers. And
> it federates.
> - We currently have two channel types: personal (about you), topics

> (about things that interest you).

> - We were to add a third channel type called *ephemeral channels*
>
> Ephemeral channels:
>
> - are buddycloud channels with different application logic: destroyed by

> the buddycloud-server when the last follower unfollows them.

> - everyone is a follower+post
> - are automatically created when you use a buddycloud client to chat
> with another user.
> - look like <UUID>@ephemeral.example.com (but never displayed that way
> to the client)
> - media posting works just as before and shared media is only visible by
> ephemeral channel followers
> - message history works
> - shared history between clients works
> - easy way to add more follower+post to an ephemeral channel
> - can hook into the push notification service

>
> Displaying Ephemeral channels on a client:
>

> - The client tries to match two person ephemeral channels with the other

> persons channel (now you can view their channel AND "chat" with them)

> - when followers >2 are displayed in a client as "chat with

[Ashley Ward]

On 21 May 2013, at 15:34, Simon Tennant <si...@buddycloud.com> wrote:
>
> Haters gonna hate. Still, I'd love your criticism today.

Makes sense to me. You're essentially using pubsub as a multi user chat, which seems perfectly plausible to me. As you say, we then get all the advanced functionality of channels virtually for free.

--
Ash

[Thomas Jost]

> Ephemeral channels:
>
> - are buddycloud channels with different application logic: destroyed by

> the buddycloud-server when the last follower unfollows them.

> - everyone is a follower+post

> - are automatically created when you use a buddycloud client to chat
> with another user.
> - look like <UUID>@ephemeral.example.com (but never displayed that way
> to the client)

Good ideas! And this would feel quite natural in PubSub-land.

> - media posting works just as before and shared media is only visible by
> ephemeral channel followers

What happens to the uploaded media when such a channel is deleted?
(and same question for regular channels btw...)

Cheers,
--
Thomas/Schnouki

[Peter Saint-Andre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just a quick note:

One thing I like about pubsub here (or MUC, which is just a debased
form of pubsub) is that there's no distinction between 1-to-1 and
multiparty.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRm6mAAAoJEOoGpJErxa2pOooQAJ4xx7roliBF7Pcl5zppM0SK
tYW9n7IOW+LbnjCiO5VlaNLBVxuI5I4z3EI3ZXKNrx61fNEQqpCzmA8KvmfmxZJY
9FDMkjwm8kRVcX559Np41XvBTIGwLNJWZicumVejl4zilwGj/0X7c1HfGC2g7xpm
vsck+miD4BBSaNBEGNrt5VqaGdwZi/xpsQF9FxS9Hcma/YpXXhuYzP/yF5S2rXbP
DhUQbO6ATpFX5a1EAo+jFgijaiWJ7PN3RattaNp/tHHZQyIZLJMDE9OookxS9ibO
yejpEEPMkxTpbOnBSL4YlcHE1DLBirMMU7hRQhb8lylGHI0CE27p97QcfsMRaxff
WhS1OB2bu9TcXQb+4ufDr9faKbAoO/9gWrwJbfAE1dmXFq/fi2D7kfbU8BD4heGz
1ssKSn3zUrKmMTbwAPlIwP3chJ3j6EHITCJ/GByJBPNUf0VskzzIAPr5e1UhIxCt
ghxsbjv/gOluOZdwMMHEaXxdz+ZsNqEv+NqkGAivVIbyuarVU0TGcJuRaUYp+mTY
ODFSo37BkZ3g1/+jaBJbERVQdfoRpSLUbyFsZeW+J4zTqDjX7qTsXxkbiUeYLdQe
v/quV3x36XHklCbhUgnAiJZh42Mdcyyo9YiHZasLeZtFBv62Pe98VFjYFcNvSIx0
f4OrjkLndm+Fb0IyVOon
=UAA8
-----END PGP SIGNATURE-----

[Simon Tennant]

@peter: indeed. (You know how I feel about MUC - the wannabe pubsub node)

@Thomas: I think this is a UX challenge - make the user aware that deleting / leaving a channel will remove x posts and y media objects.

Let's see how we get on this week - it might be fun to pull together a quick "hangouts-lite" client using Rodrigo's evolving buddycloud.js

[Ashley Ward]

On 21 May 2013, at 18:41, Simon Tennant <si...@buddycloud.com> wrote:

> @Thomas: I think this is a UX challenge - make the user aware that deleting / leaving a channel will remove x posts and y media objects.

Just a thought, but does the channel actually need to be deleted? The channel could remain, with the contents intact, until the user chooses to delete their history, or maybe have a configurable archival period. So rather than it being an "ephemeral" channel, it's actually just some kind of "chat" type channel, specific to a chat between a set of entities. A different set of entities would start a new channel, whereas a future chat between the same entities would reuse the existing channel.

For example: in Facebook chat the message history is persistent, and this is actually pretty useful at times.

I suppose the only issue may be in who (and more importantly which server) owns the channel.

--
Ash

[Abmar Barros]

I suppose the only issue may be in who (and more importantly which server) owns the channel.

+1

--
Abmar Barros
MSc in Computer Science from the Federal University of Campina Grande - www.ufcg.edu.br
OurGrid Team Leader - www.ourgrid.org

Buddycloud Dev - www.buddycloud.org
Paraíba - Brazil

[Simon Tennant]

@ash - good point about persistent history. Super useful. Right now one "archives" a hangout. I would expect us to have something similar. Let's make that action a v2 feature that could happen server-side or client-side.

What about the creator's bc-server hosting the channel? What happens when the ephemeral channel's home server goes down? My hunch is that that we can also ignore this vor a v1.0 and spin up a new ephemeral channel if necessary.

@andreas: all power to them building traditional chat. Let's keep buddycloud's name associated with reliability and just-works. I'm not convinced that anyone can provide that level of reliability across different XMPP servers.

Regarding libraries for Jitsi et al: Rodrigo is working on buddycloud.js, I expect that we can develop libraries for other languages when necessary. Probably more of a UX issue for Jitsi than a technology issue.

S.

--
You received this message because you are subscribed to the Google Groups "buddycloud-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to buddycloud-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andreas Kuckartz]

Simon Tennant:

> @andreas: all power to them building traditional chat. Let's keep
> buddycloud's name associated with reliability and just-works. I'm not
> convinced that anyone can provide that level of reliability across
> different XMPP servers.

So "just-works" for the use case "traditional chatting" simply means:
does not work work at all. That certainly is one way to manage the
problem. I do not really like it but I will not commit to solve it in
another way.

> Regarding libraries for Jitsi et al: Rodrigo is working on buddycloud.js, I
> expect that we can develop libraries for other languages when necessary.

Great.

Cheers,
Andreas