On 12 August 2015 at 10:54, Dave Cridland <[email protected]> wrote: > > > On 12 August 2015 at 09:01, Georg Lukas <[email protected]> wrote: > >> * Steve Kille <[email protected]> [2015-08-12 08:14]: >> > Given that a MAM based approach may be the preferred medium term >> > approach, it seems to me that we should focus efforts to work out what >> > the medium term approach is going to be. >> >> +1 >> >> > Also, if there is a list of issues that some people view need fixing >> > with carbons, I think it would be good to have that list explicitly >> >> I've tried to compile a more general list of issues some time ago, to >> be found here: >> >> http://mail.jabber.org/pipermail/standards/2015-April/029722.html >> >> > Thanks, this is well worth [re-]reading, as it's a good summary of > multidevice issues. > > >> The carbon relevant things from that list and from the last 0280 advance >> discussion are: >> >> * Carbons for non-"chat" messages. Jingle signalling of incoming calls >> to all interested clients was mentioned IIRC. >> >> > That use-case won't work anyway because Jingle calls are initiated with an > <iq/>. >
That sounds more abrupt than I intended. Matthew Wild suggested just adding 'normal', back in April; that would cover most use-cases, and 'headline' messages seem to be undesirable at this stage. > > >> * No filtering mechanism. Carbons are only for type="chat", the client >> can't add / remove types according to its needs. >> >> > True; do we need this in order to deploy Carbons, though? I suspect we > ultimately do to cover non-IM scenarios, but for normal IM we can probably > handle just type='chat'. > > >> * "False-positive" Carbons of MUC private messages (which are of >> type="chat"; see >> http://mail.jabber.org/pipermail/standards/2015-May/029819.html and >> following messages for a discussion and possible solutions). I think >> the solutions need to be codified in the XEP. >> >> > I think there's a number of cases where a user's server needs to know that > a remote entity is a MUC (and thankfully, with MUC, this is relatively > simple to achieve). FWIW, the same issue also affects PEP (where PEP > doesn't use headline, at least), but is rather simpler to solve on a > stanza-by-stanza basis. > > For MUC, I'll summarize our conversation online as servers already have to > track directed presence to chatrooms; it should be relatively low-cost to > check responses and mark those as chatrooms as needed, and then perform a > lookup for Carbons purposes. > > I think I can patch Openfire to do this, and I believe you suggested > Prosody may do something like this already (but I may have misunderstood). > > >> * Carbon notifications (not strictly an XEP issue, rather one of proper >> UX) - when should a client ring a bell? Recommendations for this case >> might or might not be appropriate in the XEP. >> > > I made the comment on HN that, as a community, we tend not to try to get a > consistent UX, and that perhaps we should, and explaining when to notify > (and how) would be a great start - maybe we should kick that off with a > Wiki page and see where it goes? > > >> >> >> Georg >> -- >> || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ >> || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || >> || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || >> ++ IRCnet OFTC OPN ||_________________________________________________|| >> > >
