ср, 19 июн. 2019 г. в 21:33, Ralph Meijer :
> On 19/06/2019 19.46, Sergey Ilinykh wrote:
> > Hi
> >
> > I mostly implemented SIMS in Psi and see next problems
> >
> > 1) The requirement for top-level reference element looks strange.
> > In Most of the case when I want to share something, I don
On 19/06/2019 19.46, Sergey Ilinykh wrote:
Hi
I mostly implemented SIMS in Psi and see next problems
1) The requirement for top-level reference element looks strange.
In Most of the case when I want to share something, I don't want to
refer to anything.
If I really want to have a refer
Hi
I mostly implemented SIMS in Psi and see next problems
1) The requirement for top-level reference element looks strange.
In Most of the case when I want to share something, I don't want to
refer to anything.
If I really want to have a reference I would add it inside of
.
2) Top-level re
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Stanza Content Encryption
Abstract:
The Stanza Content Encryption (SCE) protocol is intended as a way to
allow clients to securely exchange arbitrary extension elements using
different end-to-end encryption schemes.
URL: htt
Version 0.6.0 of XEP-0300 (Use of Cryptographic Hash Functions in
XMPP) has been released.
Abstract:
This document provides a common wire format for the transport of
cryptographic hash function references and hash function values in
XMPP protocol extensions.
Changelog:
Remove hash function recomm
Version 1.15.8 of XEP-0060 (Publish-Subscribe) has been released.
Abstract:
This specification defines an XMPP protocol extension for generic
publish-subscribe functionality. The protocol enables XMPP entities to
create nodes (topics) at a pubsub service and publish information at
those nodes; an
On Wed, Jun 19, 2019 at 01:25:04PM +, Tedd Sterr wrote:
> 2019-05-22 (expired 2019-06-05)
> PASSED (-0:0:+5) PR #690 - XEP-0184: Make the schema require @id in
> - https://github.com/xsf/xeps/pull/690
>
>
> 2019-06-12 (expiring 2019-06-26)
>
> Last Call: XEP-0300 (Use of Cryptographic Hash
2019-05-22 (expired 2019-06-05)
PASSED (-0:0:+5) PR #690 - XEP-0184: Make the schema require @id in
- https://github.com/xsf/xeps/pull/690
2019-06-12 (expiring 2019-06-26)
Last Call: XEP-0300 (Use of Cryptographic Hash Functions in XMPP) -
https://xmpp.org/extensions/xep-0300.html
Dave: +1
Ge
http://logs.xmpp.org/council/2019-06-12?p=h#2019-06-12-dffc419b3a1e1957
1) Role Call
Present: Jonas, Dave, Georg, Kev
Better-late-than-never: Link
2) Agenda Bashing
The agenda already appears to be suitably bashed.
3a) Last Call: XEP-0280 (Message Carbons) -
https://xmpp.org/extensions/xep-0280
On Wed, Jun 19, 2019 at 01:04:07PM +0200, Kim Alvefur wrote:
> Feature negotiation doesn't work becasue since the introduction of
> Carbons and MAM you no longer have any idea which clients will receive
> anything you sendwhich will receive anything you send.
When is it that you could determine wh
On Tue, Jun 18, 2019 at 11:03:51AM +0200, Philipp Hörist wrote:
> Feature negotiation in encryption process is a fail in General.
Feature negotiation doesn't work becasue since the introduction of
Carbons and MAM you no longer have any idea which clients will receive
anything you sendwhich will r
Thank you Kim for explaining that. I wasn’t aware that Prosody was doing this.
FWIW I’m totally fine with that solution as well (if Server developers
don’t consider that too resource heavy).
I’m in no way attached to the proposal I made. I just want to move to
a solution that doesn’t involve my mo
Hello,
On Tue, Jun 18, 2019 at 11:47:10AM +, Daniel Gultsch wrote:
> There are a few reasons why a participant might get (knowingly or not)
> be kicked out of a MUC. While it might be tempting to find a solution
> that works for every scenario I suggest we look into the different
> So instead
13 matches
Mail list logo
