Re: [Standards] Proposed XMPP Extension: Message Fastening

[Florian Schmaus]

On 18.12.19 15:05, Marvin W wrote:
> I think the guarantee of uniqueness for (xep359-id, xep359-id-by) is not
> helpful if the xep359-id-by entity cannot be trusted to be xep359
> compliant (= non malicious).

That assessment is correct. That is why, for example, XEP-0359 § 3. 2.
exists.

I can not rule out that we can potentially even further increase the
reliability of the xep359-id-by attribute behind what XEP-0359 already
specifies. But I believe this to be far easier and achievable compared
to, if we do not use the xep359-id-by when referring to messages, coming
up with rules which xep359-id to use depending on the specific situation.

> This is for example the case in public MUCs. In fact in MUCs, there is
> only one xep359-id-by that can/must be trusted, which is the MUC itself.
> Thus for MUCs, the xep359-id-by being the MUC is basically something we
> could imply, because in general, other xep359-id-by can not be trusted>
> […] If they act malicious, then even providing a by attribute
> won't solve anything, as malicious actors can just decide to not follow
> the uniqueness requirement of (xep359-id, xep359-id-by) as well.

As written above, we aim for xep359-id-by being not spoofable. Exactly
to prevent what you described.

> For the very same reason, you don't need a by when requesting messages
> by id from MAM, because the id must always be the one assigned by the
> archive server.

I do think actually that this is not the same reason. It is just
sensible to default the xep359-by-id to the MAM archive's address when
performing MAN queries. Of course, a future MAM query extension could
allow for queries using (xep359-id, xep359-id-by).

> so tl;dr: Usually the by is not required when referencing a message as
> it's value is implicit for the usecase.

I would slightly modify this statement: it is implicit for *some* use cases.

Now let's assume that your XMPP server is so kind and archives all
(message) stanzas in your user archive: including all 1:1 chats, MUC,
MIX and future yet to be invented groupchat protocols, providing you
with the ability to lookup (group)chat messages long after the groupchat
hosting service went offline. If the messages within that archive use
only (xep359-id) and not (xep359-id, xep359-id-by) to reference other
messages in the archive, then you run potentially at least into the
following issues:
- the xep359-id within the archive may not be unique, for various
  reasons:
  - implementation bug
  - malicious entity
  - IIRC ejabberd uses timestamp id xep359-id [1]. An implementation
where the timestamps are in e.g. milliseconds would potentially
generate duplicate xep359-id values (having different xep359-id-by
values)
- it may not be clear which xep359-id-by value implicitly to use for a
  given reference, because the information about the use-case is gone.


- Florian

1: Which appears to be a violation of the xep359 rules, but it is a
different discussion if we may want to change/weaken the "do not leak
information through the xep359-id value" requirements.



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Marvin W]

I think the guarantee of uniqueness for (xep359-id, xep359-id-by) is not 
helpful if the xep359-id-by entity cannot be trusted to be xep359 
compliant (= non malicious).


This is for example the case in public MUCs. In fact in MUCs, there is 
only one xep359-id-by that can/must be trusted, which is the MUC itself. 
Thus for MUCs, the xep359-id-by being the MUC is basically something we 
could imply, because in general, other xep359-id-by can not be trusted.


In direct messages it's not that clear, however it is also obvious that 
the xep359-id-by must be either the sender or the recipient's origin-id 
(the MAM stanza id are different on each server and cannot be seen by 
the other user, so can't be used for anything). If any of the two does 
not follow the recommendation to generate globally unique IDs, not 
providing the by attribute may cause issues. However for this to cause 
issues, it needs one of the two to act malicious, because even if you 
don't guarantee unique ids, collisions are very unlikely if not caused 
intentionally. If they act malicious, then even providing a by attribute 
won't solve anything, as malicious actors can just decide to not follow 
the uniqueness requirement of (xep359-id, xep359-id-by) as well.


For the very same reason, you don't need a by when requesting messages 
by id from MAM, because the id must always be the one assigned by the 
archive server.


The only reason why I could imaging the by attribute to be useful would 
be server-side rewriting (which for example won't work for e2e-encrypted 
messages and also requires indefinite server history): When by is set 
and the id is in the archive, the server could replace the by/id with a 
better suited one (that is known to the intended recipient). This way it 
would possible that clients would be fine with only ever knowing one id 
of a message (the local servers archive id) and all other ids can be 
ignored (or even redacted by the server). However I don't think this is 
something we'd like servers to do (for various reasons and because of 
the problems mentioned).


so tl;dr: Usually the by is not required when referencing a message as 
it's value is implicit for the usecase.



On 12/18/19 11:59 AM, Florian Schmaus wrote:

Oh, the IDs are unique. But only if you concatenate the 'by' value with
the ID. Or, in other words, the tuple (xep359-id, xep359-id-by) is
guaranteed by xep359 to be globally unique.

One reason why xep359 makes this distinction is to prevent ID spoofing.
Consider an archive which contains a message with the xep359-id 'id1'
and another user now refers to this message just using 'id1'. If now an
(malicious) entity would be able to add to the archive another message
with the same xep359-id 'id1', but a different xep359-id-by value, then
it is not clear anymore which message is refereed to.

Hence one should always use the tuple (xep359-id, xep359-id-by) when
referring to stanzas using xep359 IDs. And this is the coordinate system
fastening should use to establish a link to other messages.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Florian Schmaus]

On Wed, Dec 18, 2019, 13:03 Dave Cridland  wrote:

>
> On Wed, 18 Dec 2019 at 11:00, Florian Schmaus  wrote:
>
>> On 12/11/19 6:10 PM, Kevin Smith wrote:
>> >> On 9 Sep 2019, at 20:37, Florian Schmaus  wrote:
>> >> On 9/5/19 7:52 PM, Jonas Schäfer (XSF Editor) wrote:
>> >>> The XMPP Extensions Editor has received a proposal for a new XEP.
>> >>>
>> >>> Title: Message Fastening
>> >>> Abstract:
>> >>> This specification defines a way for payloads on a message to be
>> >>> marked as being logically fastened to a previous message.
>> >>>
>> >>> URL: https://xmpp.org/extensions/inbox/fasten.html
>> >>
>> >> Thank you, Kev for pushing this forward. I think the kind of attention
>> >> this ProtoXEP already has received, shows that the XMPP ecosystem needs
>> >> such a XEP and the community desires one.
>> >>
>> >> I want to suggest one small change to how the attached-to message is
>> >> specified: I always assumed that, if xep359 is used to refer a message,
>> >> the reference would not just be the id-value, but a tuple of id-value
>> >> and the id-assigning-entity address.
>> >> This avoids ambiguity if a  attaches to a stanza which
>> >> multiple  elements. Furthermore, xep359 makes it very clear
>> >> that xep359-IDs are just unique and stable within the scope of the
>> >> id-assigning-entity (this allows implementations to use simple
>> >> mechanisms to generate the ID without considering collisions with other
>> >> id-assigning-entities).
>> >
>> > Good point, thanks Flo. Although I’m not sure that 359 does make it
>> clear that it’s not globally unique
>>
>> The XEP currently states
>>
>> The value of the 'id' attribute must be unique and stable, i.e. it MUST
>> NOT change later for some reason within the scope of the 'by' value.
>> Thus the IDs defined in this extension MUST be unique and stable within
>> the scope of the generating XMPP entity.
>>
>> which tries to express this, but the wording can (and should) probably
>> be improved.
>>
>> , actually the opposite - I believe it’s a SHOULD on using UUID,
>>
>> No, it is just a friendly recommendation to simply use UUIDs, not a
>> SHOULD.
>>
>
> It says RECOMMENDED, which is, according to RFC 2119, the same as SHOULD.
> So the specification already says (more or less) that if you want to do
> anything else, you need to understand why what you're doing is almost
> certainly wrong.
>

My fault, I sometimes forget that those are equal. Sorry about that. In the
XEP it was meant to be just a friendly recommendation that developers could
simply use the UUID library of their platform to generate the xep359 IDs.
It shouldn't have been an all caps RECOMMENDED.


>
>> > and my understanding has always been that these are intended to be
>> globally unique (I realise you have authority on claims of the original
>> intention) from reading it. This isn’t the only XEP that’s written on the
>> basis of the unique IDs being unique :)
>>
>> Oh, the IDs are unique. But only if you concatenate the 'by' value with
>> the ID. Or, in other words, the tuple (xep359-id, xep359-id-by) is
>> guaranteed by xep359 to be globally unique.
>>
>> One reason why xep359 makes this distinction is to prevent ID spoofing.
>> Consider an archive which contains a message with the xep359-id 'id1'
>> and another user now refers to this message just using 'id1'. If now an
>> (malicious) entity would be able to add to the archive another message
>> with the same xep359-id 'id1', but a different xep359-id-by value, then
>> it is not clear anymore which message is refereed to.
>>
>> Hence one should always use the tuple (xep359-id, xep359-id-by) when
>> referring to stanzas using xep359 IDs. And this is the coordinate system
>> fastening should use to establish a link to other messages.
>>
>
> I don't think that existing specifications which refer to XEP-0359 have
> made the distinction. Many have decided only to trust identifiers from a
> particular source, but not that such identifiers are only unique within the
> scope of a particular jid.
>

Which existing specifications are that? I tried to closely monitor xep359
usages, but can't rule out that I missed some.

- Florian
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Dave Cridland]

On Wed, 18 Dec 2019 at 11:00, Florian Schmaus  wrote:

> On 12/11/19 6:10 PM, Kevin Smith wrote:
> >> On 9 Sep 2019, at 20:37, Florian Schmaus  wrote:
> >> On 9/5/19 7:52 PM, Jonas Schäfer (XSF Editor) wrote:
> >>> The XMPP Extensions Editor has received a proposal for a new XEP.
> >>>
> >>> Title: Message Fastening
> >>> Abstract:
> >>> This specification defines a way for payloads on a message to be
> >>> marked as being logically fastened to a previous message.
> >>>
> >>> URL: https://xmpp.org/extensions/inbox/fasten.html
> >>
> >> Thank you, Kev for pushing this forward. I think the kind of attention
> >> this ProtoXEP already has received, shows that the XMPP ecosystem needs
> >> such a XEP and the community desires one.
> >>
> >> I want to suggest one small change to how the attached-to message is
> >> specified: I always assumed that, if xep359 is used to refer a message,
> >> the reference would not just be the id-value, but a tuple of id-value
> >> and the id-assigning-entity address.
> >> This avoids ambiguity if a  attaches to a stanza which
> >> multiple  elements. Furthermore, xep359 makes it very clear
> >> that xep359-IDs are just unique and stable within the scope of the
> >> id-assigning-entity (this allows implementations to use simple
> >> mechanisms to generate the ID without considering collisions with other
> >> id-assigning-entities).
> >
> > Good point, thanks Flo. Although I’m not sure that 359 does make it
> clear that it’s not globally unique
>
> The XEP currently states
>
> The value of the 'id' attribute must be unique and stable, i.e. it MUST
> NOT change later for some reason within the scope of the 'by' value.
> Thus the IDs defined in this extension MUST be unique and stable within
> the scope of the generating XMPP entity.
>
> which tries to express this, but the wording can (and should) probably
> be improved.
>
> , actually the opposite - I believe it’s a SHOULD on using UUID,
>
> No, it is just a friendly recommendation to simply use UUIDs, not a SHOULD.
>

It says RECOMMENDED, which is, according to RFC 2119, the same as SHOULD.
So the specification already says (more or less) that if you want to do
anything else, you need to understand why what you're doing is almost
certainly wrong.


> > and my understanding has always been that these are intended to be
> globally unique (I realise you have authority on claims of the original
> intention) from reading it. This isn’t the only XEP that’s written on the
> basis of the unique IDs being unique :)
>
> Oh, the IDs are unique. But only if you concatenate the 'by' value with
> the ID. Or, in other words, the tuple (xep359-id, xep359-id-by) is
> guaranteed by xep359 to be globally unique.
>
> One reason why xep359 makes this distinction is to prevent ID spoofing.
> Consider an archive which contains a message with the xep359-id 'id1'
> and another user now refers to this message just using 'id1'. If now an
> (malicious) entity would be able to add to the archive another message
> with the same xep359-id 'id1', but a different xep359-id-by value, then
> it is not clear anymore which message is refereed to.
>
> Hence one should always use the tuple (xep359-id, xep359-id-by) when
> referring to stanzas using xep359 IDs. And this is the coordinate system
> fastening should use to establish a link to other messages.
>

I don't think that existing specifications which refer to XEP-0359 have
made the distinction. Many have decided only to trust identifiers from a
particular source, but not that such identifiers are only unique within the
scope of a particular jid.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Florian Schmaus]

On 12/11/19 6:10 PM, Kevin Smith wrote:
>> On 9 Sep 2019, at 20:37, Florian Schmaus  wrote:
>> On 9/5/19 7:52 PM, Jonas Schäfer (XSF Editor) wrote:
>>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>>
>>> Title: Message Fastening
>>> Abstract:
>>> This specification defines a way for payloads on a message to be
>>> marked as being logically fastened to a previous message.
>>>
>>> URL: https://xmpp.org/extensions/inbox/fasten.html
>>
>> Thank you, Kev for pushing this forward. I think the kind of attention
>> this ProtoXEP already has received, shows that the XMPP ecosystem needs
>> such a XEP and the community desires one.
>>
>> I want to suggest one small change to how the attached-to message is
>> specified: I always assumed that, if xep359 is used to refer a message,
>> the reference would not just be the id-value, but a tuple of id-value
>> and the id-assigning-entity address.
>> This avoids ambiguity if a  attaches to a stanza which
>> multiple  elements. Furthermore, xep359 makes it very clear
>> that xep359-IDs are just unique and stable within the scope of the
>> id-assigning-entity (this allows implementations to use simple
>> mechanisms to generate the ID without considering collisions with other
>> id-assigning-entities).
> 
> Good point, thanks Flo. Although I’m not sure that 359 does make it clear 
> that it’s not globally unique

The XEP currently states

The value of the 'id' attribute must be unique and stable, i.e. it MUST
NOT change later for some reason within the scope of the 'by' value.
Thus the IDs defined in this extension MUST be unique and stable within
the scope of the generating XMPP entity.

which tries to express this, but the wording can (and should) probably
be improved.

, actually the opposite - I believe it’s a SHOULD on using UUID,

No, it is just a friendly recommendation to simply use UUIDs, not a SHOULD.

> and my understanding has always been that these are intended to be globally 
> unique (I realise you have authority on claims of the original intention) 
> from reading it. This isn’t the only XEP that’s written on the basis of the 
> unique IDs being unique :)

Oh, the IDs are unique. But only if you concatenate the 'by' value with
the ID. Or, in other words, the tuple (xep359-id, xep359-id-by) is
guaranteed by xep359 to be globally unique.

One reason why xep359 makes this distinction is to prevent ID spoofing.
Consider an archive which contains a message with the xep359-id 'id1'
and another user now refers to this message just using 'id1'. If now an
(malicious) entity would be able to add to the archive another message
with the same xep359-id 'id1', but a different xep359-id-by value, then
it is not clear anymore which message is refereed to.

Hence one should always use the tuple (xep359-id, xep359-id-by) when
referring to stanzas using xep359 IDs. And this is the coordinate system
fastening should use to establish a link to other messages.

- Florian
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Jonas Schäfer]

(lots of snipping going on, comment inline)

On Donnerstag, 12. Dezember 2019 17:49:20 CET Kevin Smith wrote:
> On 12 Dec 2019, at 15:08, Dave Cridland  wrote:
> > On Thu, 12 Dec 2019 at 12:11, Marvin W  > > wrote: I think the question this comes down to
> > is, what we want to build using fastenings. I don't want reactions to
> > reactions, but if we allow some sort of "comment" as a Fastening, then we
> > should also allow reactions to such comments.
> > 
> > 
> > Interesting - from a syntactic viewpoint, you're absolutely right. But I
> > think you're entirely wrong from a protocol behaviour standpoint. So I
> > wonder if there's a distinction to be made between various kinds of
> > relationship:
> > 
> > * […]
> > 
> > * […]
> > 
> > * Messages where the content relates to another. Comments, threading,
> > replies, etc are all closely related to another message, but they're
> > clearly a message in their own right. A degradation here might involve
> > losing the relationship rather than the message.
> > 
> > I think Fastenings really only cover the first - MAM would here provide a
> > summary view of any fastenings. MAM doesn't urgently need to support the
> > last case at all. The middle case is somewhat harder - we might want to
> > have MAM aware of these but it would need to collate these in full - and
> > perhaps it even provides a unified view of a message and its edits etc?
> > 
> > As a thought experiment, it'd be interesting to ask:
> > 
> > 1) Are there any other "buckets" of message relationship types?
> > 
> > 2) What existing relationships fit into what types?
> > 
> > 3) What typical behaviours do we want to see (and thus support) on the
> > clients?
> 
> […]
> 
> 3) summary=‘urn:xmpp:fastening:none:0': 
> Where the new message is a new message in its own right, but that has some
> sort of link to a previous one. e.g. Comments (I’m not convinced that this
> is the right way to be doing comments, but if we did, like this). These can
> have their own fastenings. ‘Messages where the content relates to another’
> from Dave’s list.

The third case deviates a lot from the original intent of Fastening (e.g. by 
allowing recursion) and covers cases for which we’re very far from having 
proper UX.

I suggest to omit this use case from fastening if you ever get to the point 
where it would complicate matters (e.g. business rules w.r.t. recursive 
fastenings).


kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Jonas Schäfer]

On Mittwoch, 11. Dezember 2019 18:10:32 CET Kevin Smith wrote:
> > The  element should always state the QName of the external
> > element. I suggest we normalize the namespace of , and the other
> > few elements that carry multiple namespaces, to jabber:client.
> 
> I’ll go along with the majority here if more people provide feedback.

What exactly is a QName? prefix:foo? I find the syntax currently proposed by 
Fastening better in that it doesn’t require to carry state about the XML tree 
beyond the XML parser.

In any case, the namespace should *always* be explicitly specified with the 
normalisation suggested by Florian (i.e. treat jabber:server and jabber:client 
as equivalent and normalise them to jabber:client).

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Kevin Smith]

Thanks for the feedback. I don’t want to ignore this, but was trying to digest 
bits.

> On 12 Dec 2019, at 12:10, Marvin W  wrote:
> 
> On 12/11/19 6:50 PM, Kevin Smith wrote:
>>> The business rules in §4 say that a Fastening can not have a Fastening
>>> themselves. If both message attaching, reactions and others are realized
>>> using Fastening, this implies that you can not react to an attached
>>> message, for example you would not be able to thumbs-up the fact that a
>>> bot provided a helpful attaching. While it is arguable that this is not
>>> strictly a required feature, the restriction seems to be unreasonable in
>>> that case.
>> This one was deliberate - reacting to reactions to reactions (and similar) 
>> is the sort of scenario that it’s easy to spec, but then generally horrific 
>> to implement (I refer to pubsub collections as a simpler example of where a 
>> similar concept seems pleasantly general but ends up being overcomplicated 
>> to work with - to the point of neglect).
> 
> I think the question this comes down to is, what we want to build using 
> fastenings. I don't want reactions to reactions, but if we allow some sort of 
> "comment" as a Fastening, then we should also allow reactions to such 
> comments.
> If we keep this restriction, I believe we'd need a generic standard for 
> associating a message to another message, independent of it being a fastening 
> or another kind of message (that can have fastenings).

I think we’re moving on this later in the thread.

> Also one of the reasons why everyone agreed it would help to have the 
> fastened elements as a sub-element of the  instead of directly in 
> the  as in XEP-0367, is that if we don't do that, it isn't clear how 
> to handle the correction of a message attaching case (a fastening of a 
> fastening). Thus if we decide against allowing fastening of fastenings, the 
> decision to use sub-element and  etc should be revisited...
> 
>> I think  can contain multiple elements, and they’re treated 
>> independently
>> So if you apply-to two elements, and then replace apply-to one element, it 
>> would replace the relevant one, leaving the other intact. If you then 
>> replace apply-to both elements, it would replace both of them. This is 
>> under-(not at all) specified.
>> For  elements, it should be the target name/namespace, as if it 
>> was a child.
> 
> How are edits supposed to work then? Because for various (good) reasons they 
> exist of multiple elements in the example. 
> https://xmpp.org/extensions/xep-0422.html#example-4

I need to go back and work through examples. I’m not immediately sure that what 
I was saying didn’t make sense. If you have multiple elements in an apply-to, 
you would replace them by specifying the replacement of the particular element 
(or elements) you wanted to replace. Am I missing the point?

> 
>>> What happens if a client accidentally does not add the `replace="true"`
>>> (for example because the same element was send from two different
>>> devices at about the same time)? Will a) there be two elements with the
>>> same namespace and name then, b) the second silently ignored or c) the
>>> first silently replaced? In case of a), how to decide which to replace
>>> in the future? In case of b), how does the sending entity know if there
>>> message was first or second? In case of c), why put `replace="true"` at
>>> all if it is implicitly done anyways?
>> Is it sufficient to assert that protocols that want to attach multiple of 
>> the same namespace then can’t replace them, or do we need ids on the 
>> fastenings?
>> I guess if we have 😂 and
>> 🤦🏻‍♂️ as individual fastenings, we need to be able to remove one and leave 
>> the other intact. OTOH, if a fastening contained one reaction for both 😂 and 
>> 🤦🏻‍♂️, it could be replaced with a reaction with just 🤦🏻‍♂️.
> 
> I don't quite understand what you want to say here. If each reaction is a 
> separate fastening, how do you remove a single one if you only identify 
> reactions by their qname.

That’s what I was saying, I think. If we were to treat multiple reactions as 
multiple fastenings, we would need to introduce new mechanisms. If we were to 
treat all reactions as one fastening, we wouldn’t.

> Also it apparently is currently specified how to replace but not how to 
> remove a fastening. Replacing with an empty variant may be technically 
> possible, but that empty variant would then still be required to send out to 
> clients (because we don't want servers to have to know what an empty variant 
> looks like for each fastening).

I’d made a note that removal isn’t specified, yes. I’ll address this.

>> I have assumed that if you’re doing full stanza encryption, and want 
>> archiving, your only choice as things stand is to have a complete download 
>> of your archive, and to do all collation locally. Having both smart 
>> archivability (without decryption) and encryption is a more or less 
>> unsolvable problem.
>> Does anyone have a wor

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Ruslan Marchenko]

Am Mittwoch, den 11.12.2019, 17:10 + schrieb Kevin Smith:
> > On 9 Sep 2019, at 20:37, Florian Schmaus  wrote:
> > Furthermore, xep359 makes it very clear
> > that xep359-IDs are just unique and stable within the scope of the
> > id-assigning-entity (this allows implementations to use simple
> > mechanisms to generate the ID without considering collisions with
> > other
> > id-assigning-entities).
> 
> Good point, thanks Flo. Although I’m not sure that 359 does make it
> clear that it’s not globally unique, actually the opposite - I
> believe it’s a SHOULD on using UUID, and my understanding has always
> been that these are intended to be globally unique (I realise you
> have authority on claims of the original intention) from reading it.
> This isn’t the only XEP that’s written on the basis of the unique IDs
> being unique :)
> 
> We probably need to clear this up - was I the only one with this
> misconception? (i.e. do we update 422 (and others) or 359?)
> 
Yes this was also my understanding all the way through. It is the
reason all my MAM indices are composite including id and assigning
entity.
If we go for UUID we'd probably need to mention which version it should
be and what to consider a namespace and name (if v5) or MAC (if v1) to
make sure there won't be other assumptions (like reproducible UUIDs -
for duplication/collision detection)

--RR


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Kevin Smith]

On 12 Dec 2019, at 15:08, Dave Cridland  wrote:
> 
> On Thu, 12 Dec 2019 at 12:11, Marvin W mailto:x...@larma.de>> 
> wrote:
> I think the question this comes down to is, what we want to build using 
> fastenings. I don't want reactions to reactions, but if we allow some 
> sort of "comment" as a Fastening, then we should also allow reactions to 
> such comments.
> 
> 
> Interesting - from a syntactic viewpoint, you're absolutely right. But I 
> think you're entirely wrong from a protocol behaviour standpoint. So I wonder 
> if there's a distinction to be made between various kinds of relationship:
> 
> * Messages that are pure ancillary messages, like a reaction. If I don't see 
> the reactions at all, it's not great, but probably a reasonable degradation. 
> Normally, I'll just want a summary on view. Sometimes I'll dig for more 
> detail.
> 
> * Messages where the content of the message substantially alters another. 
> Edits, attachments, etc. If I don't see these at all, I've got significant 
> information loss with regards to the conversation - I'm not just missing out 
> on some additional content, I'm actually seeing different content.
> 
> * Messages where the content relates to another. Comments, threading, 
> replies, etc are all closely related to another message, but they're clearly 
> a message in their own right. A degradation here might involve losing the 
> relationship rather than the message.
> 
> I think Fastenings really only cover the first - MAM would here provide a 
> summary view of any fastenings. MAM doesn't urgently need to support the last 
> case at all. The middle case is somewhat harder - we might want to have MAM 
> aware of these but it would need to collate these in full - and perhaps it 
> even provides a unified view of a message and its edits etc?
> 
> As a thought experiment, it'd be interesting to ask:
> 
> 1) Are there any other "buckets" of message relationship types?
> 
> 2) What existing relationships fit into what types?
> 
> 3) What typical behaviours do we want to see (and thus support) on the 
> clients?

I agree more or less with these distinctions, and think each needs distinct 
handling. I do see them all as being feasibly within fastening.

After a a discussion with Dave, I think the current best suggestion is that we 
annotate a fastening based on what type of summary is possible. This also 
largely aligns with Dave’s asterisks above.

1) summary=‘urn:xmpp:fastening:count:0': 
Messages that can be counted by having the same bodies (by the archive). e.g. 
Reactions where you want to know at a glance that 50 people reacted with 🤦🏻‍♂️, 
20 with 🤮. These messages are ‘pure ancillary messages’ in Dave’s above list, 
and so don’t themselves get fastened to. You can quick-query an archive to get 
the summary - you can also full-query to get the full details if you want, such 
as who made each fastening(reaction).

2) summary=‘urn:xmpp:fastening:full:0': 
Messages that can’t be collated with others, but where you need them for the 
first message to be complete. e.g. edits. These also don’t get fastened to. 
These are ‘where the content of the message substantially alters another’ in 
Dave terms.

3) summary=‘urn:xmpp:fastening:none:0': 
Where the new message is a new message in its own right, but that has some sort 
of link to a previous one. e.g. Comments (I’m not convinced that this is the 
right way to be doing comments, but if we did, like this). These can have their 
own fastenings. ‘Messages where the content relates to another’ from Dave’s 
list.

An indivdiual fastening type would have (in the defining XEP) a particular 
summary approach (e.g. Reactions are always count, edits are always full, 
comments are always none). This lets us put a cap on the madness that ensues if 
e.g. you can react to reactions to reactions, while also allowing reactions to 
those messages that logically contain content of their own, e.g. comments.

It is compatible with the previously discussed splitting of content and pointer 
in some manner that lets archives still return relevant fastenings in some 
manner while encrypted, although if the content is encrypted it will obviously 
be unable to count things.

This is a bit more optimistic than a strawman, but may well have holes. Please 
drive your busses through them. Thoughts?

/K

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Philipp Hörist]

Hi,

I am just realizing that all these magic server features are incompatible
to encryptions which use ratchet mechanisms. Because those depend on
messages received in order.
So for example OMEMO could never use these archive features, I don't think
we can do anything about that.

We still have OpenPGP. Which should have no problem with that.

Yeah your approach with the "external name" stuff looks fine to me.

I'm not sure about this merge approach, looks like it could run into server
stanza size limits in bigger group chats, definitely doesn't seem like it
can scale up well.
For single chat this should be fine and probably convenient, for group
chats i think it makes more sense to request fastend content separately.

Not sure what you mean by archive id and message id mismatch, yes those are
never the same but why is this a problem?
When we use the merge functionality of the server we would never need the
archive ids of fastening messages, only for non-fastening messages. because
of that i would say the archive-id can be omitted and the applied content
can also be within the forwarded element. Or maybe I don't understand what
other problem there is.

Would be interesting to get the opinion of server developers if such merge
features are even realistic to implement.

Regards
Philipp
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Dave Cridland]

On Thu, 12 Dec 2019 at 12:11, Marvin W  wrote:

> I think the question this comes down to is, what we want to build using
> fastenings. I don't want reactions to reactions, but if we allow some
> sort of "comment" as a Fastening, then we should also allow reactions to
> such comments.
>
>
Interesting - from a syntactic viewpoint, you're absolutely right. But I
think you're entirely wrong from a protocol behaviour standpoint. So I
wonder if there's a distinction to be made between various kinds of
relationship:

* Messages that are pure ancillary messages, like a reaction. If I don't
see the reactions at all, it's not great, but probably a reasonable
degradation. Normally, I'll just want a summary on view. Sometimes I'll dig
for more detail.

* Messages where the content of the message substantially alters another.
Edits, attachments, etc. If I don't see these at all, I've got significant
information loss with regards to the conversation - I'm not just missing
out on some additional content, I'm actually seeing different content.

* Messages where the content relates to another. Comments, threading,
replies, etc are all closely related to another message, but they're
clearly a message in their own right. A degradation here might involve
losing the relationship rather than the message.

I think Fastenings really only cover the first - MAM would here provide a
summary view of any fastenings. MAM doesn't urgently need to support the
last case at all. The middle case is somewhat harder - we might want to
have MAM aware of these but it would need to collate these in full - and
perhaps it even provides a unified view of a message and its edits etc?

As a thought experiment, it'd be interesting to ask:

1) Are there any other "buckets" of message relationship types?

2) What existing relationships fit into what types?

3) What typical behaviours do we want to see (and thus support) on the
clients?

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Marvin W]

On 12/12/19 2:53 PM, Philipp Hörist wrote:
This is a pretty substantial feature so to fallback to a "Download the 
whole archive" approach to make it work is not a good solution for me 
and will probably lead to fastening not working with full stanza encryption


The solution for me is to separate metadata and content


I totally agree we should make sure encryption is fully considered in 
the design of Fastening (although some features will never work on 
encrypted messages).


However I don't think your suggested solution will serve this purpose. 
One reason I understood why we put elements inside the  is 
that this way, servers know which part of the messages is to be fastened 
and can strip out all the parts of the message not required for the client.


So with your example but encrypted and useless metadata added:


  
  
  


Servers would be able to fasten the message to the correct referenced 
message, however they can not strip the useless metadata as it's not 
clear what is important and what is not. Example for useless metadata 
would be a store hint.


I think I like this model more:


  [...]



  

  
  
  


Which the server can "merge" to:


  [...]
  

  


It would even allow subsequent edits to replace without leaking anything 
other that one message replaces another:



  

  
  
  


Resulting in


  [...]
   
  

  


(Stuff is going to be a bit more complicated as message IDs and archive 
IDs mismatch...)
(I am putting the  directly in message here, but it would in 
practice be outside the  element in a MAM message)


Marvin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Kevin Smith]

Thanks Philipp.

On 12 Dec 2019, at 13:53, Philipp Hörist  wrote:
> The solution for me is to separate metadata and content
> 

> lets do something like
> 
>  to="chatroom@chatservice.example">
> 
> 
>   Very much
>   
> 

This seems like a good compromise, I’ll incorporate similar, thanks. (I think 
Marvin suggested a similar approach, I’m going to work through his mail next).

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Philipp Hörist]

Hi,

The current approach is not good for full stanza encryption. And we have to
assume full stanza encryption will become the norm at some point so any
proposal should have that in mind.
Full stanza encryption does not mean Full stanza encryption. There are
elements that are never encrypted, for example store hints for the server,
delay elements added by the server, and im sure i will find one or two more.

Full stanza encryption means, we encrypt everything that makes sense and
don't negatively impact usability.

This is a pretty substantial feature so to fallback to a "Download the
whole archive" approach to make it work is not a good solution for me and
will probably lead to fastening not working with full stanza encryption

The solution for me is to separate metadata and content

So instead of


  
  Very much
  


lets do something like




  Very much



This allows us to encrypt content but not the metadata, and in turn allows
the server archive to do some magic, for example if we want to request all
messages which were fastened to another message.

Keep in mind if this metadata leak is a problem for a client, nobody forces
a client to support fastening while encryption is activated. But it should
be possible if the user wishes.

Regards
Philipp
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Marvin W]

On 12/11/19 6:50 PM, Kevin Smith wrote:

The business rules in §4 say that a Fastening can not have a Fastening
themselves. If both message attaching, reactions and others are realized
using Fastening, this implies that you can not react to an attached
message, for example you would not be able to thumbs-up the fact that a
bot provided a helpful attaching. While it is arguable that this is not
strictly a required feature, the restriction seems to be unreasonable in
that case.


This one was deliberate - reacting to reactions to reactions (and similar) is 
the sort of scenario that it’s easy to spec, but then generally horrific to 
implement (I refer to pubsub collections as a simpler example of where a 
similar concept seems pleasantly general but ends up being overcomplicated to 
work with - to the point of neglect).


I think the question this comes down to is, what we want to build using 
fastenings. I don't want reactions to reactions, but if we allow some 
sort of "comment" as a Fastening, then we should also allow reactions to 
such comments.
If we keep this restriction, I believe we'd need a generic standard for 
associating a message to another message, independent of it being a 
fastening or another kind of message (that can have fastenings).


Also one of the reasons why everyone agreed it would help to have the 
fastened elements as a sub-element of the  instead of directly 
in the  as in XEP-0367, is that if we don't do that, it isn't 
clear how to handle the correction of a message attaching case (a 
fastening of a fastening). Thus if we decide against allowing fastening 
of fastenings, the decision to use sub-element and  etc should 
be revisited...



I think  can contain multiple elements, and they’re treated 
independently
So if you apply-to two elements, and then replace apply-to one element, it 
would replace the relevant one, leaving the other intact. If you then replace 
apply-to both elements, it would replace both of them. This is under-(not at 
all) specified.
For  elements, it should be the target name/namespace, as if it was 
a child.


How are edits supposed to work then? Because for various (good) reasons 
they exist of multiple elements in the example. 
https://xmpp.org/extensions/xep-0422.html#example-4





What happens if a client accidentally does not add the `replace="true"`
(for example because the same element was send from two different
devices at about the same time)? Will a) there be two elements with the
same namespace and name then, b) the second silently ignored or c) the
first silently replaced? In case of a), how to decide which to replace
in the future? In case of b), how does the sending entity know if there
message was first or second? In case of c), why put `replace="true"` at
all if it is implicitly done anyways?


Is it sufficient to assert that protocols that want to attach multiple of the 
same namespace then can’t replace them, or do we need ids on the fastenings?
I guess if we have 😂 and
🤦🏻‍♂️ as individual fastenings, we need to be able to remove one and leave the 
other intact. OTOH, if a fastening contained one reaction for both 😂 and 🤦🏻‍♂️, 
it could be replaced with a reaction with just 🤦🏻‍♂️.


I don't quite understand what you want to say here. If each reaction is 
a separate fastening, how do you remove a single one if you only 
identify reactions by their qname.


Also it apparently is currently specified how to replace but not how to 
remove a fastening. Replacing with an empty variant may be technically 
possible, but that empty variant would then still be required to send 
out to clients (because we don't want servers to have to know what an 
empty variant looks like for each fastening).



I have assumed that if you’re doing full stanza encryption, and want archiving, 
your only choice as things stand is to have a complete download of your 
archive, and to do all collation locally. Having both smart archivability 
(without decryption) and encryption is a more or less unsolvable problem.

Does anyone have a workable way to go beyond ‘archive can’t be smart’ with E2E?


It depends on how "smart" your archive should be. Just attaching a 
message to another message does work perfectly fine with encrypted 
messages, but you can obviously not summarize them.


What does not work with encryption is to know the qname of the element. 
And I think it would be desirable to not leak that for the sake of 
smarter archiving (so that it cannot be seen if I react to a message or 
just mark it as read), so if we can come up with something that makes 
this not required, that would be great. It could even be that this can 
not work well with race conditions (= you have to have received the last 
encrypted reaction before you can send a new encrypted reaction and if 
you didn't, others will always have to fetch both just to find out that 
they only needed one after decrypting).


By the way, I can hardly imagine summarizing to work in a generic way. 
The only

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Kevin Smith]

Thanks Marvin. I really am sorry for the delay in the reply.

On 6 Sep 2019, at 23:11, Marvin W  wrote:
> 
> Just a few things I noticed while reading this proto xep:
> 
> In the introduction it describes "a server adding information on a link
> previously posted to a chat room" as a use case of Fastening, which is
> exactly a use cases of XEP-0367 (Message Attaching) as already pointed
> to by Sam. Is it expected that XEP-0367 is updated to use Fastening
> instead or basically be completely abandoned in favor of Fastening?

There was a discussion in Council at the time about this. It was believed (I 
forget who asserted it now) that Sam had said he didn’t want 367 used for the 
things 422 is to be used for, and we decided it was easiest to start a new spec 
for the sake of expediency. If we want to roll 422 into 367 or whatever, it’s 
probably orthogonal to getting the right protocol specced.

> The business rules in §4 say that a Fastening can not have a Fastening
> themselves. If both message attaching, reactions and others are realized
> using Fastening, this implies that you can not react to an attached
> message, for example you would not be able to thumbs-up the fact that a
> bot provided a helpful attaching. While it is arguable that this is not
> strictly a required feature, the restriction seems to be unreasonable in
> that case.

This one was deliberate - reacting to reactions to reactions (and similar) is 
the sort of scenario that it’s easy to spec, but then generally horrific to 
implement (I refer to pubsub collections as a simpler example of where a 
similar concept seems pleasantly general but ends up being overcomplicated to 
work with - to the point of neglect).

So we could allow this, obviously, but I think there needs to be a very strong 
story as to why the complexity is needed before we do - I suspect that if we 
did allow such generality in the spec it would then be ignored (potentially in 
non-interoperable ways) by implementations (e.g. some implementations will end 
up only rendering reactions to the first layer, etc.). Is anyone working on a 
project that has this as a concrete requirement?

> §3.3 describes a `replace="true"` attribute that can be added to
>  to indicate that a message replaces a previous message. The
> rules say that it is to be decided by the namespace and name of the
> child payload, which element to replace. Does that mean that an
>  must contain exactly one element? How does this play together
> with  elements?

This is a good question. Do you think this needs clarification, or is broken?
I think  can contain multiple elements, and they’re treated 
independently.
So if you apply-to two elements, and then replace apply-to one element, it 
would replace the relevant one, leaving the other intact. If you then replace 
apply-to both elements, it would replace both of them. This is under-(not at 
all) specified.

For  elements, it should be the target name/namespace, as if it was 
a child.

Shall I go ahead and update to reflect this, or does it need further discussion?

> What happens if a client accidentally does not add the `replace="true"`
> (for example because the same element was send from two different
> devices at about the same time)? Will a) there be two elements with the
> same namespace and name then, b) the second silently ignored or c) the
> first silently replaced? In case of a), how to decide which to replace
> in the future? In case of b), how does the sending entity know if there
> message was first or second? In case of c), why put `replace="true"` at
> all if it is implicitly done anyways?

Is it sufficient to assert that protocols that want to attach multiple of the 
same namespace then can’t replace them, or do we need ids on the fastenings?
I guess if we have 😂 and 
🤦🏻‍♂️ as individual fastenings, we need to be able to remove one and leave the 
other intact. OTOH, if a fastening contained one reaction for both 😂 and 🤦🏻‍♂️, 
it could be replaced with a reaction with just 🤦🏻‍♂️.

> I see severe problems when using this together with XEP-0420 (Stanza
> Content Encryption). Which content is expected to be encrypted? If the
> whole stanza is encrypted, the server looses the id information and thus
> can not make use of the advantage of Fastening. If we encrypt the
> content of , the replacing logic will select the 
> element from XEP-0420 to decide which message to replace, which means
> all encrypted messages would (potentially) replace each other (for
> example an encrypted read marker and an encrypted thumbs up reaction).
> If the encrypted content is a sibling to the  and the
>  contains an  to reference inside the encrypted
> content, it would leak the name of the element inside the encryption.

I have assumed that if you’re doing full stanza encryption, and want archiving, 
your only choice as things stand is to have a complete download of your 
archive, and to do all collation locally. Having both smart archivability 
(without decrypt

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Kevin Smith]

> On 9 Sep 2019, at 20:37, Florian Schmaus  wrote:
> 
> On 9/5/19 7:52 PM, Jonas Schäfer (XSF Editor) wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>> 
>> Title: Message Fastening
>> Abstract:
>> This specification defines a way for payloads on a message to be
>> marked as being logically fastened to a previous message.
>> 
>> URL: https://xmpp.org/extensions/inbox/fasten.html
> 
> Thank you, Kev for pushing this forward. I think the kind of attention
> this ProtoXEP already has received, shows that the XMPP ecosystem needs
> such a XEP and the community desires one.
> 
> I want to suggest one small change to how the attached-to message is
> specified: I always assumed that, if xep359 is used to refer a message,
> the reference would not just be the id-value, but a tuple of id-value
> and the id-assigning-entity address.
> This avoids ambiguity if a  attaches to a stanza which
> multiple  elements. Furthermore, xep359 makes it very clear
> that xep359-IDs are just unique and stable within the scope of the
> id-assigning-entity (this allows implementations to use simple
> mechanisms to generate the ID without considering collisions with other
> id-assigning-entities).

Good point, thanks Flo. Although I’m not sure that 359 does make it clear that 
it’s not globally unique, actually the opposite - I believe it’s a SHOULD on 
using UUID, and my understanding has always been that these are intended to be 
globally unique (I realise you have authority on claims of the original 
intention) from reading it. This isn’t the only XEP that’s written on the basis 
of the unique IDs being unique :)

We probably need to clear this up - was I the only one with this misconception? 
(i.e. do we update 422 (and others) or 359?)

> That is my main concern with the current ProtoXEP right now. However, I
> am probably going to think a little bit more about it, which could lead
> to some more feedback.
> 
> 
> What follows are some nits and remarks in no particular order:
> 
> Please remove "that contains content" from the very first sentence, to
> make it more readable.

Will do.

> Explicitly referring to Entity Capabilities (XEP-0115) in § 2. is
> redundant and prone to becoming outdated. I wish XEPs would instead
> point to a location, for example in XEP-0030, where the interested
> reader can read more about the current state of affairs regarding
> feature discovery caching mechanisms. I would be happy to create such a
> location if there is a consensus that this is a good idea.

This is fair, but also consistent with other XEPs, so I’m inclined to leave for 
the moment.

> The  element should always state the QName of the external
> element. I suggest we normalize the namespace of , and the other
> few elements that carry multiple namespaces, to jabber:client.

I’ll go along with the majority here if more people provide feedback.

> The semantic of attaching again to a message which we already attached
> to while using replace=false should be spelled out. Assuming 'false' is
> the default value for the 'replace' attribute. I probably need to think
> some more about it, but it feels like replace='true' is like a reset: It
> doesn't just replace a single "attachment" but all previously attached
> messages (regarding the child payload in question). Is that correct?

I’ll try to find some words that are clearer.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Kevin Smith]

On 10 Sep 2019, at 08:20, JC Brand  wrote:
> 
> 
> 
> Am 7. September 2019 15:03:49 MESZ schrieb Andrew Nenakhov 
> mailto:andrew.nenak...@redsolution.com>>:
>> Seems like a copy of XEP-0367 Message Attaching. It also shares the
>> same
>> problem: no explanation whatsoever on how to fetch these attachments
>> from a
>> Message Archive in any efficient way. Ideally, we should retrieve a
>> message
>> from an archive with all its attachments. 
> 
> I agree, especially for thin (e.g. web) clients this is an issue.
> 
> If I connect and want to get the last 20 messages of a MUC, but 19 are 
> reactions (and maybe even for a message not included in the results) then I 
> in effect get only one showable message back.
> 
> This is already an issue with markers and receipts AFAIK (which could make 
> use of fastening for those too).

The right model here (for that type of client), to my eyes is to log in, get 
the last 20 messages of the MUC (or 1:1 chat for that matter) and for those 20 
messages to be base messages (for want of a good description). They could be 
returned on their own, with a subsequent query for their metadata (fastenings), 
or they could be returned with metadata. But what shouldn’t happen is that you 
ask for 20 messages and you get 1 base message with 19 messages of metadata 
(probably none of which relate to that base message).

> 
>> We should also have some kind of
>> notification on reconnecting that a previously received message
>> received/updated an attachment (or attachments) while we were offline.
> 
> This seems less of an issue to me since I'd in any case to a catch-up query, 
> unless you're referring to something like the mythical "inbox" feature.

I’m inclined to try to address it afterwards, since if we have protocols that 
successfully query the archive, this is a different view onto that.

/K___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Kevin Smith]

On 7 Sep 2019, at 14:17, Daniel Gultsch  wrote:
> 
> Am Sa., 7. Sept. 2019 um 13:05 Uhr schrieb Andrew Nenakhov
> :
>> 
>> Seems like a copy of XEP-0367 Message Attaching. It also shares the same 
>> problem: no explanation whatsoever on how to fetch these attachments from a 
>> Message Archive in any efficient way. Ideally, we should retrieve a message 
>> from an archive with all its attachments. We should also have some kind of 
>> notification on reconnecting that a previously received message 
>> received/updated an attachment (or attachments) while we were offline.
>> 
>> Without some kind of plan to deal with these issues, any discussion about 
>> attachments will result in half-baked XEP that can only be implemented on 
>> hardcore 'traditional' clients that enjoy a persistent connection.
> 
> I agree that any fastening/attaching/referencing XEP with the implied
> intent of making collective retrieval from MAM possible should also
> specify (or at least be released simultaneously with a XEP that does)
> said retrieval. Both to make the intent of the XEP clear and to make
> sure that the generic mechanism really is generic enough to handle
> that.

In an ideal world, I don’t disagree with you. In this instance my aim was to 
get Fastening out ASAP so Reactions could be rebased on it and unblocked. But I 
do see archive access in my near future now.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Kevin Smith]

On 7 Sep 2019, at 14:03, Andrew Nenakhov  
wrote:
> Seems like a copy of XEP-0367 Message Attaching. It also shares the same 
> problem: no explanation whatsoever on how to fetch these attachments from a 
> Message Archive in any efficient way. Ideally, we should retrieve a message 
> from an archive with all its attachments. We should also have some kind of 
> notification on reconnecting that a previously received message 
> received/updated an attachment (or attachments) while we were offline. 

Given your message to the other thread, I think we’re fairly well aligned on 
what’s needed here. I do believe that as long as we get Fastening going in a 
sensible direction, development of the archive access model can happen

> Without some kind of plan to deal with these issues, any discussion about 
> attachments will result in half-baked XEP that can only be implemented on 
> hardcore 'traditional' clients that enjoy a persistent connection. 

We did come up with a plan for this at the summit (or at least an intended 
direction). Fastening is the first step of this - subsequent steps are the 
archive access. Clients with full knowledge of the archive, or that require 
permanent connections, are not the model I’m shooting for, and definitely not 
the only one that needs considering.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[JC Brand]

Am 7. September 2019 15:03:49 MESZ schrieb Andrew Nenakhov 
:
>Seems like a copy of XEP-0367 Message Attaching. It also shares the
>same
>problem: no explanation whatsoever on how to fetch these attachments
>from a
>Message Archive in any efficient way. Ideally, we should retrieve a
>message
>from an archive with all its attachments. 

I agree, especially for thin (e.g. web) clients this is an issue.

If I connect and want to get the last 20 messages of a MUC, but 19 are 
reactions (and maybe even for a message not included in the results) then I in 
effect get only one showable message back.

This is already an issue with markers and receipts AFAIK (which could make use 
of fastening for those too).

> We should also have some kind of
>notification on reconnecting that a previously received message
>received/updated an attachment (or attachments) while we were offline.

This seems less of an issue to me since I'd in any case to a catch-up query, 
unless you're referring to something like the mythical "inbox" feature.

>Without some kind of plan to deal with these issues, any discussion
>about
>attachments will result in half-baked XEP that can only be implemented
>on
>hardcore 'traditional' clients that enjoy a persistent connection.
>
>чт, 5 сент. 2019 г. в 22:53, Jonas Schäfer :
>
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: Message Fastening
>> Abstract:
>> This specification defines a way for payloads on a message to be
>> marked as being logically fastened to a previous message.
>>
>> URL: https://xmpp.org/extensions/inbox/fasten.html
>>
>> The Council will decide in the next two weeks whether to accept this
>> proposal as an official XEP.
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Florian Schmaus]

On 9/5/19 7:52 PM, Jonas Schäfer (XSF Editor) wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Message Fastening
> Abstract:
> This specification defines a way for payloads on a message to be
> marked as being logically fastened to a previous message.
> 
> URL: https://xmpp.org/extensions/inbox/fasten.html

Thank you, Kev for pushing this forward. I think the kind of attention
this ProtoXEP already has received, shows that the XMPP ecosystem needs
such a XEP and the community desires one.

I want to suggest one small change to how the attached-to message is
specified: I always assumed that, if xep359 is used to refer a message,
the reference would not just be the id-value, but a tuple of id-value
and the id-assigning-entity address.
This avoids ambiguity if a  attaches to a stanza which
multiple  elements. Furthermore, xep359 makes it very clear
that xep359-IDs are just unique and stable within the scope of the
id-assigning-entity (this allows implementations to use simple
mechanisms to generate the ID without considering collisions with other
id-assigning-entities).

So assume we have


  
…


The according  element should include a 'id-by' (name is
subject to bikeshedding) attribute:



I was not yet able to conclude how it should look like for 1:1 chat and
. However, I assume that the only relevant case where you
want to attach to via  is 1:1 chat. All other cases I can
think of right now, like MUC and MIX, would have the room/channel as
id-assigning-entity and therefore use . Then the value of
'id-by' attribute could potentially be the full JID of the sender in
case of .


That is my main concern with the current ProtoXEP right now. However, I
am probably going to think a little bit more about it, which could lead
to some more feedback.


What follows are some nits and remarks in no particular order:

Please remove "that contains content" from the very first sentence, to
make it more readable.

Explicitly referring to Entity Capabilities (XEP-0115) in § 2. is
redundant and prone to becoming outdated. I wish XEPs would instead
point to a location, for example in XEP-0030, where the interested
reader can read more about the current state of affairs regarding
feature discovery caching mechanisms. I would be happy to create such a
location if there is a consensus that this is a good idea.

The  element should always state the QName of the external
element. I suggest we normalize the namespace of , and the other
few elements that carry multiple namespaces, to jabber:client.

The semantic of attaching again to a message which we already attached
to while using replace=false should be spelled out. Assuming 'false' is
the default value for the 'replace' attribute. I probably need to think
some more about it, but it feels like replace='true' is like a reset: It
doesn't just replace a single "attachment" but all previously attached
messages (regarding the child payload in question). Is that correct?

- Florian
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Daniel Gultsch]

Am Sa., 7. Sept. 2019 um 13:05 Uhr schrieb Andrew Nenakhov
:
>
> Seems like a copy of XEP-0367 Message Attaching. It also shares the same 
> problem: no explanation whatsoever on how to fetch these attachments from a 
> Message Archive in any efficient way. Ideally, we should retrieve a message 
> from an archive with all its attachments. We should also have some kind of 
> notification on reconnecting that a previously received message 
> received/updated an attachment (or attachments) while we were offline.
>
> Without some kind of plan to deal with these issues, any discussion about 
> attachments will result in half-baked XEP that can only be implemented on 
> hardcore 'traditional' clients that enjoy a persistent connection.

I agree that any fastening/attaching/referencing XEP with the implied
intent of making collective retrieval from MAM possible should also
specify (or at least be released simultaneously with a XEP that does)
said retrieval. Both to make the intent of the XEP clear and to make
sure that the generic mechanism really is generic enough to handle
that.

cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Andrew Nenakhov]

Seems like a copy of XEP-0367 Message Attaching. It also shares the same
problem: no explanation whatsoever on how to fetch these attachments from a
Message Archive in any efficient way. Ideally, we should retrieve a message
from an archive with all its attachments. We should also have some kind of
notification on reconnecting that a previously received message
received/updated an attachment (or attachments) while we were offline.

Without some kind of plan to deal with these issues, any discussion about
attachments will result in half-baked XEP that can only be implemented on
hardcore 'traditional' clients that enjoy a persistent connection.

чт, 5 сент. 2019 г. в 22:53, Jonas Schäfer :

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Message Fastening
> Abstract:
> This specification defines a way for payloads on a message to be
> marked as being logically fastened to a previous message.
>
> URL: https://xmpp.org/extensions/inbox/fasten.html
>
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>


-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Fastening

[Marvin W]

Just a few things I noticed while reading this proto xep:

In the introduction it describes "a server adding information on a link
previously posted to a chat room" as a use case of Fastening, which is
exactly a use cases of XEP-0367 (Message Attaching) as already pointed
to by Sam. Is it expected that XEP-0367 is updated to use Fastening
instead or basically be completely abandoned in favor of Fastening?

The business rules in §4 say that a Fastening can not have a Fastening
themselves. If both message attaching, reactions and others are realized
using Fastening, this implies that you can not react to an attached
message, for example you would not be able to thumbs-up the fact that a
bot provided a helpful attaching. While it is arguable that this is not
strictly a required feature, the restriction seems to be unreasonable in
that case.

§3.3 describes a `replace="true"` attribute that can be added to
 to indicate that a message replaces a previous message. The
rules say that it is to be decided by the namespace and name of the
child payload, which element to replace. Does that mean that an
 must contain exactly one element? How does this play together
with  elements?
What happens if a client accidentally does not add the `replace="true"`
(for example because the same element was send from two different
devices at about the same time)? Will a) there be two elements with the
same namespace and name then, b) the second silently ignored or c) the
first silently replaced? In case of a), how to decide which to replace
in the future? In case of b), how does the sending entity know if there
message was first or second? In case of c), why put `replace="true"` at
all if it is implicitly done anyways?

I see severe problems when using this together with XEP-0420 (Stanza
Content Encryption). Which content is expected to be encrypted? If the
whole stanza is encrypted, the server looses the id information and thus
can not make use of the advantage of Fastening. If we encrypt the
content of , the replacing logic will select the 
element from XEP-0420 to decide which message to replace, which means
all encrypted messages would (potentially) replace each other (for
example an encrypted read marker and an encrypted thumbs up reaction).
If the encrypted content is a sibling to the  and the
 contains an  to reference inside the encrypted
content, it would leak the name of the element inside the encryption.

There is a bit of uncertainty which ID to use. §3 says 
should be used and the examples all refer to an origin-id. §4 says
 must be present. IMO the correct would be to use 
in groupchat and either  or message id (in that order, if
they mismatch) in chat. This behavior is also described in other XEPs IIRC.

Marvin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Proposed XMPP Extension: Message Fastening

[XSF Editor]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Message Fastening
Abstract:
This specification defines a way for payloads on a message to be
marked as being logically fastened to a previous message.

URL: https://xmpp.org/extensions/inbox/fasten.html

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___