https://logs.xmpp.org/council/2021-03-31?p=h#2021-03-31-73bb35836fe3ee0d
1) Roll Call Present: Jonas, Zash, Daniel, Georg Definitely not attending non-existent secret society meetings: Dave 2) Agenda Bashing None. 3) Editor's Update * Published Content Rating Labels as XEP-0456 4) Deprecate XEP-0013 (Flexible Offline Message Retrieval) - https://xmpp.org/extensions/xep-0013.html Last week Sam requested this be Deprecated due to significant overlap with XEP-0313 (Message Archive Management). Georg never liked the XEP-0013 workaround for the MAM use case, but there are no recommended alternatives. Zash suddenly notices that XEP-0136 (Message Archiving) was deprecated. Daniel believes there are actually very few implementations using message purging, though there isn't a mechanism to replace it; but is still in favour of deprecating. Kev notes that XEP-0386 (Bind 2.0) does provide such a replacement. Georg believes 0013 can be deprecated, and there doesn't appear to be a great need to replace it. Daniel doesn't think the existence of a replacement is a strict requirement for deprecation. Zash thinks the underlying problem might be that interaction between XEP-0013 and XEP-0313 is unspecified. Georg wonders whether it would be possible to create something better than 0013, but not as extensive as XEP-0386. Jonas suggests an option might be to insert the message purging part from 0013 into 0313, and then deprecate 0013. Georg suggests an alternative could be that a client using MAM on connect would have its offline message history dropped. Sam thinks it would be fine to go straight ahead with deprecation, since it shouldn't break anything, and doing so may even encourage efforts towards producing a replacement. Daniel thinks moving the purge protocol into 0313 sounds like a good intermediate solution - Georg is concerned by the many race conditions in MAM, without adding 'delete all history now' to the pile - Daniel doesn't find MAM to be so terrible, even when combined with dropping history - Georg notes that everything works only if the correct rituals are performed in exactly the correct order (and the ordering is undocumented, naturally.) Daniel checks for some agreement that a non-Bind2 alternative to offline message history purging is a wanted feature, and whether the MAM authors would be okay with adding that before 0013 is deprecated - Georg is ambivalent regarding that feature. Zash questions whether it needs to go into 0313, as it would no longer be needed once offline messages are no longer in use. Kev would also prefer not to add this temporarily into 0313, unless there is no intention to advance 0313; it should be put into a new XEP until Bind2 is solved. Georg suggests "do not deliver offline messages to a MAM client" and "expire old messages from offline history if full instead of rejecting new ones" as additions to 0313. Kev believes that users are unlikely to care which clients have received which messages, and so doesn't see a need for per-client offline message storage - Georg thinks users still want to see all messages on all clients, not whichever random subset happens to remain. Georg believes there would be great benefit to improving the perceived reliability of XMPP for legacy clients, such as Pidgin, at a very low cost. Jonas sees that there are arguments about how MAM catch-up might be improved, but those are only tangentially related to whether 0013 should be deprecated. Kev questions what the proposal is, other than using Bind2 (or something similar) to inform the server that you're a MAM capable client and not to send offline messages - Georg's proposal was simply not to send offline messages to any MAM capable client (using MAM already indicates MAM capability.) Zash: +1 Georg: +1 Daniel: +1 Jonas: +1 Dave: [pending] Jonas directs further matters in this enthralling discussion towards the still active XEP-0313 Last Call thread [1], or into a separate discussion for Bind2 design. 5) Pending Votes None. 6) Date of Next 2021-04-07 1500 UTC 7) AOB Jonas queries the possibility of moving Council meetings into the XSF MUC, given that many discussions start in here and should really be carried over into there. Zash isn't opposed - it always seemed weird for Board to hold their meetings there, but not Council; Kev sees no reason to do it, and possible reasons not to. Jonas thinks it might encourage more non-Council input, though also more noise. Georg thought the Council meeting was moved away from the XSF MUC precisely to separate it from the additional noise. Kev thinks the significant advantage to leaving it in here is filtering, as the XSF MUC is quite noisy and can safely be ignored most of the time, while anything happening in here is expected to be more worthwhile. Daniel isn't a fan of Board meetings being held in the XSF MUC, and would prefer Council meetings aren't held there either - if only not to interrupt others' ongoing discussions. Georg also has a weak preference for staying here. Zash adds that it is much easier to give this MUC a higher notification priority than working out some time-based rules for the XSF MUC. Jonas concludes to stay put. Kev believes there would have been value in Council providing guidance on what to do in place of 0013 message purging - Jonas suggests that using MAM is sufficient; Zash imagines the server might take note of MAM usage before initial presence and adjust things accordingly. Kev doesn't believe that usage of MAM alone solves the issue of receiving offline messages duplicated from history - Georg suggests that the server can omit offline history when a client queries MAM or MAM preferences; Jonas would still direct people to implement the message purging part, even with 0013 deprecated (in the same way that some parts of RFC 3920, which is deprecated, are still needed on some servers.) Kev is unsure how the server would determine a client is MAM-capable before sending the offline messages, without adding roundtrips - Zash presumes a MAM-capable client would request MAM preferences first; Georg adds that the client would need to request the last stored MAM ID before initial presence, to avoid a race condition. Zash explains that Prosody already takes note of when the client does anything MAM-related, and that logic could be extended to stop offline message broadcasts. Zash volunteers to write a new XEP on "How to deal with offline messages in the presence of MAM", if only so Georg has somewhere to document his favourite race conditions. Kev checks that the suggested fix is to send an empty MAM query before initial presence - Georg admits that it's not a fix, rather a pragmatic solution. Kev thinks a new XEP is needed to explain "if a client requests MAM prior to offline messages being sent, dump the offline store. As a client, request MAM before initial presence" - Zash thinks it could be titled something like "How to deal with offline messages in the presence of MAM"; Daniel thinks it's either that or a conditional purge. Georg queries whether Kev's implementation doesn't already send a MAM query prior to initial presence - Kev says it only requests MAM when a chat is opened, to add some chat history; Zash expects offline messages would be desirable in this case. Kev ultimately wants to use Bind2 (with benefits), so a full sync can be avoided and XEP-0430 (Inbox) style current-state sync can be used. Jonas appreciates the discussion and sees value in providing guidance, but views using message purging from XEP-0013 as the trivial solution; anything more complex can be discussed elsewhere - Sam will start a thread [2]. 8) Close Thanks Tedd, Kev, everyone, and all. Georg is replying to the XEP-0313 Last Call, but that might not cover all of the relevant points; Kev needs to re-read 0313 before replying; Zash thinks that sounds like a thing he should have done too. [1] https://mail.jabber.org/pipermail/standards/2021-March/038252.html [2] https://mail.jabber.org/pipermail/standards/2021-March/038275.html
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
