On 25 apr. 2014, at 13:32, Kim Alvefur <z...@zash.se> wrote: > Hello, > > It has been brought up that my Carbons implementation does not follow > the Receiving Messages to the Bare JID¹ section. This section says > include carbons-enabled sessions in the normal forking of messages as > described by XMPP IM². > > What I implemented was instead to send carbons-wrapped messages to > carbons-enabled sessions that would not already receive them based on > the XMPP IM rules. So a message will always be carbons-wrapped if it > was sent because carbons was enabled. I believe this makes sense, does > anyone else? > > ¹ http://xmpp.org/extensions/xep-0280.html#inbound-bare (version 0.9) > ² http://xmpp.org/rfcs/rfc6121.html#rfc.section.8.5.2.1.1
Hi Kim, Thinking about this a bit more, I actually disagree with this proposal. The semantics of receiving a carbon copy should be "hey this other resource has a conversation going, here's a copy of this message in case you want to follow along". That might imply, for example, that the client uses a different way of notifying the user: the user might have configured their client to not make a sound when receiving a carbon copy, as multiple devices making sounds gets annoying. A bare-JID message is a different situation. Sending one implies the sender is looking for a resource that will reply to start a conversation with it, so for these I think it would be fine if a carbons-enabled client notifies the user as if it were a normal message. Of course the client could add extra logic for this ("if it's a carbon copy, and the first message we've seen from this user this session/hour/day, play sounds"), but I think doing it in the way that is currently in the XEP is a much cleaner solution. Regards, Thijs Alkemade
signature.asc
Description: Message signed with OpenPGP using GPGMail