Comments inline. I'm trying a new MUA, I hope it won't butcher this message.
30 Dec 2019 6:58:51 pm Dave Cridland :
> Please note Section 2.3 in this document.
> Having some clear and consistent mechanism for indicating that, when
> heuristically deciding if a message is an "Instant Message", s
31 Dec 2019 2:41:31 am Marvin W :
> Hi,
>
> I'd like to express my concern that the purpose of this proposed XEP is
> mostly around defining a specific API to library developers. According
> to XEP-0001, a Standards Track XEP defines a *wire protocol* intended to
> be used as a standard part of
Hi,
I'd like to express my concern that the purpose of this proposed XEP is
mostly around defining a specific API to library developers. According
to XEP-0001, a Standards Track XEP defines a *wire protocol* intended to
be used as a standard part of XMPP technologies. Nothing indicates that
a XEP
For the curious, this relates to the discussion here:
https://mail.jabber.org/pipermail/jdev/2019-September/090402.html
On Mon, 30 Dec 2019 at 13:29, Jonas Schäfer wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: User-defined Data Transfer
> Abstract:
> This
Please note Section 2.3 in this document.
Having some clear and consistent mechanism for indicating that, when
heuristically deciding if a message is an "Instant Message", systems should
ignore the and would eliminate my arguments against
using enthusiastically for fallback purposes. So *someth
On Mon, 30 Dec 2019 at 17:16, Philipp Hörist wrote:
> hi,
>
> Am Mo., 30. Dez. 2019 um 17:57 Uhr schrieb Dave Cridland <
> d...@cridland.net>:
>
>> That specification isn't linked from XEP-0384 at all, so how are we
>> supposed to be able to tell it affects OMEMO?
>>
>
> You can't, and the XEP do
hi,
Am Mo., 30. Dez. 2019 um 17:57 Uhr schrieb Dave Cridland :
> That specification isn't linked from XEP-0384 at all, so how are we
> supposed to be able to tell it affects OMEMO?
>
You can't, and the XEP does not mandate any specific implementation or
protocol version of the non-standard Signa
That specification isn't linked from XEP-0384 at all, so how are we
supposed to be able to tell it affects OMEMO?
On Sat, 28 Dec 2019 at 17:30, Paul Schaub wrote:
> That is true.
> The related part of the double ratchet spec is
> https://signal.org/docs/specifications/doubleratchet/#out-of-order
If you like the XMPP Standards Foundation and you want to help it, then
join us.
If you don't like the XMPP Standards Foundation and you'd rather it
changed, then join us.
On Mon, 30 Dec 2019 at 11:39, Alexander Gnauck wrote:
> I have setup the membership application Wiki page for the applicati
On Mon, 30 Dec 2019 at 14:35, Jonas Schäfer wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Special Interests Group End to End Encryption
> Abstract:
> This document proposes the formation of a Special Interest Group (SIG)
> within the XSF devoted to the deve
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Special Interests Group End to End Encryption
Abstract:
This document proposes the formation of a Special Interest Group (SIG)
within the XSF devoted to the development of end-to-end encryption
within the context of XMPP.
UR
Version 0.2.0 of XEP-0422 (Message Fastening) has been released.
Abstract:
This specification defines a way for payloads on a message to be
marked as being logically fastened to a previous message.
Changelog:
Preparation for extending MAM (ks/dwd)
URL: https://xmpp.org/extensions/xep-0422.html
Hello everyone!
During the 36C3 a bunch of people finalized the idea to form a SIG
dedicated to end-to-end encryption. The desired outcome of the SIG would
be to facilitate development on E2EE related technology within the XSF.
Concrete goals include, but are not limited to:
* Work on specifying
Version 0.2.0 of XEP-0422 (Message Fastening) has been released.
Abstract:
This specification defines a way for payloads on a message to be
marked as being logically fastened to a previous message.
Changelog:
Preparation for extending MAM (ks/dwd)
URL: https://xmpp.org/extensions/xep-0422.html
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Fallback Indication
Abstract:
This specification proposes a mechanism by which message bodies can be
marked as being purely for fallback purposes, and therefore to be
ignored by intermediaries and anything that understands th
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: User-defined Data Transfer
Abstract:
This specification proposes a simple mechanism by which applications
can transfer data safely, without needing additional protocol design
work. It is intended to provide a protocol that is
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: MAM Fastening Collation
Abstract:
This specification proposes a mechanism by which MAM results
containing fastenings can be collated effectively.
URL: https://xmpp.org/extensions/inbox/mamfc.html
The Council will decide in
I have setup the membership application Wiki page for the application
period Q1 2020
Applications are encouraged from developers and others who are actively
involved in the Jabber/XMPP community. To apply, create a page about
yourself on the Wiki:
https://wiki.xmpp.org/web/Membership_Applicat
18 matches
Mail list logo