Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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. > >>> > >>>

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

(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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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,

Re: [Standards] Proposed XMPP Extension: Message Fastening

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 >

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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. > >

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

> 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 >>

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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. > >

Re: [Standards] Proposed XMPP Extension: Message Fastening

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 >

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

Re: [Standards] Proposed XMPP Extension: Message Fastening

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

[Standards] Proposed XMPP Extension: Message Fastening

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