Hi,
As Daniel wrote, MUST is probably to strong here, it is enough to
mention that it can lead to problems if you dont discard such messages.
If you have a client that always shows the user if a decryption fails,
this also means you need a client that has absolute perfect
deduplication in any
I agree that for “catch-up”, it’s not particularly useful, but knowing exactly
what messages you’ve seen is.
Makes sense if we see the Archive as Store of all messages we have seen.
I often forget thats that the original idea, because of OMEMO PFS i does
not serv that purpose.
Also if we
is and what would client
developers want?
i also found this out the hard way, thats why i drop all messages
type=groupchat immediatly on a user archiv query.
i dont see a use for this.
___
Standards mailing list
Info:
Hi,
I see no downside with your proposal, but the upsides are not as plenty
as you described.
1. every client gets notified already if a update to the device list is
made, otherwise OMEMO would not work half of the time
2. there is no code that is added *only* to prevent the race
for every contact in roster, and perform some SQL magic on query.
it would send you a list of contacts and afterwards you could start
querying the archive for messages of these contacts.
Am 02.12.2016 um 17:14 schrieb Kevin Smith:
On 2 Dec 2016, at 16:03, forenjunkie <forenjun...@chello
XEP, you can filter with various attributes, you dont have to step
through EVERY message.
Am 02.12.2016 um 16:57 schrieb Kevin Smith:
On 2 Dec 2016, at 15:49, forenjunkie <forenjun...@chello.at> wrote:
Its not written down somewhere that its up to the client, but it makes no sense
to pu
, then you know everything that comes before that was
already read so i dont have to query it.
Am 02.12.2016 um 16:34 schrieb Kevin Smith:
On 2 Dec 2016, at 15:26, forenjunkie <forenjun...@chello.at> wrote:
in a single chat conversation, it makes no sense to query unread messages
Hi,
in a single chat conversation, it makes no sense to query unread messages.
you could just query the last 10 MAM Messages, if no readmarker comes
with it, query another 10. such a implementation of MAM would be very
weird to me, but you could do it and get only unread messages with it.
So
But it doesnt work with a decentral, open source kind of system.
a feature like that depends on the other side deleting the message.
you are lying to your users the minute you offer this feature in your
client and not show a disclaimer.
you promise the message will self destruct, but you can
