[Standards] XEP-0313: pending 0.7 update review

Philipp Hörist philipp at hoerist.com
Tue May 12 17:04:01 UTC 2020


Hi,

Yes you use the last known archive-id, this will yield sometimes some
duplicates which you can easily de-duplicate either with the message-id or
origin-id which are known to you.

We all wish there would be a mechanism that told us the stanza-id after we
sent a message but its not planned in this iteration of the XEP.

It's not the most efficient way to do this, but getting a stanza back after
every message you send only to tell you the archive-id is also not very
efficient.

All clients that implement MAM right now seem to be able to deal with the
few duplicates on catchup.

The new filter options are for the use case of fetching holes in your
history, not for catchup.

Regards
Philipp




Am Di., 12. Mai 2020 um 18:45 Uhr schrieb Michal Piotrowski <
michal.piotrowski at erlang-solutions.com>:

> Thanks for the reply Philipp. In that case I didn't understand the purpose
> of the new ways of fetching the archive as proposed by Matthew in
> https://github.com/xsf/xeps/pull/922 namly "before-id", "after-id", and
> "ids". I assumed that they operate not on the archive id provided by MAM
> but on the origin-id (or other id) provided by the user.
>
> If they operate on the archive id provided by MAM, I think we are still
> missing a simple way for the sender to sync the archive. The user sending
> the message, doesn't know the archive id of the just sent message unless it
> tries to read it from MAM. I can imagine a situation where a user sent many
> messages to someone else, there was no message back from the other user
> when the sender was online. The next time our sender connects and wants to
> sync MAM it has to either query it by timestamp or use last known archive
> id, which is from before the messages were sent.
>
> In other words, I think it'd be good if the sender could quickly learn
> what is the archive id for the message it just sent, or has the ability to
> query the archive based on origin-id.
>
> Best regards
> Michal Piotrowski
> Software Architect at https://www.erlang-solutions.com/
> email: michal.piotrowski at erlang-solutions.com
> skype: twitter/github/medium: michalwski
>
>
>
> On Tue, 12 May 2020 at 18:05, Philipp Hörist <philipp at hoerist.com> wrote:
>
>> Hi,
>>
>> I think you misunderstand the XEP, MAM does not care about what IDs a
>> user adds, it certainly does not care about origin-id, or the message-id.
>>
>> The server itself generates a unique ID when receiving a message and this
>> ID is communicated via the stanza-id element for example in MUC Messages.
>>
>> Or if you fetch messages via MAM, in the result element id attribute.
>>
>> Regards
>> Philipp
>>
>> Am Di., 12. Mai 2020 um 17:44 Uhr schrieb Michal Piotrowski <
>> michal.piotrowski at erlang-solutions.com>:
>>
>>> One more question, probably more general. What would be the most desired
>>> server's behaviour when it observes that a user sent a message with a used
>>> UID? In my opinion, it be better to reject this new message with an
>>> existing UID, if so how to communicate that error back to the sender?
>>>
>>> Best regards
>>> Michal Piotrowski
>>> Software Architect at https://www.erlang-solutions.com/
>>> email: michal.piotrowski at erlang-solutions.com
>>> skype: twitter/github/medium: michalwski
>>>
>>>
>>>
>>> On Mon, 11 May 2020 at 10:22, Michal Piotrowski <
>>> michal.piotrowski at erlang-solutions.com> wrote:
>>>
>>>> Hi Matthew,
>>>>
>>>> Thanks for making the changes. I'm really in favour of them. I see
>>>> there was no update to the PRs nor here on the mailing list. What needs to
>>>> happen in order to proceed with these?
>>>>
>>>> Alos, I have a comment (or rather question) regarding the new way of
>>>> querying the archive based on message UIDs. I assume that by UID, you mean
>>>> the origin-id as set by the client sending the message. If so, it didn't
>>>> find it clearly stated in your proposed changes nor in the current
>>>> version of MAM XEP. If not origin-id is meant here, I'd like to know what
>>>> UID means in this context.
>>>>
>>>> Best regards
>>>> Michal Piotrowski
>>>> Software Architect at https://www.erlang-solutions.com/
>>>> email: michal.piotrowski at erlang-solutions.com
>>>> skype: twitter/github/medium: michalwski
>>>>
>>>>
>>>>
>>>> On Wed, 22 Apr 2020 at 13:17, Florian Schmaus <flo at geekplace.eu> wrote:
>>>>
>>>>> On 4/22/20 12:07 PM, Matthew Wild wrote:
>>>>> > On Tue, 21 Apr 2020 at 15:50, Florian Schmaus <flo at geekplace.eu
>>>>> > <mailto:flo at geekplace.eu>> wrote:
>>>>> >     On 4/21/20 2:32 PM, Dave Cridland wrote:> On Mon, 20 Apr 2020 at
>>>>> 16:20,
>>>>> >     > You're going to hate me, but one more thing...
>>>>> >     >
>>>>> >     > Current MAM says that servers SHOULD include a count. The
>>>>> problem with
>>>>> >     > this is that it's extremely slow on any system with more than
>>>>> trivial
>>>>> >     > retention periods, since this tends to degenerate into either a
>>>>> >     COUNT(*)
>>>>> >     > SQL query (table-scan-tastic) or a standalone counter (which
>>>>> then
>>>>> >     drifts
>>>>> >     > and is a contention point).
>>>>> >     >
>>>>> >     > The majority of client libraries appear to ignore the count
>>>>> values
>>>>> >     > anyway, as far as I can tell, so can we relax this to a MAY?
>>>>> (XEP-0059
>>>>> >     > is MAY-but-only-if, which is arguably really a SHOULD anyway).
>>>>> >
>>>>> >     I think such a relaxation would require a namespace bump.
>>>>> >
>>>>> > I'm not convinced. In any case, servers that already comply with the
>>>>> > SHOULD will probably continue to do so, new servers may be more
>>>>> likely
>>>>> > not to, but given that clients don't really use the (unreliable) info
>>>>> > today then I don't think we lose anything in practice.
>>>>>
>>>>> I could follow that argumentation in this case. It's probably just me,
>>>>> but I am very conservative when it comes to relaxations of keywords.
>>>>>
>>>>> - Florian
>>>>>
>>>>> _______________________________________________
>>>>> Standards mailing list
>>>>> Info: https://mail.jabber.org/mailman/listinfo/standards
>>>>> Unsubscribe: Standards-unsubscribe at xmpp.org
>>>>> _______________________________________________
>>>>>
>>>>
>>> Code Sync & Erlang Solutions Conferences
>>> <https://www2.codesync.global/l/23452/2019-11-13/6sypwx>
>>>
>>>
>>> Code BEAM Lite ITA - Bologna: Rescheduled
>>>
>>> Code BEAM STO - Stockholm: Rescheduled
>>>
>>> ElixirConf EU - Warsaw: 7-8 October 2020
>>>
>>> Code Mesh - London: 5-6 November 2020
>>>
>>>
>>> Erlang Solutions cares about your data and privacy; please find all
>>> details about the basis for communicating with you and the way we process
>>> your data in our Privacy Policy
>>> <https://www.erlang-solutions.com/privacy-policy.html>. You can update
>>> your email preferences or opt-out from receiving Marketing emails here
>>> <https://www2.erlang-solutions.com/email-preference?epc_hash=JtO6C7Q2rJwCdZxBx3Ad8jI2D4TJum7XcUWcgfjZ8YY>
>>> .
>>>
>>>
>>> _______________________________________________
>>> Standards mailing list
>>> Info: https://mail.jabber.org/mailman/listinfo/standards
>>> Unsubscribe: Standards-unsubscribe at xmpp.org
>>> _______________________________________________
>>>
>> _______________________________________________
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: Standards-unsubscribe at xmpp.org
>> _______________________________________________
>>
>
> Code Sync & Erlang Solutions Conferences
> <https://www2.codesync.global/l/23452/2019-11-13/6sypwx>
>
>
> Code BEAM Lite ITA - Bologna: Rescheduled
>
> Code BEAM STO - Stockholm: Rescheduled
>
> ElixirConf EU - Warsaw: 7-8 October 2020
>
> Code Mesh - London: 5-6 November 2020
>
>
> Erlang Solutions cares about your data and privacy; please find all
> details about the basis for communicating with you and the way we process
> your data in our Privacy Policy
> <https://www.erlang-solutions.com/privacy-policy.html>. You can update
> your email preferences or opt-out from receiving Marketing emails here
> <https://www2.erlang-solutions.com/email-preference?epc_hash=JtO6C7Q2rJwCdZxBx3Ad8jI2D4TJum7XcUWcgfjZ8YY>
> .
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200512/c95fba24/attachment-0001.html>


More information about the Standards mailing list