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, reac
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
>
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 F
Am Do., 12. Dez. 2019 um 09:24 Uhr schrieb Dave Cridland :
> 1) The "Florian Plan" - introduce a phase prior to Experimental, wherein a
> XEP is semi-adopted but remains without a number. This somewhat happens
> anyway, but it does so outside our IPR rules, so arguably this is a case of
> forma
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 Op
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.
>
>
Interesti
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
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
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 e
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
On 12 Dec 2019, at 09:22, Dave Cridland wrote:
>
> Many moons past, we had a clever idea.
>
> What we thought was that we should change the XML namespace system we used -
> previously, XEPs had been allocated a namespace when adopted, and they stuck
> with this namespace throughout. Sometimes
Many moons past, we had a clever idea.
What we thought was that we should change the XML namespace system we used
- previously, XEPs had been allocated a namespace when adopted, and they
stuck with this namespace throughout. Sometimes this broke things during
Experimental (indeed, if a XEP had to
12 matches
Mail list logo
