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 < [email protected]>: > 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: [email protected] > skype: twitter/github/medium: michalwski > > > > On Mon, 11 May 2020 at 10:22, Michal Piotrowski < > [email protected]> 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: [email protected] >> skype: twitter/github/medium: michalwski >> >> >> >> On Wed, 22 Apr 2020 at 13:17, Florian Schmaus <[email protected]> wrote: >> >>> On 4/22/20 12:07 PM, Matthew Wild wrote: >>> > On Tue, 21 Apr 2020 at 15:50, Florian Schmaus <[email protected] >>> > <mailto:[email protected]>> 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: [email protected] >>> _______________________________________________ >>> >> > 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: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
