> …this is the line of thought that neglects that we are working on a
> federated system where we can not assume that every actor is faithful.
> ID assigned by the sending entity can potentially be observed by another
> malicious actor and be reproduced ("spoofed").
There is nothing stopping me fr
On Wed, 2023-02-22 at 19:02 +0100, Florian Schmaus wrote:
> That is where we already think different. The more archives messages
> are
> contained in, the higher the chances are that they are preserved and
> recoverable. Which is usually a good thing.
The ground truth for messages received by th
On 22/02/2023 18.00, Tedd Sterr wrote:
But, being serious: the issue is that both clients and servers need an
id for referring to stanzas, and if that id is dependably unique then it
solves a number of difficulties; the reason we have problems is that the
original RFC-defined 'id' attribute had
On 22/02/2023 14.14, Marvin W wrote:
Hi Flow,
Hi Marvin,
As it stands today, every message ideally has no more than two IDs:
That is where we already think different. The more archives messages are
contained in, the higher the chances are that they are preserved and
recoverable. Which is
> > There is a very obvious solution to this which everyone seems to be
> > overlooking: we need a new element with a guaranteed unique, non-spoofed
> > UUID; should a server feel the need to do bad things, it can set the
> > 'spoofed' attribute to true and then clients can act accordingly.
> what
> There is a very obvious solution to this which everyone seems to be
> overlooking: we need a new element with a guaranteed unique, non-spoofed
> UUID; should a server feel the need to do bad things, it can set the
> 'spoofed' attribute to true and then clients can act accordingly.
what entity wou
Hi Flow,
As it stands today, every message ideally has no more than two IDs:
- The sender assigned id (origin-id or message's id-attribute) which is
required so that senders can be assured that the message is the one
they sent when they fetch them from the archive or get reflected from
MUCs, recei
There is a very obvious solution to this which everyone seems to be
overlooking: we need a new element with a guaranteed unique, non-spoofed UUID;
should a server feel the need to do bad things, it can set the 'spoofed'
attribute to true and then clients can act accordingly.
Something like:
O
Hi,
I just want to briefly mention that I agree with Marvin here.
The rules in XEP-0461 (Message Replies) and XEP-0444 (Message
Reactions) are good. We don’t need to make the stanza-id XEP more
complicated. We should however outsource the two-three paragraphs on
what ID to use into it’s own XEP.
On 22/02/2023 12.35, Florian Schmaus wrote:
With the current state of affairs, you only need to use origin-id in 1:1
chats.
Foosball tonight?
thumbs-up
I believe the last above should be
thumbs-up
which demonstrates how tricky this is.
- Flow
__
It appears there are two possible design options
A) do not state 'by' when referencing a stanza and provide rules how the
'by' value can be inferred depending on the usage context
B) explicitly state the 'by' attribute and provide rules that allow to
determine if the used 'by' attribute whe
11 matches
Mail list logo
