[Standards] Feedback: XEPs 280 and 313... and the "what is what" issue.

[Marco Cirillo]

Having implemented Carbons recently, I sort of incurred in this "what is what" issue which mainly regarded MUC Private Messages.

1) Some Implementations show the message as coming from the MUC itself




In my opinion the sanest approach would be addressing at protocol level:





--

*Marco Cirillo*
/LW.Org/LW.Org IM Owner & Head Developer/
/Metronome IM Project Mantainer/Developer/
/Jappix Mantainer/Developer/
http://lightwitch.org

MAM wise it's more narrow and less problematic as preferences and query parameters allow to better filter both what you log and what you can retrieve, but it poses a problem for clients (as discussed today in the Gajim room) when you want to synchronize the local historic with the remote one. For Carbons although it gets really ugly, because when a resource which is in a muc receives a PM it'll be delivered to all enabled resources, which normally shouldn't be a problem if it weren't that: 2) Non-Carbons enabled clients which support OTR, don't do any type of flagging (<private /> or Message Processing Hints) of the messages and perhaps they'll be blindly forwarded. 3) Causes an issue with Merged Nicknames (minor and implementation dependent but it's there). About the possible solutions, I know there has been some talking but none is flawless... After some discussions on the argument I think I came to the conclusion that the most (for now) reliable, but in my opinion insane, way is having the client send a service discovery to the bare jid to assert if the entity is a muc... However, since it ties the client to the responsivity and availability of the remote entity it's not exactly stellar. 1) Adding a new type to message stanzas, this is my favourite since would remove most of the complexity both ways... but unluckily it'll pose a lot of issues with interoperability and backdraw compatibility federation wise. 2) Flagging messages using XEP-334, this is very good as well and in theory should require minimal server intervention and would deal well with interoperability and compatibility but then it would require wide implementing client wise. I know there's no easy recipe to deal with this, but I really feel "tossing discos like freesbees" isn't proper and if not point one just above at least pushing for XEP-334 advancement and implementation (and obviously a change in the MUC XEP to use 'em for the above case..) could help with a more widespread adoption and advancement of both Carbons and MAM.

smime.p7s
Description: Firma crittografica S/MIME