[Standards] Re: XEP-0045 join events

[Philipp Hörist]

Hi,

> Is it allowable that a server sends _more_ events (that are not in the list 
> specified in XEP-0045)?

Yes as Point 5 of the event list clearly means "everything else" as denoted by 
the "etc.", accounting for the extensible nature of XMPP.

Not sure what there is to discuss. What do you think would be excluded under 
Point 5?

Or are you asking if you can inject new undefined Events *before* Point 5? To 
that question i would definitely have the opinion, No you should not do that, 
and its not allowed and unexpected.

You gave no example what could be that important that it needs to be inserted 
earlier than point 5 in the event order.

If you are talking about Prosodys room self presence which communicates an 
avatar then its clearly not necessary to send this presence before the subject.

Not sure if Prosody sends the avatar presence before the subject, but it was 
never and will never be necessary to satisfy the use case of communicating the 
avatar. So if you are asking if you should do the same, i would say No, please 
send after subject as allowed by the XEP.

Or is there any other concrete example you are asking for?

Regards
Philipp


On Fri, Oct 18, 2024, at 16:45, Guus der Kinderen wrote:
> Hello XMPP aficionados!
> 
> For a client joining a MUC, XEP-0045 defines a very strict order of events 
> (section 7.1). Is it allowable that a server sends _more_ events (that are 
> not in the list specified in XEP-0045)?
> 
> I've observed that in the wild, at least one implementation sends a presence 
> stanza 'from the room itself' (with CAPS), preceding the events defined in 
> section 7.1.
> 
> There is an argument to be made that the XEP defines the order of the events, 
> but leaves room for there to be 'more' events. One could argue that this is 
> in line with the extensible nature of XMPP. 
> 
> On the other hand, I think that it's fair to say that this is stretching 
> things to an extent where it is not unreasonable for implementations to not 
> account for this (thus introducing potential interop issues).
> 
> I would like for the XEP to be more explicit, and either explicitly allow or 
> disallow this behavior. I have not quite made my mind up which way I lean, to 
> be honest. I'm interested in learning about the views on this from the 
> community.
> 
> For context, this has been previously discussed in the XSF Discussion MUC. 
> This is a link to the public message archive of that discussion. 
> https://logs.xmpp.org/xsf/2024-09-07#2024-09-07-78b71f7983a88d14
> 
> Kind regards,
> 
>   Guus
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org
> 
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: UPDATED: XEP-0402 (PEP Native Bookmarks)

[Philipp Hörist]

> 
> Ultimately, my argument is that I want to set autojoin to false and for it to 
> remain false, and not to be changed when I happen to join a room; obviously 
> when it's now used in place of 'joined', that's unavoidable. But then, I 
> never want to autojoin a room, so arguably that should be a client setting 
> and the attribute is useless to me too.

I think you are a bit late to the party there.

Since years in Gajim, we don't expose the user to protocol details of 
bookmarks. We removed all mentions of bookmarks. No user does need to know the 
protocol details how a client syncs known chats. Why would a user need to learn 
what "autojoining a MUC" means when using Gajim.

I think your fear that this language change in the XEP makes your usage 
impossible is overblown.

What the XEP describes for me is a fair, common sense implementation, in 
absence of any advanced settings that your client may offer.

I think all your wishes can be implemented by a client who offers more control 
for that, call it "advanced multi device muc join settings".

Is this discussion maybe just a different opinion on what "SHOULD" entails?
When i read the RFC keyword definition, it seems ok for me that a developer 
offers settings that ignore this SHOULD.

I think there are valid use cases for ignoring the autojoin flag, or storing 
join information locally instead of syncing it to pubsub etc. and this SHOULD 
would not stop me implementing settings to satisfy such use cases.

Regards
Philipp___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0439: Quick Responses - Feedback

[Philipp Hörist]

hi

On Mon, Jul 15, 2024, at 23:17, Tim Henkes wrote:
> 
> Voting (and polls) are actually something I thought about beforehand and
> wanted to have them covered by this XEP. My idea is that rules like the
> ones you mentioned are enforced by the voting bot and not the XEP. The
> XEP simply gives you a way to trigger an action - the voting bot would
> be the one to "execute" the action, including check whether the same
> person is trying to vote again and block that/make it a correction
> instead etc.
> 
> Does that sound okay?
> 

Actually no, sounds like it does not cover the most basic things i would expect 
from a voting functionality.

 1. It should be possible for every user to create a vote, without the help of 
bots
 2. The results should be able to be displayed live, not only at the end of a 
vote
 3. Vote Correction, Voting for multiple options, etc should be a thing
 4. Probably many other simple features other messengers provide with votes

When you propose that this XEP should be used for voting, and that rules are 
enforced by a bot, what i see is

 1. In a MUC with 500 users, people spamming the message archive with responses 
which everyone else will then download, although they cannot display them 
because they have no idea about the rules of the vote, because only the bot 
knows what counts
 2. No client even has an idea that this is a vote, can only be guessed from 
the text by the user, not programmatically by the client, so no custom UI 
possible.
 3. Answer from the bot is undefined, will it be simply the result as text 
message? Again not possible to do any kind of UI.
If this really should be used for voting, the XEP does not add anything over 
what we have today.
 We currently can send whole XEP-0004 dataforms with every message and its well 
defined and implemented how dataforms are to be filled out and submitted. The 
actions part of the XEP is in essence a dataform with a single list field 
option.

Regards
Philipp


___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Encrypted peer-to-peer XML channel

[Philipp Hörist]

Hi,

Your constraints seem rather far fetched.

You are offline? What does this mean? in a local network, not connected to the 
internet?
How do you find and connect to another device without server?

Why would you need to transfer your history specifically in these conditions?

Simply upload to http server encrypted.
XML Stream via Server is not a good way to transfer hundreds of megabytes.

Is this about the transport method? Or the format?
Because interoperable format seems like a big task, transport seems easy.
I think defining the transport and where to store is useful short term, then 
every client can offer their own backup.
Its useful independent of the format.

im less optimistic for a standardized exchange format.

Regards
Philipp

On Mon, Jul 15, 2024, at 21:55, Andrew Nenakhov wrote:
> We're not currently doing it but considering to do in the future. Very much 
> likely we'll just do an upload of an encrypted archive via cloud storage. 
> This way it can be interoperable with the likes of Dropbox / gdrive / 
> whatever.
> 
> On Tue, Jul 16, 2024, 00:51 Tim Henkes  wrote:
>> Hi folks,
>> 
>> 
>> I've been brainstorming a mechanism for offline history transfer (i.e.
>> one client fetches the offline message history from another client). For
>> that, an encrypted direct client-to-client XML channel would be neat.
>> 
>> 
>> 1. Are direct client-to-client XML channels a thing?
>> 
>> I found XEP-0247 [1], which looks alright on first read-through but is
>> deferred since 2010. Does someone more familiar with the topic know why
>> the XEP was abandoned and whether it could realistically be revived or
>> if there is a better alternative now?
>> 
>> 
>> 2. Are encrypted direct client-to-client channels a thing?
>> 
>> There is JET [2], but it seems to focus on key negotiation (which I
>> would do differently) and file transfers, which I don't need either. I
>> don't see how a bidirectional data channel/stream would be encrypted
>> using JET.
>> 
>> There's also a XEP called jingle-xtls [3] in the Inbox, but it's even
>> more abandoned than XEP-0247 and also seems to focus mostly on the key
>> negotiation, which again I would do differently.
>> 
>> 
>> Next to these questions I would be interested in the general sentiment
>> and ideas for workarounds (e.g. "p2p is cursed, just send encrypted
>> stanzas via the server as usual" or "just use a simple binary format and
>> don't bother with a fully fledged XML stream").
>> 
>> 
>> Thanks :D
>> 
>> Tim
>> 
>> 
>> [1] https://xmpp.org/extensions/xep-0247.html
>> 
>> [2] https://xmpp.org/extensions/xep-0391.html
>> 
>> [3] https://xmpp.org/extensions/inbox/jingle-xtls.html
>> 
>> ___
>> Standards mailing list -- standards@xmpp.org
>> To unsubscribe send an email to standards-le...@xmpp.org
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org
> 
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0439: Quick Responses - Feedback

[Philipp Hörist]

Hi,

On Mon, Jul 15, 2024, at 22:42, Tim Henkes wrote:
> I think responses in MUC would only cause chaos, maybe the XEP should just 
> forbid that.
> 
> Actions in MUC should be good though, I want actions to work in MUCs. Voting 
> should be fine too as long as everybody is aware that the votes are not 
> anonymous. Why do you think this XEP might not be right for voting?
> 

I didnt think it through what would actually be necessary for a good voting 
functionality. I just wanted to know if it was considered by the XEP.

I think voting is a think that deservs its own XEP and should not be an 
afterthought.

For voting i think much more rules would be needed, like for example not 
accepting 2 votes from the same person, or interpet a different vote from the 
same person as correction, etc.

Regards
Philipp___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0439: Quick Responses - Feedback

[Philipp Hörist]

Hi,

# Responses

Thanks for the replies, i think i understand the  use case a bit 
bettter.

I think this could make use of fallback text, which we can remove if the XEP is 
supported.
Because its not needed that the body mentions the options again if we have 
buttons for it.

But other than that i think its fine, altough it will be a bit akward to 
implement, sounds easy, but with rules like "only if its the last message" im 
sure its not that straight foward when implementing.

# Actions

On Mon, Jul 1, 2024, at 09:54, Marvin W wrote:
> 
> > Sending clients MUST keep in mind that they have to choose/generate
> ids for each  accordingly, if they need to differentiate
> between messages.
> 
> 

Feels vague, basically says, whoever sends a message can do what he wants.

I know already what my client users want to see

- They want to know what message they already answered 
- They will answer messages from other devices, but want to see it on all 
devices

I see no reason not to include the message id i answered to, this can only be 
beneficial.
Its maybe not needed for the sender, but for clients to easily implement and 
provide nice GUI.

I see already users complain on the client side, and we can tell every single 
developer of the sending code to set proper ids.

So please lets just skip that, and add proper reference to the message. Every 
sender is free to ignore that information if they do not need it. But it is 
incredibly helpful on the client side to provide nice GUI.

# Other things

- Do we want to mix actions with responses? I hope not, but this should maybe 
mentioned in the XEP
- Are there usecases for MUCs? I think only actions would theoretically work. I 
fear people will do voting with this. Im not sure if this spec is right for 
this use case.

Regards___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] XEP-0439: Quick Responses - Feedback

[Philipp Hörist]

Hi,

I looked through the XEP and i find a few things not great.

Im not getting the difference between  and .
And the XEP makes no attempt to describe it.

A question that i answer with "Yes" or "No" should be a response, but a 
Question that i answer with "Merge" is an action?
Seems completely random. The XEP mentions no use case that can only be done 
with , i see no reason at all as a client developer to implement this.

Now for , the id attribute is under specified, it seems essential to 
the whole thing working at all.
Should this be a globally unique ID? Or at least unique per remote JID?

In my opinion  should have another id attribute (of course differently 
named) referencing the message it belongs to.
We have this pattern with message errors, iq responses, reactions, message 
replies, moderation, etc., we should not break this pattern here for no gain, 
just because its theoretically possible to still match this if the id is 
globally unique.

I think this is a really nice idea and feature, but it should fit in with 
current XEP patterns, and better describe what  even should 
accomplish.

Is the original Author still around?
I also looking forward to other peoples opinions.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] XEP-0424/425 Feedback

[Philipp Hörist]

Hi,

Some feedback while trying to implement these XEPs

XEP-0424
1)
The schema mentions



But the XEP does not mention the attribute, what is the purpose?

2)
> When replacing the original message with a tombstone, the original contents 
> (i.e. the  and any related elements which might leak information about 
> the original message) get replaced with a  element which MUST 
> include an 'id' attribute referring to the original message

Why does the element MUST have an id attribute? its a element inside the 
 which already has the id, or in case of groupchat its inside a mam 
wrapper which has a stanza id, in all cases its perfectly clear that the 
retracted element belongs to the actual message wrapping it, maybe im missing 
something obvious here but i dont see a need for this id attribute at all.

Example 7

> For messages of type 'groupchat', the stanza's Unique and Stable Stanza IDs 
> (XEP-0359)  [4 
> ] 'origin ID' 
> MUST NOT be used for retractions

Example mentions origin-id in groupchat context






XEP-0425
1)
> A Message Archive Management (XEP-0313) 
>  [6 
> ] service MAY 
> replace the contents of a message, that was retracted due to moderation, with 
> a 'tombstone' similar to the one described in Message Retraction (XEP-0424) 
>  [5 
> ].

How similiar? The tombstone text does not mention seemingly important MUST 
rules from XEP 0424

For example

> Some clients may have been offline while the retraction was issued. The 
> archiving service therefore MUST store the retraction message, regardless of 
> whether the original message is deleted or replaced with a tombstone.

the above mentioned MUST rule about the id attribute in the  
element, seems to be not important anymore in moderation, at least the id 
attribute is not found anymore in the tombstone.

Im not saying we need to copy text 1:1 between the XEPs, but should the XEP not 
go into more detail what exactly the differences are, and what exactly from 
0424 applies?

Thanks
Regards
Philipp
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

Re: [Standards] Some questions about profile and nickname (XEP 0054, 0154, 0292)

[Philipp Hörist]

Hi,

About nickname, it depends on your use case with xmpp.
If you want to write a standard client for a federated world, i would
suggest ignoring the field in the VCard, and not allow users to set it.
Its less complex to have only one place to store a nickname, and everybody
supports 0172.
Also its way less traffic to subscribe to 0172 node updates.

Of course nobody stops you from syncing those two.

Regards
Philipp

Am So., 2. Okt. 2022 um 22:14 Uhr schrieb Simon Lipp <
aekai...@simon.lipp.name>:

> Hello,
>
> I’ve been reading profile related XEPs, and one point that has never
> been mentioned is the possibilty (or lack of) multilingual fields. Let’s
> say that I want a note in English and another version in French in my
> profile (be vCard-temp, vCard4 or User Profile). Is that a possibility ?
> A quick search of "xml:lang" in the mentioned XEPs does not yield
> anything on that topic.
>
> Another non-mentioned subject is the synchronization between the
> different XEPs, especially about the nickname field which plays a
> special role in XEP-0172. Should a server, on a publish action on the
> node http://jabber.org/protocol/nick, attempt to update to the vCard/user
> profile of the user ? Should a client that modifies the NICKNAME field
> of vCard-temp also publish on the http://jabber.org/protocol/nick node ?
>
> Regards,
>
> Simon
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

[Philipp Hörist]

Hi,

Im also looking into implementing ISR.
I think also that the HT-* method should be split out from the XEP.

ISR has value without making auth a one step action. It reduces in its
basic form without token auth the RTTs already.

If there is a auth method which reduces RTTs even more, great, recommend it
or link to it, but dont mandate it.

Further make it future proof, Who knows what new auth methods will be
invented. Provide a framework for fast resumption, but let people choose
themself how fast they need to go. (read what auth method they use).

Regards
Philipp

Am So., 28. Aug. 2022 um 16:44 Uhr schrieb Matthew Wild :

> On Wed, 24 Aug 2022 at 12:18, Matthew Wild  wrote:
> > I'm also looking at potentially implementing it in Prosody very soon,
> > as part of the modern auth project (
> > https://docs.modernxmpp.org/projects/auth/ ).
>
> Now that I've read the XEP through some more times, and have a bit of
> an implementation, I'm wondering why we are bundling instant stream
> resumption and token auth together?
>
> At least one client/deployment has indicated the desire to do the
> round-trip saving resumption using normal password authentication
> (i.e. with-isr-token='false').
>
> Also, if the client has an ISR token but cannot resume the stream
> (e.g. it has restarted and didn't persist the local stream state),
> there is no way to authenticate using the token, and there is no way
> to enable a new XEP-0198 session within .
>
> For the 2FA use-case, I need to use tokens to identify specific
> device/client installations over the long term, independent of
> XEP-0198 sessions. As things stand, I don't think XEP-0397 can
> properly fulfill this requirement. Note that just because I need to
> identify the device in the long term, doesn't mean the token must stay
> the same (I actually like that it can be rotated on each use). But I
> feel there are corner cases, such as if a disconnect occurred between
>  and the XEP-0198 ,
> where the client may end up needing to fall back to password
> authentication.
>
> This subtle complexity where ISR seems to fail at saving round-trips
> in some cases and at preserving client credentials in others, along
> with some deployments only wanting password auth, leads me to
> wondering if we shouldn't just split the two concerns into different
> specs co-existing within the framework of SASL2.
>
> Regards,
> Matthew
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP Versioning

[Philipp Hörist]

Hi,

I just wanted to throw into the discussion that breaking changes is not the
only thing to consider.
Often new features are added to XEPs which are not breaking but someone
still wants to know if a client implements it.

Example XEP: 0045
Version 1.30: Add 333 status code with OPTIONAL feature.

As a server/client developer i can imagine that a quick scan over all
clients/servers who implements > 1.30 can be useful.

This happens in my opinion more often in XEPs than breaking changes which
need a namespace bump.

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

Re: [Standards] What to do about multi-item data forms?

[Philipp Hörist]

Hi,

While i also think that its probably better to write a note that says
 and  should not be mixed in the same form, i dont see a
good reason why we cant use  and  with the reported
form.

It does not add complexity and is useful to provide some context with the
form.

So if we limit the usage of the XEP lets not throw the baby out with the
bathwater.

Regards
Philipp

Am Di., 19. Juli 2022 um 21:47 Uhr schrieb Florian Schmaus :

> On 19/07/2022 14.46, Sam Whited wrote:
> > Thinking about this more, I'm not sure that it makes sense to clarify
> > this in a new XEP. Did we ever come up with something along the lines
> > of IETF erratas or editors notes that we could put at the beginning of
> > the document?
>
> I would prefer to update the existing XEP if this is an option. I think
> it may be.
>
>
> > After re-reading this thread it's still unclear to me what the original
> > intent was and it doesn't seem like anyone else besides Peter and I
> > have opinions,
>
> It was not so long ago when I reworked Smack's Data Form code. IIRC I
> was under the impression that  and  do *not* appear
> within the same data form.
>
> I believe that disallowing mixing  and  within the same
> form makes interoperability easier, as it reduces the valid
> possibilities how the protocol could be used. Ideally use-cases like the
> one mentioned (jmp.chat) can instead be build of an optional extension
> protocol, probably based on using two data forms.
>
> In any case, this should be clarified in the XEP. So thanks for your
> effort Sam! :)
>
> - Flow
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0425 (Message Moderation)

[Philipp Hörist]

Hi,

Thanks Marvin for that feedback, i have to say i missed all those issues.

I would consider the IQ issue the biggest issue, from an xmpp lib
standpoint, i want to parse the namespace of the child and then route the
stanza to a very specific codepath or handler.
Making this a generic element which does not belong to any specific XEP is
real ugliness and pain, and this should not move forward in my opinion.

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

Re: [Standards] LAST CALL: XEP-0425 (Message Moderation)

[Philipp Hörist]

Hi,

looking again through the standard i noticed two things

Example 8, misses the moderate namespace on the moderated tag

and the other thing is more of a design consideration

The data is in 3 different pairing of tags

1. moderate - retract (Client sends this)
2. moderated - retract (Server sends to client)
3. moderated - retracted (Tombstone)

This to me sounds more like a protocol written for humans to read, rather
than for machines to parse.
So more code needs to be written, but developers can read it in the correct
tense if they look at the protocol on the web.

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

Re: [Standards] LAST CALL: XEP-0425 (Message Moderation)

[Philipp Hörist]

>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>

Yes


>
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>

Yes


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>

Yes its implemented in Gajim 1.4


> 4. Do you have any security concerns related to this specification?
>

No


> 5. Is the specification accurate and clearly written?
>

Yes

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

Re: [Standards] MAM Sync Strategies

[Philipp Hörist]

Thilo Molitor  schrieb am Fr., 27. Aug. 2021, 15:35:

>
> every MUC catchup delays only "live" message stanzas for that MUC, not
> other MUCs or 1:1).
>

How can you delay live messages from a muc ?

Lovetox

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

Re: [Standards] MUC Mention Notifications

[Philipp Hörist]

Hi,

Ok i think i get it, its a warmed up  XEP. Not a very successful
XEP btw.

Anyway back to the original use case for sending messages to people not
joined the MUC

i think Marvins approach is easier.
But it does not replace the reference mention, because we still need that
to mark up the text correctly. And yes references might be encrypted,
depending on the uri attr and what i can reference in the future, so i
would say we should not expect servers to be able to read references. And
its a recipe for disaster to encrypt some references and others not.

I really see no way how we can use references for these server features.

Seems like we duplicating here a bit of functionality between the XEPs
then, but i still think its the cleaner approach.

Regards
Philipp




Am Fr., 25. Dez. 2020 um 12:49 Uhr schrieb Marvin W :

> Hi,
>
> On 23.12.20 17:47, Philipp Hörist wrote:
> > and when would a client add this notify tag? Should the client let
> > the user decide? (I dont like that) Is there any reason why i would
> > not add  to every message? I see no downside for the sender
>
> Client should only add the  tag on user request (that is because
> they did a mention or otherwise signal they'd like to notify a user).
> The priority="high" tag should be even more restricted, e.g. should be
> confirmed by user explicitly. Client should not have an option to send
>  with every message.
>
> The downside for the sender is that the recipient probably doesn't like
> it when used without good reason and will probably hate you for doing
> it. Obviously, recipient clients would need to have certain limits for
> when they accept  (e.g. ignore them when in direct messages from
> strangers to not amplify the impact of spam or allow to disable support
> for it per-contact in case any of your important contacts just uses this
> feature too much).
>
> In large communities I've already seen users making excessive or
> unjustified use of @all or @channel, leading to their messages being
> removed, them being warned and/or banned. There can also be a server
> policy that only room members of a certain level are allowed to send
> these messages (or in our case  tags). Having a more dedicated
> feature for notifications that is not directly related to the message
> body helps servers to enforce such policy.
>
> Misuse of high priority notification (be it by adding a  tag or
> by mentioning) is a social issue that you can't tackle meaningfully on a
> protocol level alone.
>
>
> On 24.12.20 16:25, Matthew Wild wrote:
> >  would be largely duplicating the semantics of XEP-0372
> > mentions.
>
> XEP-0372 (in its current version 0.4.0) does not specify any semantics
> for mentions at all and (according to its introduction) only "provides a
> mechanism for marking up a section of a message body with information
> about the target of the reference".
>
>  would only be about semantics and not about marking up in
> message body at all. At least with the current specification, there
> would be little to no overlap and definitely no duplication. Sure enough
> you could go without the  element and create a XEP that adds
> semantic meaning to a XEP-0372 mention (which is what the suggested
> protoxep does). But I think splitting semantics and markup here makes a
> lot of sense.
>
> I am aware that some implementations may use XEP-0372 as an indicator to
> notify users in MUCs, but those implementations probably would also do
> this without XEP-0372 by matching body against the users nickname. Both
> is obviously unspecified behavior.  is about adding a properly
> specified method to (in the long run) replace such unspecified behavior.
>
> Marvin
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications

[Philipp Hörist]

Hi

and when would a client add this notify tag? Should the client let the user
decide? (I dont like that)
Is there any reason why i would not add  to every message? I see no
downside for the sender

best wishes
Philipp

Am Mi., 23. Dez. 2020 um 16:29 Uhr schrieb Kevin Smith <
kevin.sm...@isode.com>:

> On 23 Dec 2020, at 15:16, Marvin W  wrote:
> >
> > Hi there,
> >
> > I actually was working on something with partially overlapping goals,
> > that is
> > a) being notified for relevant groupchat messages via push
> > notifications. This is mostly relevant for iOS push notifications (at
> > least as far as I understood during last summit).
> > b) signal to recipient that a message is important to notify about (for
> > example, when out of office, still notify for the really important
> > things). This is a feature some of you may know from Slack.
> >
> > I was first thinking to base this around mentions as well, but that
> > would mostly work for a, not b (at least not how b is realized in Slack).
> >
> > I thus was to suggest a much more generic approach, that is to add a new
> > element  to the message
> > (completely independent of any use of mentions/references). Jid could be
> > left out in direct chats, in MUCs can point to the real jid, member jid
> > or room jid (equivalent to @channel mentioning), also there might be
> > value in an optional priority="high" attribute to signal higher message
> > priority.
> >
> > Your usecase of delivering messages to non-present MUC users seems to
> > fit into this schema. Also, adding server-side meaning to something that
> > is mostly formatting (mentions) seems a little bit weird to me.
> >
> > Another advantage of the  element approach is that it also works
> > for server-side processing in e2ee message (without leaking relevant
> > message details) as long as the  is not e2e encrypted (which it
> > shouldn't be as it's also meant to be processed by servers).
>
> I like this, I think this is a useful discussion to be having.
>
> I think there’s merit in something combining these two approaches. I think
> the idea of being able to specify that it’s meant to generate a
> notification is useful (and I can see why Slack’s ‘also say I want to
> override notification silencing’ would be useful - although for that to
> work as in Slack the sender has to be able to discover that the recipient
> has disabled notifications, and I suggest that a ‘please notify even if
> notifications are turned off’ flag would be useful if we go that route, as
> this processing is going to be recipient-side). Also useful is
> everything-under-the-Sun’s ability to @everyone and @groups, which a notify
> mechanism nicely addresses. Also useful is referencing a particular bit of
> the message to be the markup, like in references(mentions).
>
> /K
>
> > Marvin
> >
> >
> > On 18.12.20 18:00, JC Brand wrote:
> >> Hi all
> >>
> >> I've submitted a PR for a new protoXEP: MUC Mention Notifictions
> >>
> >> https://github.com/xsf/xeps/pull/1022
> >>
> >> The goal is to document how someone who's affiliated, but not currently
> >> present in a MUC might receive notifications when he/she is mentioned
> >> inside that MUC.
> >>
> >> For the concept of "mentions", XEP-0372 references are used.
> >>
> >> To enable this feature, I've opted for a configuration setting in the
> MUC.
> >>
> >> Apparently Tigase already has a similar feature to this protoXEP and
> >> relies on letting the user opt-in when registering a nickname with the
> MUC.
> >>
> >> Maybe someone from Tigase can comment on the particulars of that. My
> >> understanding is that this necessitates the ability to self-register in
> >> a MUC, which IMO adds a hurdle to adoption of this feature.
> >>
> >> Regards
> >> JC
> >>
> >>
> >> ___
> >> Standards mailing list
> >> Info: https://mail.jabber.org/mailman/listinfo/standards
> >> Unsubscribe: standards-unsubscr...@xmpp.org
> >> ___
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] UPDATED: XEP-0333 (Chat Markers)

[Philipp Hörist]

Hi,

You know that anyway because of stream management acks and if you received
no error.

Regards

Am Di., 13. Okt. 2020 um 03:41 Uhr schrieb Manuel Rubio <
man...@altenwald.com>:

> Hi,
>
> sorry to get this message too old from the list but I wanted to ask if
> it's possible to add "sent" to the list of markers.
>
> The "sent" will be very useful when a message is sent, the server
> replies directly to the user with a "sent" marker and then we know the
> server has the message.
>
> Kind regards,
> Manuel Rubio.
>
> El 2020-04-21 12:43, p...@bouah.net escribió:
> > Version 0.4 of XEP-0333 (Chat Markers) has been released.
> >
> > Abstract:
> > This specification describes a solution of marking the last received,
> > displayed and acknowledged message in a chat.
> >
> > Changelog:
> > Add notes about usage within MUCs. (mw)
> >
> > URL: https://xmpp.org/extensions/xep-0333.html
> >
> > Note: The information in the XEP list at https://xmpp.org/extensions/
> > is updated by a separate automated process and may be stale at the
> > time this email is sent. The XEP documents linked herein are up-to-
> > date.
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC identity + feature on mixed-operation domains / gateways (XEP-0045)

[Philipp Hörist]

Am So., 4. Okt. 2020 um 17:12 Uhr schrieb Georg Lukas :

>
> 2. Which of the above elements MUST a room on the domain have?
>

the identity conference/text and the feature.
because conference/text only points to a chat text service, not
specifically a MUC, that's what the feature is for.
At least that's what i get from

https://xmpp.org/registrar/disco-categories.html#conference


>
> 3. If the room in question does not exist, but would be auto-created on
> join, how can this be discovered by a client?
>

A disco info request to the address will yield item-not-found or some
similar error


>
> 4. Which of the above XML elements should a client use to determine
> whether a bare JID is a room? ...whether a domain JID is a MUC service?
>

service and room need an identity conference/text and the feature

https://xmpp.org/extensions/xep-0045.html#registrar-discocat
https://xmpp.org/extensions/xep-0045.html#registrar-features


> 5. What is the right order of events for a client trying to determine
> whether to add a JID to the roster or to join it as a room?
>
> - Send disco#info to the bare JID
>   - success: decided according to #4 above
> - join room / add contact
>   - item-not-found: send disco#info to domain JID? Maybe?
> - success: decide according to #4
>   - join room / add contact
> - failure: show an error
>
> This is two or three round-trips, and not very elegant. But the shortcut
> of sending a disco#info to the domain has led to funny errors in the
> past, and sending disco#info to the bare JID is insufficient if it is a
> room that doesn't exist but would be created on join.
>

I'm not following, do you believe disco info to a bare account jid will
yield item-not-found if it does not exist? That's not the case
if you get back item-not-found you can assume you are talking to a muc
service

so i don't see why you need a disco to the domain jid

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

Re: [Standards] Stanza ID of outgoing message

[Philipp Hörist]

Hi,

1. Sounds like a hack, i find it weird to connect these two XEPs like that,
and yes application layer does not need to know anything about stream
management right now
2. Carbon is complicated enough right now, also very inefficient to mirror
the whole stanza and more, only because we need the mam-id
3. Didn’t look into it

I also think we should do something specially for MAM.

regards
Philipp

Am So., 27. Sept. 2020 um 17:46 Uhr schrieb Holger Weiß <
hol...@zedat.fu-berlin.de>:

> When opening a new session, MAM clients might want to use the
> most-recent known XEP-0359 stanza ID to sync messages.  One problem they
> face is that there's no way to figure out the stanza ID of outgoing
> messages, short of actually querying them back from MAM.  Therefore, a
> common workaround is to use the stanza ID of the most-recent _incoming_
> message and then de-dup any outgoing messages returned from MAM.
>
> I think it would be good to find a better solution.  The issue has been
> discussed before, and I've seen at least the following suggestions:
>
> 1. Let XEP-0198 include the stanza ID with the stream management ACK.
>
>I like the idea of acknowledging the stanza and returning its ID in
>one go, but one concern I heard is that this might not play well with
>existing APIs: libraries may handle stream management transparently,
>while dealing with MAM sync is left to the application layer.
>
> 2. Let XEP-0280 carbon-copy messages back to the sender.
>
>Presumably the solution that requires the least-intrusive changes,
>both spec- and implementation-wise.  The downside I see is that the
>entire (XEP-0280-wrapped) message stanza is reflected just to return
>the stanza ID.
>
> 3. Let clients subscribe to XEP-0313 archiving, as suggested here, for
>example: https://geekplace.eu/xeps/xep-mamsub/xep-mamsub.html
>
>Would involve more changes, but might remove the need for XEP-0280
>altogether, which could be a nice goal in itself.  However, it has
>the same downside as solution (2).
>
> I'd prefer a solution that doesn't involve reflecting the entire stanza
> just to make the client aware of the stanza ID.  So if (1) is not an
> option, I think I'd opt for extending XEP-0359 or XEP-0313 (or, if
> people prefer, adding a new XEP) to return an ACK for outgoing 1:1
> messages.  E.g., something like this:
>
> | 
> |   
> | 
>
> Thoughts?
>
> Holger
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback on XEP-0420: Stanza Content Encryption (SCE)

[Philipp Hörist]

Am Di., 1. Sept. 2020 um 16:26 Uhr schrieb Linus Jahn :

> Hello folks,
>
> I'm planning to implement Stanza Content Encryption [1] in QXmpp [2] and I
> had
> a more detailed look at the XEP. Here are my open questions / suggestions:
>
> 1. The XEP suggests that each encryption method uses a  tag
> with
> xmlns=''. However, since the  element is not
> defined
> by SCE, there's no way of recognising a stanza as encrypted using SCE. I
> could
> only search for the elements defined by the supported encryptions QXmpp
> (in my
> case) knows about.
>
> My suggestion would be to define the  element in the SCE XEP
> instead of redefining it in each of the encryption mechanisms.
>
> Instead of:
> 
> ...
> 
>
> I'd suggest something like this:
> 
> ...
> 


There needs to be a container for the elements the encryption XEP needs
otherwise you would need to namespace all the children of  with
urn:xmpp:super-e2ee:0

  

  ...


  
PGNvbnRlbnQgeG1sbnM9J3Vybjp4bXBwOnNjZTowJz48cGF5bG9hZD48Ym9keSB4bWxucz0namFi
  
YmVyOmNsaWVudCc+SSBnb3QgaW4gZXZlcnlvbmUncyBob3N0aWxlIGxpdHRsZSBmYWNlLiBZZXMs
  
IHRoZXNlIGFyZSBicnVpc2VzIGZyb20gZmlnaHRpbmcuIFllcywgSSdtIGNvbWZvcnRhYmxlIHdp
  
dGggdGhhdC4gSSBhbSBlbmxpZ2h0ZW5lZC48L2JvZHk+PHggeG1sbnM9J2phYmJlcjp4Om9vYic+
  
PHVybD5odHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9GaWdodF9DbHViI1Bsb3Q8L3VybD48
  L3g+PC9wYXlsb2FkPjwvY29udGVudD4=

  


header is a child that would have to be namespaced with
urn:xmpp:super-e2ee:0, as namespaces are inherited

Not sure why you need to know that something is encrypted with SCE, you
find the encryption namespace and pass the stanza to the encryption module.


> 2. The XEP says that messages MUST NOT have an unencrypted  element.
> This means that I can't include a "fallback body" for clients that don't
> support SCE. How should I solve this (without violating the XEP)?
>

The famous fallback body, which client needs that? Only Pidgin? Client can
implement EME then they don't need to depend on a fallback body


> 3. How should SCE work with XEP-0380: Explicit Message Encryption [3]?
> Should
> SCE maybe replace EME at some point (SCE also annotates the encryption
> method)?
> Or should it maybe even recommend using EME in combination?
>

In my opinion it should recommend using EME, SCE can’t replace EME because
not all encryption mechanisms use SCE, and we can’t say that future
encryption mechanisms will use SCE.

SCE is for clients who don’t support a particular encryption mechanism,
right now they only need to implement EME and are fine for all eternity, if
we start to fragment that in recommending clients should not use EME when
using SCE, we end up in the same situation as before EME existed.

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

Re: [Standards] Feedback on XEP-0420: Stanza Content Encryption (SCE)

[Philipp Hörist]

Am Di., 1. Sept. 2020 um 17:03 Uhr schrieb Philipp Hörist <
phil...@hoerist.com>:

>
> SCE is for clients who don’t support a particular encryption mechanism,
> right now they only need to implement EME and are fine for all eternity, if
> we start to fragment that in recommending clients should not use EME when
> using SCE, we end up in the same situation as before EME existed.
>
>
Of course i mean "EME is for clients that .."

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

Re: [Standards] XEP0384 OMEMO pubsub#publish-options clarification

[Philipp Hörist]

Hi,

Just to be clear, the XEP mandates protocol features, not a default config
on your PubSub Service.

Default config does not make much sense, as other XEPs would need another
configuration, that would mean we would need per node default
configurations.

Publish Options solves that.

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

Re: [Standards] XEP0384 OMEMO pubsub#publish-options clarification

[Philipp Hörist]

Am Sa., 29. Aug. 2020 um 08:16 Uhr schrieb Ruslan N. Marchenko :

>
> The way I read it initially was "pubsub service MUST support persitent
> items" but it seems it really mandates pubsub default config rather than
> feature support?
>

No, and why do you think that?


> Then "'max' as value to persisy_items" I persume is a typo and should read
> as 'max' value to 'max_items' when used together with 'persist_items'?
>
>
Yes is a typo, should be fixed


> After I implemented publish-options, configure-node, persist-items,
> multi-items, delete-items (and retract-item which seem to be redundant) I
> still see the omemo merely sets access-model to open (as in XEP's example)
> but not others.
>

What do you mean by "omemo merely sets .." what is omemo in that context?


> And since my default pep node config is no persist, max 1, pam=presence it
> only flips pam to open and the rest remains as is (no persistence, max=1).
> Is it just conversations specific or the XEP really mandates defaults on
> the PEP node? It should be fairly easy to set the rest of the required
> options in publish options instead of mandating the defaults.
>

Conversations does not implement the XEP version you are referring to,
maybe that answers your question.

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

Re: [Standards] XEP0384 OMEMO pubsub#publish-options clarification

[Philipp Hörist]

Hi,

Note that major server implementation don’t support checking all fields
they support with publish-options

Means only because a server supports max_items, it does not mean it can
check the value via publish-options.

e.g. ejabberd

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

Re: [Standards] Bookmarks and autojoin issues

[Philipp Hörist]

Hi,

let me try with XEP-0402


  

  

  JC
  

   

  

  

  


- Clients offer a option to set one or more profiles for the device
- Clients can ask the user on joining a bookmark which profiles should be
added (one or multiple)
- Default is no profile
- If a Client has no profile set, it honors the autojoin attr
- If a Client has a profile set, he autojoins all bookmarks that have the
corresponding profile, effectively ignoring the autojoin attr
- If a client leaves a muc he removes the profile from the bookmark

Still sounds complex to me, not easy to make that user friendly in my
opinion

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

Re: [Standards] Bookmarks and autojoin issues

[Philipp Hörist]

Hi,

So whats your ideas how we can implement that?

What first comes to mind is, that 402 now can hold extended payloads in
each bookmark item.
So we just add the profile there?

and UI wise i ask the user when he joins a room to what profile he wants to
add that.

regards
Philipp


Am So., 24. Mai 2020 um 11:13 Uhr schrieb Mathieu Pasquet <
mathi...@mathieui.net>:

> On 24.05.2020 06:50, Philipp Hörist wrote:
> >Hi,
> >
> >The problem is there are no rules what goes into which profile.
> >
> >If i add a bookmark as a desktop client, i don't know if it should go
> into the
> >mobile profile or not.
> >And btw we try to abstract bookmarks away from the user, so managing
> profiles
> >of bookmarks for different devices is exactly not the direction i want to
> go.
> >
> >So either this can be determined automatically without user input (i
> doubt it)
> >or a simple local autojoin list where the user simply has to manually join
> >bookmarks is better in my opinion.
> >
> >Regards
> >Philipp
> >
> >
>
> Well, one easy to implement and to understand rule would be to, by
> default, create a single "default" profile and use that to effectively keep
> the current behavior of "everything is synced everywhere", unless the user
> configured it otherwise. I see this as an advanced feature and not
> something that most users would want to fiddle with (as I said, the
> issues mostly grow with the number of MUCs). The state would then be
> synced across clients referring to the same profile name.
>
> There is also a niche for client developers who could then use a
> test client with a distinct bookmarks profile without the need for a
> separate account.
>
> I have had local autojoin lists for a decade in poezio and frankly it
> is not a very good solution when not many clients support it, other
> clients abstract the bookmark management away from the user, and nothing
> is standard. You have the choice between having an unpredictable mix of
> remote bookmarks and local autojoins, or entirely disable remote bookmarks
> for the sake of sanity, which is not good either.
>
> Cheers,
> Mathieu
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Bookmarks and autojoin issues

[Philipp Hörist]

Hi,

The problem is there are no rules what goes into which profile.

If i add a bookmark as a desktop client, i don't know if it should go into
the mobile profile or not.
And btw we try to abstract bookmarks away from the user, so managing
profiles of bookmarks for different devices is exactly not the direction i
want to go.

So either this can be determined automatically without user input (i doubt
it) or a simple local autojoin list where the user simply has to manually
join bookmarks is better in my opinion.

Regards
Philipp




Am So., 24. Mai 2020 um 01:17 Uhr schrieb Maxime Buquet :

> On 2020/05/24, Mathieu Pasquet wrote:
> > Greetings,
> >
> > I want to raise an issue that appears with bookmarks in their current
> > form in the multi-client scenario. It appears as long as we have more
> > than one client, and gets worse for every added client and MUC bookmark.
> >
> > XEP-0048 and XEP-0402 both re-use the  element, which has
> > an autojoin flag. In a single-client scenario this is fine because that
> > represents what the user wants in terms of joined rooms. In a
> > multi-client scenario however, that quickly changes as you probably do
> > not want the same view everywhere.
>
> I agree.
>
> > The use cases I have in mind are a bit extreme (e.g. people with > 100
> > MUCs in their autojoined bookmarks), which are unusable on mobile, for
> > example, where screen space is limited and you probably want to limit
> > yourself to the "important" ones. Or when joining big IRC channels with
> > more than 1000 users, you also do not want that on mobile as that much
> > activity is never good for battery life, however optimized the client
> > might be. Even for smaller cases, such as 20-30 rooms, this can be a
> > limiting factor.
> >
> > Bookmarks in themselves only represent MUCs we want to keep in memory,
> > and that is fine. However tying the "autojoin" attribute in there means
> > we are now syncing client state, and that is not often desirable, for
> > the reasons stated above (different constraints, different platforms,
> > different attention spans).
> >
> > The following is probably over-engineered for a nerdy edge case, but one
> > viable solution would be the ability to manage sets of client "profiles"
> > which would hold client state independently from bookmarks. This could
> > be stored in PEP as well, and could be a list of pubsub URIs to the
> > stored bookmarks. Removing a bookmark would automatically remove the
> > autojoin in all profiles that link to it.
>
> I'm thinking that even if some clients don't want to implement support
> for multiple profiles, they could "just" implement support for a
> single/default profile, still allowing advanced clients to use different
> ones.
>
> This would allow for the bookmark list would to be a bookmark list and
> not a syncing mechanism.
>
> That list could be used in various cases where completion/suggestions
> are helpful.
>
> --
> Maxime “pep” Buquet
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0333: meaning of 'acknowledged'

[Philipp Hörist]

> Am Do., 21. Mai 2020 um 18:31 Uhr schrieb Andrew Nenakhov <
> andrew.nenak...@redsolution.com>:
>
>> Current text of XEP-0333 suggests that if a remote party acknowledges the
>> last voice
>> message out of many, all previous should be considered as
>> acknowledged.
>>
>
Yes i agree it's hard to imagine use cases where this would be useful

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

Re: [Standards] XEP-0333: meaning of 'acknowledged'

[Philipp Hörist]

@Matthew

Scrolling to the bottom should trigger a 

Only because i see something does not mean i acknowledge it

I can imagine a use case where you send a date and time for a meeting.

If i open the message my client should indicate that i saw the message, but
that does not mean  the date and time is OK for me. If it would be I could
indicate this via an ack.

regards
Philipp

Am Do., 21. Mai 2020 um 18:31 Uhr schrieb Andrew Nenakhov <
andrew.nenak...@redsolution.com>:

> I've said it again and I'll repeat it: we have a very clear example of
> how this feature can work. It's Telegram and their voice messages,
> which present a user a special dot if the voice message is unplayed by
> the remote side.
> Once the remote side plays the voice message (or 'interacts with it'),
> the dot disappears. Of course, this would work well only if
> acknowledged stanzas are sent for individual messages. Current text of
> XEP-0333 suggests that if a remote party acknowledges the last voice
> message out of many, all previous should be considered as
> acknowledged. This clearly contradicts a very well defined and useful
> use-case, so I believe that this part of 0333 should be revised.
>
> чт, 21 мая 2020 г. в 19:45, Matthew Wild :
> >
> > Hi folks,
> >
> > XEP-0333 defines the state:
> >
> > > acknowledged -- the message has been acknowledged by some user
> interaction e.g. pressing an acknowledgement button.
> >
> > If a user scrolls down to the bottom of a chat log, we know they are
> present and looking at the screen. This is user interaction. Should a
> client send ?
> >
> > Regards,
> > Matthew
> > ___
> > 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
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313: pending 0.7 update review

[Philipp Hörist]

Hi,

Yes you use the last known archive-id, this will yield sometimes some
duplicates which you can easily de-duplicate either with the message-id or
origin-id which are known to you.

We all wish there would be a mechanism that told us the stanza-id after we
sent a message but its not planned in this iteration of the XEP.

It's not the most efficient way to do this, but getting a stanza back after
every message you send only to tell you the archive-id is also not very
efficient.

All clients that implement MAM right now seem to be able to deal with the
few duplicates on catchup.

The new filter options are for the use case of fetching holes in your
history, not for catchup.

Regards
Philipp




Am Di., 12. Mai 2020 um 18:45 Uhr schrieb Michal Piotrowski <
michal.piotrow...@erlang-solutions.com>:

> Thanks for the reply Philipp. In that case I didn't understand the purpose
> of the new ways of fetching the archive as proposed by Matthew in
> https://github.com/xsf/xeps/pull/922 namly "before-id", "after-id", and
> "ids". I assumed that they operate not on the archive id provided by MAM
> but on the origin-id (or other id) provided by the user.
>
> If they operate on the archive id provided by MAM, I think we are still
> missing a simple way for the sender to sync the archive. The user sending
> the message, doesn't know the archive id of the just sent message unless it
> tries to read it from MAM. I can imagine a situation where a user sent many
> messages to someone else, there was no message back from the other user
> when the sender was online. The next time our sender connects and wants to
> sync MAM it has to either query it by timestamp or use last known archive
> id, which is from before the messages were sent.
>
> In other words, I think it'd be good if the sender could quickly learn
> what is the archive id for the message it just sent, or has the ability to
> query the archive based on origin-id.
>
> Best regards
> Michal Piotrowski
> Software Architect at https://www.erlang-solutions.com/
> email: michal.piotrow...@erlang-solutions.com
> skype: twitter/github/medium: michalwski
>
>
>
> On Tue, 12 May 2020 at 18:05, Philipp Hörist  wrote:
>
>> Hi,
>>
>> I think you misunderstand the XEP, MAM does not care about what IDs a
>> user adds, it certainly does not care about origin-id, or the message-id.
>>
>> The server itself generates a unique ID when receiving a message and this
>> ID is communicated via the stanza-id element for example in MUC Messages.
>>
>> Or if you fetch messages via MAM, in the result element id attribute.
>>
>> Regards
>> Philipp
>>
>> Am Di., 12. Mai 2020 um 17:44 Uhr schrieb Michal Piotrowski <
>> michal.piotrow...@erlang-solutions.com>:
>>
>>> One more question, probably more general. What would be the most desired
>>> server's behaviour when it observes that a user sent a message with a used
>>> UID? In my opinion, it be better to reject this new message with an
>>> existing UID, if so how to communicate that error back to the sender?
>>>
>>> Best regards
>>> Michal Piotrowski
>>> Software Architect at https://www.erlang-solutions.com/
>>> email: michal.piotrow...@erlang-solutions.com
>>> skype: twitter/github/medium: michalwski
>>>
>>>
>>>
>>> On Mon, 11 May 2020 at 10:22, Michal Piotrowski <
>>> michal.piotrow...@erlang-solutions.com> wrote:
>>>
>>>> Hi Matthew,
>>>>
>>>> Thanks for making the changes. I'm really in favour of them. I see
>>>> there was no update to the PRs nor here on the mailing list. What needs to
>>>> happen in order to proceed with these?
>>>>
>>>> Alos, I have a comment (or rather question) regarding the new way of
>>>> querying the archive based on message UIDs. I assume that by UID, you mean
>>>> the origin-id as set by the client sending the message. If so, it didn't
>>>> find it clearly stated in your proposed changes nor in the current
>>>> version of MAM XEP. If not origin-id is meant here, I'd like to know what
>>>> UID means in this context.
>>>>
>>>> Best regards
>>>> Michal Piotrowski
>>>> Software Architect at https://www.erlang-solutions.com/
>>>> email: michal.piotrow...@erlang-solutions.com
>>>> skype: twitter/github/medium: michalwski
>>>>
>>>>
>>>>
>>>> On Wed, 22 Apr 2020 at 13:17, Florian Schmaus  wrote:
>>>>
>>>>> On 4/22/20 12:07 PM,

Re: [Standards] XEP-0313: pending 0.7 update review

[Philipp Hörist]

Hi,

I think you misunderstand the XEP, MAM does not care about what IDs a user
adds, it certainly does not care about origin-id, or the message-id.

The server itself generates a unique ID when receiving a message and this
ID is communicated via the stanza-id element for example in MUC Messages.

Or if you fetch messages via MAM, in the result element id attribute.

Regards
Philipp

Am Di., 12. Mai 2020 um 17:44 Uhr schrieb Michal Piotrowski <
michal.piotrow...@erlang-solutions.com>:

> One more question, probably more general. What would be the most desired
> server's behaviour when it observes that a user sent a message with a used
> UID? In my opinion, it be better to reject this new message with an
> existing UID, if so how to communicate that error back to the sender?
>
> Best regards
> Michal Piotrowski
> Software Architect at https://www.erlang-solutions.com/
> email: michal.piotrow...@erlang-solutions.com
> skype: twitter/github/medium: michalwski
>
>
>
> On Mon, 11 May 2020 at 10:22, Michal Piotrowski <
> michal.piotrow...@erlang-solutions.com> wrote:
>
>> Hi Matthew,
>>
>> Thanks for making the changes. I'm really in favour of them. I see there
>> was no update to the PRs nor here on the mailing list. What needs to happen
>> in order to proceed with these?
>>
>> Alos, I have a comment (or rather question) regarding the new way of
>> querying the archive based on message UIDs. I assume that by UID, you mean
>> the origin-id as set by the client sending the message. If so, it didn't
>> find it clearly stated in your proposed changes nor in the current
>> version of MAM XEP. If not origin-id is meant here, I'd like to know what
>> UID means in this context.
>>
>> Best regards
>> Michal Piotrowski
>> Software Architect at https://www.erlang-solutions.com/
>> email: michal.piotrow...@erlang-solutions.com
>> skype: twitter/github/medium: michalwski
>>
>>
>>
>> On Wed, 22 Apr 2020 at 13:17, Florian Schmaus  wrote:
>>
>>> On 4/22/20 12:07 PM, Matthew Wild wrote:
>>> > On Tue, 21 Apr 2020 at 15:50, Florian Schmaus >> > > wrote:
>>> > On 4/21/20 2:32 PM, Dave Cridland wrote:> On Mon, 20 Apr 2020 at
>>> 16:20,
>>> > > You're going to hate me, but one more thing...
>>> > >
>>> > > Current MAM says that servers SHOULD include a count. The
>>> problem with
>>> > > this is that it's extremely slow on any system with more than
>>> trivial
>>> > > retention periods, since this tends to degenerate into either a
>>> > COUNT(*)
>>> > > SQL query (table-scan-tastic) or a standalone counter (which then
>>> > drifts
>>> > > and is a contention point).
>>> > >
>>> > > The majority of client libraries appear to ignore the count
>>> values
>>> > > anyway, as far as I can tell, so can we relax this to a MAY?
>>> (XEP-0059
>>> > > is MAY-but-only-if, which is arguably really a SHOULD anyway).
>>> >
>>> > I think such a relaxation would require a namespace bump.
>>> >
>>> > I'm not convinced. In any case, servers that already comply with the
>>> > SHOULD will probably continue to do so, new servers may be more likely
>>> > not to, but given that clients don't really use the (unreliable) info
>>> > today then I don't think we lose anything in practice.
>>>
>>> I could follow that argumentation in this case. It's probably just me,
>>> but I am very conservative when it comes to relaxations of keywords.
>>>
>>> - Florian
>>>
>>> ___
>>> Standards mailing list
>>> Info: https://mail.jabber.org/mailman/listinfo/standards
>>> Unsubscribe: standards-unsubscr...@xmpp.org
>>> ___
>>>
>>
> Code Sync & Erlang Solutions Conferences
> 
>
>
> Code BEAM Lite ITA - Bologna: Rescheduled
>
> Code BEAM STO - Stockholm: Rescheduled
>
> ElixirConf EU - Warsaw: 7-8 October 2020
>
> Code Mesh - London: 5-6 November 2020
>
>
> Erlang Solutions cares about your data and privacy; please find all
> details about the basis for communicating with you and the way we process
> your data in our Privacy Policy
> . You can update
> your email preferences or opt-out from receiving Marketing emails here
> 
> .
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313: pending 0.7 update review

[Philipp Hörist]

Hi,

Am Sa., 4. Apr. 2020 um 11:33 Uhr schrieb Ruslan N. Marchenko :

>
> Thanks, that makes perfect sense to me as in my limited _mere p2p
> conversation_ use case all those bells and whistles are rather confusing.
> I don't understand though the need of _flip-page_ element - the reverse
> _page_ order is achieved by  element (as specified here [1]). Is it
> to reverse _message_ order (contradicting to section Querying an archive)?
>
>
 gives you the last page in chronological order, there comes no
use case to mind where this is useful.

- Either i want to sync up, then i want them in chronological order, so i
dont use 
- Or i want to "backscroll" through history, then i want them in reversed
order which  and  now make possible


> * Communicating the archive ID: not sure how to formulate it but something
> along the lines: if client expects message synchronisation for outgoing
> messages it MUST add origin-ID to the sent message and store the ID locally
> for future synchronisation.
> * Business Rules -> Storage and Retrieval Rules -> User Archives : At a
> minimum, the server MUST store the  elements of a stanza. The
> server also MUST store origin-id element if that was supplied in outgoing
> message by archive owner.
>
>
Its not strictly needed that the archive preserves the origin-id, its not
even needed for deduplication that you use origin-id at all.
Whatever you put now in origin-id, just put into the standard message-id
attribute. message-id attribute is already preserved by servers.

I think the use for origin-id was historically because not all MUC
implementations did preserve the message-id or were allowed to rewrite it.
But this has been fixed in 0045 since then if im not wrong

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

Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts

[Philipp Hörist]

Am Di., 3. März 2020 um 21:19 Uhr schrieb Andrew Nenakhov <
andrew.nenak...@redsolution.com>:

>
> I think this XEP should be obsoleted in favour of XEP-0333 Chat
> Markers, which does all that XEP-0184 does, plus something more.
>
>
Why would someone depreacte a spec that is implemented in nearly every
client in existence, for something that does, best case, exactly the same?

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

Re: [Standards] Offline Feature Negotiation and Device Lists

[Philipp Hörist]

Hi,

Am Mo., 17. Feb. 2020 um 12:12 Uhr schrieb Ralph Meijer :

>
> One thing I'm concerned about in general is what happens if I start
> sending presence to my contacts. I would get a PEP notification for each
> of my contacts with their capabilities. Bandwidth-wise having hashes
> here helps, but still it is a lot of traffic. Especially for mobile
> uses, it might be better to retrieve this information incrementally,
> through regular disco or perhaps a new IQ-get exchange for CAPS hash sets.
>

Yes im also concerned about this. Putting stuff into PEP and using +notify
is convenient.

But it clearly does not scale well at all.

You might be ok for 20-30 contacts but not for 300

Just from the top of my head

UserAvatar
UserMood
UserTune
UserNick
UserLocation
UserActivity
OMEMO
OpenPGP

I'm sure there are even more.

This will soon reach an amount where a client simply can't implement these
XEPs because of performance reasons.
At some point we should make this scaleable.

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

Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS

[Philipp Hörist]

>
> 1. What software has XEP-0368 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.
>

Gajim / nbxmpp


>
> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0368? If so, please describe the problems and, if
> possible, suggested solutions.
>

Mixing DIRECT and START TLS is problematic i guess its not supported by any
library that offers some kind of abstraction over sockets.

For example in GLib you can connect to a SRV record, GLib resolves the SRV
record mixes it and does happy eyeballs to connect to the address.
If i have to mix i cant use this, i have to write my own resolver code, i
have to wait on 2 SRV records to finish, and have to mix myself.
Its unreasonable to ask libs to implement such a behavior, seems quite
unique to mix different SRV records.

The benefit is not really clear, Applications would want to favor Direct
TLS its less roundtrips. We are treating something the same which is not
the same. And one has a clear benefit.

This rule will most likely be ignored by clients.


> 3. Is the text of XEP-0368 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.
>

Remove the mixing of SRV records

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

Re: [Standards] LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))

[Philipp Hörist]

> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>

Yes


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>

It solves the problem described and introduces a new problem.
Migration to this standard is not possible without data loss.
It removed the  element without any explanation.
Clients who migrate to this standard have no standard way to sync passwords
across devices.
I'm not sure what the thought process was here, the password of the MUC is
known to the server anyway, it does not matter if its stored in a second
place on the same server.

3. Do you plan to implement this specification in your code? If not,
> why not?
>

I have implemented behind a development flag, but im not sure i want to
really migrate to this standard for reasons described above


> 4. Do you have any security concerns related to this specification?
>

No


> 5. Is the specification accurate and clearly written?
>

Yes


> Your feedback is appreciated!
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]

[Philipp Hörist]

Hi,

What I talked about when i said it's impossible is not about the Crypto.
It's the wire format that is not documented to my knowledge. And without
that you can't make OMEMO work.
The wireformat can only be looked up in the source code. If you want to use
a GPL incompatible license then this would be a problem.

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

Re: [Standards] Proposed XMPP Extension: Ephemeral Messages

[Philipp Hörist]

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 SignalProtocol. The XEP says

> The signal protocol currently only exists in GPLv3-licensed
implementations maintained by OpenWhisperSystems.

So it means, you use the libraries OpenWhisperSystems currently offers and
if you want to know what they do you read the docs on their page.

I know this is not a beautiful thing in Standards world, but that's what it
is at the moment.

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

Re: [Standards] Proposed XMPP Extension: Ephemeral Messages

[Philipp Hörist]

Hi,

> 4.5 Exchanging Ephemeral OMEMO Messages
> OMEMO requires that messages are delivered in a sequence. If a message is
missing, all the following messages cannot be decrypted and a new session
has to be established.

This is wrong, OMEMO can well deal with missing messages, this and all
subsequent points that build on that assumption should be removed from the
XEP

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

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Philipp Hörist]

Am Sa., 21. Dez. 2019 um 11:39 Uhr schrieb Andrew Nenakhov <
andrew.nenak...@redsolution.com>:

>
> We assumed as much but weren't sure. Anyway, Marvin had sent a malformed
> stanza, which was corrected (escaped) by the server. Next, a client that
> counted characters in a different way than he did (which was known
> beforehand) counted them differently.  Next he complains he didn't get the
> result he expected.
>
> The only thing I'm surprised is that the server didn't just drop the
> connection, as it does when receiving unescaped < symbols
>
>
I think you misunderstood the RFC, it's not a violation to send ">"
unescaped.

> The right angle bracket (>) *may *be represented using the string " >
", and *MUST*, for compatibility ,
be escaped using either " > " or a character reference *when *it appears
in the string " ]]> " in content, when that string is not marking the end
of a CDATA section .


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

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Philipp Hörist]

Am Mi., 18. Dez. 2019 um 12:02 Uhr schrieb Florian Schmaus :

> I do like to point out that it is probably not really XMPP specific
> (similar to XEP-0392: Consistent Color Generation), but I don't see a
> reason why this shouldn't get XEP'ed up.
>
>
I don't see the similarities, one is a pure UI suggestion (XEP-0392), has
nothing to do with the protocol layer.
The other XEP (Message Counting) tells you how to generate information
which you have to transfer via xmpp to other entities.

One has no impact whatsoever on interoperability.
Without the other there is simply no interoperability.

Not sure what you mean by XMPP specific, yeah im sure other things in this
world also count characters for something, but that does still leave us
with the responsibility to define how XMPP wants to do it.

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

[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

[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] Bookmarks 2 extensibility

[Philipp Hörist]

> On Mon, 25 Nov 2019 at 12:26, Jonas Schäfer  wrote:
>
>> The only thing I wonder is: Why an extra sub-element? This reminds me of
>> the
>> `X-` prefix which has since been deprecated. We *do* have namespacing in
>> XML,
>> let’s make use of that. Simply state that all unknown child elements of
>> the
>> <{bookmarks:0}conference/> element must be preserved; no need to stuff it
>> away
>> in an extra element.
>>
>
>
>From a programming perspective I would argue that storing one element away
is much less work than searching for all unknown child elements.

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

Re: [Standards] Support for stickers (custom emojis)

[Philipp Hörist]

Just make a HTTP HEAD request, look how big the content is then start to
download.

This is not a problem specific of stickers, you have that problem always
when you want to download data, potentially the data can always be big.

or you add an attribute size, and trust the sending client.

regards
Philipp

Am Do., 17. Okt. 2019 um 12:10 Uhr schrieb JC Brand :

> Hello
>
> I'm currently working on adding support for non-unicode emojis to
> Converse.js.
>
> Currently, users can't upload their own images to be used for custom
> emojis,
> mostly because Converse is a thin client with no backend support for it.
>
> So to add custom emojis, the web host needs to edit a emojis.json file
> to add new entries with URLs pointing to the actual images.
>
> Concerning compatibility with other clients, I've discussed it with edhelas
> and he told me he uses XEP-0231 BOB for sending stickers.
>
> There are a few reasons why I'm not keen on using BOB:
>
> - BOB depends on XHTML-IM which is deprecated. Converse.js doesn't support
> it
>   and I'm reluctant to add support just for this.
> - BOB mentions that binary data should be smaller than 1KB. Not sure how
>   relevant that still is, but it discourages me from sending larger
> amounts.
> - The sending client needs to maintain a cache of all sent stickers.
> - AFAICT, when receiving an uncached BOB message via MAM and the sending
> client
>   is offline, then you can't get the image data.
>
> Instead, I propose that we use XEP-0372 references to indicate that a
> particular shortname (e.g. :dancingpanda:) should be replaced with an
> image.
>
> For example:
>
>  I feel like dancing! :dancingpanda:
>  begin="21"
> end="35"
> type="data"
> uri="https://images.com/dancingpanda"/>
> 
>
> I'm not sure whether "type" should be "data", seems a bit too generic for
> me,
> perhaps it could be something else?
>
> Some criticisms of this approach from edhelas:
>
> - HTTP images can be sent to a webchat client served over HTTPS
> - There's no size limit, so users can send links to very large stickers
>
> Concerning the first criticism, a client can choose to not render HTTP
> images inline and instead make the shortname a link which opens the image
> in a
> new tab. Not ideal, but a compromise for the privacy and security
> conscious.
>
> For the second I don't have a good answer.
>
> That said, I currently still prefer my suggestion to using BOB. I'd be
> interested to hear your feedback and suggestions.
>
> Regards
> JC
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0060: max-items (publish-options et al) council action required

[Philipp Hörist]

Hi,

I think Daniel meant, whatever the servers max limit is.
For bookmarks to work i dont need to know what the max limit of the server
is.
If its 1, then so be it, you will never have more than one bookmark, fix
your server.

I also dont need to know what the storage capacity of MAM is, or how much
files i can upload before they are getting deleted.
Yes if a server has a limit on storage capacity at the end data is lost at
one point, but i dont think a client should monitor that.

Point here is, if there is no "whatever the max limit is" option, then
every client is forced to set a arbitrary value for max-items. This means
the node gets reconfigured on most pushes in a multi device setup.

regards
Philipp

Am So., 6. Okt. 2019 um 13:20 Uhr schrieb Maxime Buquet :

> On 2019/10/06, Daniel Gultsch wrote:
> > Therefor I propose wording for XEP60 that 'clarifies' that max-items 0
> > means unlimited.
>
> Is there a way to know as a client when we're going to run into the
> limit? Or when we've gone over the limit? Or is the pubsub service just
> overwritting stuff and nobody ever noticies?
>
> --
> Maxime “pep” Buquet
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] PupSub max_items field has no "max" value

[Philipp Hörist]

Hi,

There is currently no value that says make it the maximum the server
supports.

This causes some problems, for example when we want to store bookmarks in
different items like in XEP-0402 proposed.

Default on most servers is max_items=1. So first i try with publish options
and already here its not clear what value i should set for max_items. There
is no way to discover what the amount the server supports is, so i take an
arbitrary number i think is good.

But a different client might think another number is better, so on each
publish each client pulls the node configuration and reconfigures the node
to whatever value he finds useful.

This looks like a bad process. Usually i want to conifgure a node once, and
not every few days because another client thinks a different config is
better.

Writing max_items down in the XEP is also not optiimal. We run into the
same problem if we later change the number in the XEP. Older clients will
configure the node always back to where it was.

I see the same problem with item_expiry, if a server supports that suddenly
it gets impossible to have a item not expire.

Now we could imagine setting the value to 0 means forever or max. But i
didnt find this documented anywhere.

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

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Philipp Hörist]

Examples are not normative, the XEP does not limit the message type to
anything specific. So every developer can decide if he wants it carbon
copied or not.

If you fear this is missed by implementors, a hint in the implementation
notes is probably enough.

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

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Philipp Hörist]

Am Do., 5. Sept. 2019 um 12:36 Uhr schrieb Ruslan N. Marchenko :

>
> > And in 0353 messages are body-less hence not
> eligible for carbons.
>
>
bodyless is eligible for carbons if the message is of type "chat". We use
this on many XEPs, receipts, all encrypted messages, markers, chatstates
etc
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Reactions

[Philipp Hörist]

Am Mi., 31. Juli 2019 um 18:20 Uhr schrieb Ненахов Андрей <
andrew.nenak...@redsolution.ru>:

> The fallback to message reactions is no reactions. If a user is using
> a legacy client, message reactions will likely flood his messenger.
> Fallback *could* be done via quote of a previous message an appended
> reaction symbol. But it should not be done at all.
>

+1

People who prefer fallback messages here should be aware that this could
lead to legacy clients beeing unusable because of reaction message spam in
MUCs
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Anonymous unique occupant identifiers for MUCs

[Philipp Hörist]

Ah i get it, you could with brute force just try to hash JIDs and
deanonymize the participants.

Philipp

Am Di., 16. Juli 2019 um 22:47 Uhr schrieb Philipp Hörist <
phil...@hoerist.com>:

> Hi,
>
> Yes looks useful, although i would say lets not turn it into something it
> does not try to be. (Making MUCs more anonym)
>
> What i wonder is though how servers calculate the id, why use a random
> seed? why not just a hash of some unique strings, like MUC JID + user jid.
>
> Randomness would only introduce the problem that if the server storage is
> lost somehow and new setup that IDs are not the same anymore.
> But maybe i dont see how a random seed improves something here
>
> Regards
> Philipp
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Anonymous unique occupant identifiers for MUCs

[Philipp Hörist]

Hi,

Yes looks useful, although i would say lets not turn it into something it
does not try to be. (Making MUCs more anonym)

What i wonder is though how servers calculate the id, why use a random
seed? why not just a hash of some unique strings, like MUC JID + user jid.

Randomness would only introduce the problem that if the server storage is
lost somehow and new setup that IDs are not the same anymore.
But maybe i dont see how a random seed improves something here

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

Re: [Standards] Leading and trailing spaces in resourceparts

[Philipp Hörist]

Hi,

Thanks, next time i will read also the errata :)

Regards
Philipp

Am So., 30. Juni 2019 um 21:44 Uhr schrieb Sam Whited :

> On Sun, Jun 30, 2019, at 19:12, Philipp Hörist wrote:
> > I tried to test against the examples in
> > https://tools.ietf.org/html/rfc7622#section-3.5
> > and found that my tests fail for the example 
> > The document goes on mentioning the JID beeing illegal because leading
> > spaces are illegal.
>
> This is a verified problem, see errata 4560:
>
> https://www.rfc-editor.org/errata/eid4560
>
> —Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Leading and trailing spaces in resourceparts

[Philipp Hörist]

Hi,

I tried to test against the examples in
https://tools.ietf.org/html/rfc7622#section-3.5
and found that my tests fail for the example 
The document goes on mentioning the JID beeing illegal because leading
spaces are illegal.

My question is rather simple, where is this rule documented?

rfc7622 mandates to apply the PRECIS-OpaqueString profile to resources,
which does not enforce a mapping for spaces to none at start and end.

There is a PRECIS-Nickname profile which does, but its not mentioned in the
document.

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

Re: [Standards] Proposed XMPP Extension: Stanza Content Encryption

[Philipp Hörist]

Hi,

I think it would be good to concentrate on the task that this XEP wants to
solve (its hard enough), and not invent new ones.

- No this XEP should not invent a new 0030
- No this XEP should not improve/destroy current crypto mechanics by adding
various information's into the payload. If you feel this is necessary
update the corresponding crypto XEP.

This XEP should be a simple standard that tells developers what content to
expect when decrypting a full stanza payload, and what to put into when
encrypting. Nothing more.

Regards
Philipp

Am Mo., 24. Juni 2019 um 23:38 Uhr schrieb Maxime Buquet :

> On 2019/06/24, Dave Cridland wrote:
> > On Mon, 24 Jun 2019 at 20:11, Paul Schaub  wrote:
> > > Am 24.06.19 um 19:04 schrieb Ненахов Андрей:
> > > > So much for deniability.
> > >
> > > Yeah, I'd rather keep it flexible and let the encryption XEP which
> > > defines a SCE profile decide, which fields to use and not to use. OX
> for
> > > instance should probably use the "full stack" of affix elements, while
> > > OTR would stay away from most of them (except maybe timestamp).
> > >
> > I would rather everything used the same.
>
> I think the point of this XEP is to enforce only meaning of elements it
> provides for other XEPs to use.
>
> As Paul said, I also think profiles of this XEP (other XEPs reusing SCE)
> should define how these elements are used. Somebody might come up with
> an encryption mechanism that doesn't fit our model of REQUIRED elements.
>
> --
> Maxime “pep” Buquet
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0191 leads to stale presence?

[Philipp Hörist]

Hi,

The section means, my server sends my presence to the now unblocked
contact. Yes this would look like im coming online to the contact.
But this does not solves the problem that i dont have current presence
information about the unblocked contact.
The server sending my presence to the contact does not lead to getting
up-to-date presence information of the contact back.

So if you follow the XEP, you end up with stale presence of the unblocked
contact.

Regards
Philipp

Am Sa., 22. Juni 2019 um 01:16 Uhr schrieb Tedd Sterr :

> *mea culpa*
>
> So, section 3.4 User Unblocks JID, paragraph last-1:
>
> *"When the user unblocks communications with a JID, the user's server MUST
> send the user's current presence information to the JID (but only if the
> JID is allowed to receive presence notifications from the user in
> accordance with the rules defined in RFC 3921)."*
>
> It doesn't explicitly say to probe, but 'current presence' should imply
> sending one if necessary..? It would be the same as initially coming online.
>
> Though there's nothing wrong with being more explicit.
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0191 leads to stale presence?

[Philipp Hörist]

I think you misunderstood what Kim meant.

Its about unblocking, so you are obviously again interested in presence,
the XEP does not mention the client or server should send a probe because
the presence is stale

regards
Philipp

Am Fr., 21. Juni 2019 um 22:57 Uhr schrieb Tedd Sterr :

> If you block a contact, presumably that means you don't want them to see
> your presence and you're not interested in theirs.
> In that case, presence going stale is unimportant (shouldn't be shown
> anyway?), and any kind of probes would be considered a leak.
>
> There may be a small case for still viewing their presence for spying
> purposes, but I'm not sure it's worth the extra complication.
>
> [Possibly worth contrasting with XEP-0186 (Invisible Command) where you
> would still want to view presence.]
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Stanza Content Encryption

[Philipp Hörist]

Hi,

Im not quite sure what you want to negotiate, but making any part of the
encryption process depending on disco info of a online resource is a fail.

Feature negotiation in encryption process is a fail in General. Its simply
not needed, we have 2 encryption methods right now (OMEMO and PGP) that
dont depend on any kind of negotiation and this works fine. One of them
even having full stanza encryption.

The whole encryption process must be possible while the recipient is
offline, for the whole process. Feature negotiations also imply that there
are multiple features to handle differently which makes implementation more
complicated. You have to think about multiple resources online which would
support different kind of features, and other resources offline where you
dont even know the features, this is a nightmare i would not even start to
implement.

Regards
Philipp





Am Di., 18. Juni 2019 um 10:38 Uhr schrieb Paul Schaub <
vanitasvi...@fsfe.org>:

> Hi Florian!
>
> Am 17.06.19 um 17:58 schrieb Florian Schmaus:
> > On 15.05.19 16:53, Paul Schaub wrote:
> >> Thank you very much for your eager interest and numerous replies
> >> *cough*, in other words, Thank you Florian for your reply :D
> >>
> >> I'm not quite sure, how exactly the process of negotiating expected
> >> encrypted elements would look like.
> > XEP-0030 features mostly.
> >
> >> I can see that this would
> >> make it easier for adopters to gradually start implementing support for
> >> one feature at a time (like start with support for  encryption
> >> and then successively add support for other elements as well), but at
> >> the same time I feel like this could enable "downgrade" attacks and
> >> would diminish the "encrypt *all* the sensitive things"-approach that I
> >> aim for.
> > The fact that you can gradual start implementing it is just one of the
> > advantages. Another major advantage is that we can start implementing
> > it *right now*.
> >
> > I can not stress the "get it implemented right now" as advantage
> > enough. For one, it allows us to get implementation experience early,
> > which is something other E2EE approaches did not, which contributed to
> > their failure. But more importantly, we are able to reduce the
> > percentage of unencrypted plaintext, which is still to high at the
> > moment.
> >
> > After we have secured plaintext, we can take the next step and look
> > into securing metadata. But one step after another. I want to raise
> > the floor for privacy first, and then the ceiling. There is no reason
> > why we should try to tackle everything in one rush (thanks to XMPPs
> > extensiblity property). In fact, I believe this is actually harmful
> > because it prevents us from deloying privacy solutions because of
> > endless discussions, while there is still plaintext on the wire.
> >
> > Let us start with getting rid of unencrypted messages first, and then
> > we can focus on the metadata. We certainly should keep downgrade
> > attacks in mind, but I don't believe that this is an argument against.
>
> Fair points. I will look into XEP-0030 then to figure out how one could
> implement the feature negotiation.
>
> >
> >> An alternative approach that some people suggested would be to replace
> >> the envelopes content element with a normal message stanza. That way
> >> implementations could simply decrypt that stanza, check it for forbidden
> >> elements and remove those and then feed the cleaned stanza back into the
> >> XML stream. That way the client wouldn't have to reimplement listeners
> >> for all the events. On the other hand, the client would probably want to
> >> somehow mark the decrypted stanza as end-to-end encrypted.
> > Injecting stanzas that where never send by the server into the clients
> > processing chain is an approach that is sometimes mentioned. It may
> > appears to be a nifty trick at first, but I believe this is not an
> > good idea for the following reasons:
> >
> > First, your premise that the client would not have to reimplement
> > listeners is wrong. You still want to carry around the information
> > that the data was protected by some mechanism, as you need to pass
> > that information up to the application. Otherwhise the application can
> > not tell the difference between a protected chat state and an
> > unprotected one.
> >
> > Let's take Chat State Notifications (CSN, xep85) for example. A library
> may
> > implement a listener/callback/hook once such a notificaiton arrives
> > that looks like this:
> >
> > chatStateChange(Chat chat, ChatState chatState, Message message)
> >
> > Now with protected CSNs you most certainly want to extend the callback
> > with the information wheter or not the CSN was protected or not:
> >
> > chatStateChange(Chat chat, ChatState chatState, Message message,
> > SecurityInformation securityInformation)
> >
> > Which allows the user to retrieve the information about the used
> > encryption protocol, if any, from the SecurityInformatio

Re: [Standards] Whitespace "ping"

[Philipp Hörist]

Hi,

So what is the best practice as a desktop client? As i also currently
review the whitespace sending code.

Is every 10 seconds too much?

regards
Philipp

Am Di., 11. Juni 2019 um 14:38 Uhr schrieb Mickaël Rémond <
mrem...@process-one.net>:

> Thanks :)
> I do not have a strong opinion regarding the "need", it was more a way to
> explain what I was trying to achieve with that idea.
> I am working on a client library these days and I am trying to be widely
> compliant and try to adapt to the server policy regarding whitespace
> keep-alive.
> I can easily live with "best practices" instead of "standards" and
> hardcode a few values in my lib.
>
> Cheers,
>
> --
> Mickaël Rémond
>
>
> On 11 Jun 2019, at 14:31, Guus der Kinderen 
> wrote:
>
> I'd have to check, but I think we're sending a IQ Ping when the client
> misses it's first white space ping interval (whatever we deem is
> appropriate in that server config), and define the client to be
> disconnected when it doesn't respond in a timely manner. This covers both
> of your "the client is being silly" scenario's: to many whitespace pings
> aren't adding much overhead to the server, while to few pings are covered
> by the IQ Ping. I agree with you that it's all very unspecified, which
> could be improved on. I'm not seeing much of a direct  _need_ to do that,
> but I'd not oppose it either.
>
> On Tue, 11 Jun 2019 at 14:24, Mickaël Rémond 
> wrote:
>
>> Hello Guus,
>>
>> On 11 Jun 2019, at 14:00, Guus der Kinderen 
>> wrote:
>>
>> What we need basically is a way to negotiate the interval with server
>>
>>
>> I'm not sure if this is _needed_? Without this being a requirement, much
>> of the complexity of "making this more standard" falls away.
>>
>>
>> Well, I think if the server does not have to approve the value, client
>> could expect to set it to something extreme (like 1s) or useless (like 1
>> days). The server could thus reply with a different value. And still the
>> server needs to know at which rate the client is expected to send the keep
>> alive.
>> But, yes, it is always possible to do something like that in a non
>> standard way. My point was trying to agree on something to make life of
>> client developers easier :)
>>
>> A server could, before determining that a connection is lost, attempt to
>> send any IQ stanza (PING is an obvious choice, but any query will do). As
>> the client is obliged to respond, if anything with an error, the server
>> knows if the connection is, in fact, lost.
>>
>>
>> What would be the trigger for determining that the connection is lost and
>> send the ping? Is it whitespace keep-alive or anything else?
>>
>> Thanks!
>>
>> --
>> Mickaël Rémond
>>
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Stanza Content Encryption

[Philipp Hörist]

Hi,

> Within the IEEE IoT Harmonization effort, there is a mechanism to
E2E-encrypt stanzas in XMPP:

> https://gitlab.com/IEEE-SA/XMPPI/IoT/blob/master/E2E.md


This seems targeted specifically to IoT which seem to have different needs


Just two points from this document that i see completely fail for the IM
use case


1. Exchanging Public Keys with presence

2. Encrypting all nodes inside message and iq


Stuff that we need to decide has not much to do with the encryption, like


1. What nodes should *not* be encrypted, which should be encrypted

2. What should i do if i find nodes outside of the encrypted container and
inside of the encrypted payload (after decrypting) which wins?

3. Maybe a blacklist/whitelist of nodes for 2.


regards

Philipp



Am Mo., 1. Apr. 2019 um 13:53 Uhr schrieb Dave Cridland :

> Why is the IEEE working on this? Surely it would be considerably more
> productive just to ask the XSF (or even the IETF, I can see arguments for
> both) about the problem?
>
> On Mon, 1 Apr 2019 at 10:51, Peter Waher  wrote:
>
>> Hello Paul, and those in the community interested in end-to-end
>> encryption of stanzas.
>>
>>
>>
>> Within the IEEE IoT Harmonization effort, there is a mechanism to
>> E2E-encrypt stanzas in XMPP:
>>
>> https://gitlab.com/IEEE-SA/XMPPI/IoT/blob/master/E2E.md
>>
>>
>>
>> Site for the IEEE IoT Harmonization project:
>>
>> https://gitlab.com/IEEE-SA/XMPPI/IoT
>>
>>
>>
>> Best regards,
>>
>> Peter Waher
>>
>>
>>
>> --
>>
>> > Hi everyone!
>> >
>> > The Sprint in Berlin was great and it was huge fun meeting so many
>> > developers (and users as well!) in person. There was a ton of
>> > interesting discussions around OMEMO and other stuff, as well as some
>> > productive coding (and Mate!).
>> >
>> > I took the opportunity to once again start a discussion around partial
>> > stanza encryption. The results have been collected in the XMPP wiki:
>> >
>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.xmpp.org%2Fweb%2FStanza_encryption&data=02%>
>>
>> 7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065421995310&sdata=YqVBLurjKA1xIqjIMqKweWXhm6hhk%2F7cdLfpwkiyOjg%3D&reserved=0
>> 
>> >
>> > The ultimate goal is to create a ProtoXEP along with some experimental
>> > implementations, so we can finally start to gather some experience on
>> > this unexplored topic. I know there be dragons and we should carefully
>> > think about rules to prevent evil things from happening, but we also
>> > have to get started, as I think this topic has been postponed for all
>> > too long.
>> >
>> > The specification is worked on on Github and a rendered version can be
>> > found below (this is all what I came up with while on my train home).
>> > The purpose of this mail is to get some first feedback and make people
>> > aware about the work, so they can get involved in the process :)
>> >
>> >
>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvanitasvitae%2Fflowdalic-xeps%2Ftree%2Fsce&data=02%7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065421995310&sdata=T61uPbN2631En4SqdiDMW2Gwk5pfgrCxZXFmFxHpt%2Bg%3D&reserved=0
>>
>> https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgeekplace.eu%2Fxeps%2Fxep-sce%2Fxep-sce.html&data=02%7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065422005321&sdata=3BvePHpJPZICLrqxlfiRW7sCL0EwLRov%2FEc6l5i%2Bkic%3D&reserved=0
>> >
>> > I also created a small MUC on the topic, although the address is not
>> > final, as I may move the conversation to a more stable server (mine is
>> > hosted behind dyndns, so Schroedingers Chat might kick in :/).
>> >
>> > xmpp:s...@conference.jabberhead.tk?join
>> >
>> > Happy Hacking!
>>
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[Philipp Hörist]

Am Do., 28. März 2019 um 09:48 Uhr schrieb Dave Cridland :

>
> 3) I don't think Andrew's assertion that our current (partial?) solutions
> for his requirements are an overlapping mess ought to be discarded out of
> hand. Cleaning these things up might make a lot of sense.
>
>
I dont see an overlapping mess.

We have an old deferred standard IM-XHTML -> We have a potential new
approach XEP-0394
We have an old insufficient way to send media OOB -> We have a potential
new sufficient approach SIMS  (There will always be one more missing attr
that could potentially be useful in a media transfer so i ignore the fact
that Andrew wants to transfer seconds of a audio file, this is easily added)

There is a "lets document the client praxis" kind of XEP-0393 which states
some easy markdown syntax that may be encountered when using XMPP. I see
this as a sort of document where developers can look up some easy markup
stuff that some clients use. I dont see this as a serious approach to solve
all markup needs of XMPP and i dont think it should be further extended.
Yet people will probably use it because they know the syntax from other
IM-Apps. But i dont see this XEP in opposition to any other XEP.

I saw no arguments against 0394 and its approach, as i see it perfectly
fits Andrews usecases.
I dont see that there is a need to enclose each markup element into
reference elements just for the sake of consistency. This would lead to
some horrible inefficient syntax. I think developers can deal with the
syntax that is described in 0394, they will not give up because they dont
find a reference element.

Whats missing from SIMS except some useful attrs?


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

Re: [Standards] One true final way to mark up messages

[Philipp Hörist]

Hi,

you try to do what 0394 does, but your syntax is way more bloated and i
dont see any value added, so why not just use 0394?
ah yes because you seem to think adoption is better if you stuff everything
into one XEP. I disagree, in fact i think it has no effect on adoption at
all.
Implementing "bold" or "italic" in a client is probably 2 hours work,
displaying an audio or video player inside your chat window, ranges
depending on your OS and GUI Framework from many days work to almost
impossible.

For media transfers there is also already SIMS, where is the added value?

I can see that it makes sense to have a place where it is described how
everything is tied together, but this does not have to be a XEP, the XEP is
only the protocol what is put on the wire, if you put everything into one
XEP it does not help a developer in any way to develop a nice looking, good
working GUI. (Thats the actual work)

Parsing the information out of the xml is not the problem, stuffing
everything into references makes it not even 1% easier to implement all
that stuff.

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

Re: [Standards] XEP-0313 / XEP-0359 interaction

[Philipp Hörist]

Hi,

There is no loss in semantic, the XEP states

>  The 'by' attribute MUST be set to the address of the archive.

so its clear to every client developer at any point in time, what message
was archived by the server, and on what message some user or server just
added another  element.

Further 0359 states

> Stanza ID generating entities, which encounter a  element
where the 'by' attribute matches the 'by' attribute they would otherwise
set, MUST delete that element even if they are not adding their own stanza
ID.

So i would say this is as save as it gets, and only misbehaving clients or
server will have problems.

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

Re: [Standards] Proposed XMPP Extension: DNS Queries over XMPP (DoX)

[Philipp Hörist]

Whats the use case for this XEP?
Until now i only needed DNS querys to connect to the XMPP Server, i see
this XEP is not helping with that as it already needs an active connection
to the XMPP Server.

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

Re: [Standards] Is the World Ready for Compliance Suites 2019?

[Philipp Hörist]

Hi,

I think there is some confusion about the use of 0066. We do not
communicate that an image should be shown inline. It is a hacky way of
communicating that the URL links to a file that was specifically uploaded
by a user, or a user wants to share.

This is so clients can differentiate between random links a user found on
the internet and posts into a chat and uploaded content from the user. The
first could lead to users accidentally sending dangerous files to their
contacts if we automatically download it and show it inline.

So we add a oob tag to the message to tell other clients this file was
uploaded by the user (or a deliberate action to share some content) and not
some copy paste link.
If the client acts on this information differently is up to the client.

So because we make uploads known with 0066 (Which is what this XEP is for
to deliberately share a URL), we have to also think about clients not
supporting 0066 and that leads to putting the url also into the body.

385 adds more metadata than 0066, but other than that it does exactly the
same.

regards
Philipp

Am Do., 7. März 2019 um 08:07 Uhr schrieb Timothée Jaussoin <
edhe...@movim.eu>:

> What about using a proper XEP like SIMS (
> https://xmpp.org/extensions/xep-0385.html) for that case?
>
> This look like a hack to me.
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SCRAM interoperability

[Philipp Hörist]

But thats really little gain, with basically everyone knowing how bad it is
to use the same password on different services, and it feels like it would
not really be something the client dev could be blamed for.

Am Do., 24. Jan. 2019 um 19:33 Uhr schrieb Jonas Schäfer <
jo...@wielicki.name>:

> On Donnerstag, 24. Januar 2019 19:07:09 CET Philipp Hörist wrote:
> > Hm yes you are right, never thought that through as it seems.
> >
> > But does it really help not saving the pass on the client, what do i save
> > instead? the challenge i send? if this is aquired by an attacker he can
> > still access my account.
>
> But not any other account where you used the same password, as the salt is
> (hopefully) unique.
>
> kind regards,
> Jonas___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SCRAM interoperability

[Philipp Hörist]

Hm yes you are right, never thought that through as it seems.

But does it really help not saving the pass on the client, what do i save
instead? the challenge i send? if this is aquired by an attacker he can
still access my account.

regards

Am Do., 24. Jan. 2019 um 16:01 Uhr schrieb Sam Whited :

> On Thu, Jan 24, 2019, at 15:55, Philipp Hörist wrote:
> > SCRAM is not a mechanism to hide the password from the server
> > operator. Its a mechanism to make it possible for the server operator
> > to NOT store the password after getting it.
>
> This is also easily accomplished with PLAIN. PLAIN also makes upgrading
> the password storage mechanism much more agile so it's probably safer
> for most use cases.
>
> That being said, it does require that you store the password on the
> client (unless you want the user to enter it every time), so I see that
> as the primary benefit of using SCRAM, not stopping the server operator
> from having to store it.
>
> —Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SCRAM interoperability

[Philipp Hörist]

SCRAM is not a mechanism to hide the password from the server operator.
Its a mechanism to make it possible for the server operator to NOT store
the password after getting it.

Regards
Philipp

Am Do., 24. Jan. 2019 um 16:51 Uhr schrieb Evgeny :

> On Thu, Jan 24, 2019 at 6:39 PM, Florian Schmaus 
> wrote:
> > I am not sure if the XSF is the right venue
>
> Well, some people cite RFC 6120, as I understand, section 13.8.1,
> which requires, among others, to support SCRAM-SHA1-PLUS. So
> XSF responsibility cannot be completely ruled out.
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SCRAM interoperability

[Philipp Hörist]

Hi,

You get the password in plain at the point when the user creates the
account. Then you save it in 1 and 256.

If your question is that this is not possible anymore for people that
created their account when you only offered SHA1. Yes there is no way
around it, you cant migrate these users, they have to reset the
password.

I guess you think about only using 256 for new users, old users fail,
try another mechanism and succeed. This is tricky i guess. There is
nothing mentioned on how many times a client should try another
mechanism or if it should at all.
Scram makes it possible that a client can, but for example Gajim will
not try another mechanism right now, but only because i didnt saw a
reason how this could be a benefit other than hiding server
implementation errors.

If i were a server dev, i would probably chose to only use 256 in
completely new setups, or if the operator is willing to reset all
passwords.

Especially in the light that its not clear if SHA256 is really a
worthy gain over SHA1 in the context of SCRAM.

regards
Philipp

2019-01-24 16:20 GMT+01:00, Evgeny :
> On Thu, Jan 24, 2019 at 6:11 PM, Florian Schmaus 
> wrote:
>> Then you can't authenticate unless the server also stores the
>> authentication data for SCRAM-SHA1. I guess that is your point. What
>> is
>> wrong with the server storing the required data to authenticate
>> clients
>> with eg. SCRAM-SHA1 or SCRAM-SHA256 (besides the implementation
>> overhead
>> argument)? Maybe I am missing something?
>
> I am not sure what you mean. I can only do that on the server
> if I get plain password from the client which is something SCRAM
> was designed to prevent if I understand it correctly.
> Also, the problem still remains with upgrading existing
> SHA-1 to SHA-256/384/512/whatever and if I don't upgrade it there
> is possibility to create interop problem again, unless a client
> 1) supports all previous SHA versions
> 2) doesn't treat previous SHA versions as a downgrade attack
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0292: vCard4 - advance?

[Philipp Hörist]

Hi,

Ok didnt read into the context, yes single node is obviously not an option.
But for this use case random id is even worse. Maybe we can get this little
change in it before Last Call.

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

Re: [Standards] XEP-0292: vCard4 - advance?

[Philipp Hörist]

Only thing i would change is this sentence

> When a client stores items at this node, it SHOULD NOT include an ItemID,
so that the pubsub service can assign those identifiers.

Maybe i dont understand why this was written but it seems unnecessary to me.
It should be the implementors choice if it stores the data in a way that
allows to pull all changes to the vcard since first publish, or use a
singleton node item id "current".

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

Re: [Standards] Tidying Deferred

[Philipp Hörist]

Hi,

I think moving a XEP out of Deferred just because someone asks the editor
to do it (because someone cares but not the Author) seems like just adding
more work load on the Editor for the only gain that some people like the
word "Experimental" more than "Deferred"

This feels like not working on the actual problem, and just using a short
term bandaid, because after 12 Months the same process has to be done
again. Seems pointless.

The actual problem in my opinion is, that authors do not sponsor the XEP
till the end of the process.

The state deffered tells us exactly that, an idea of a standard but there
is no one that cares enough to sponsor the XEP.
And only because a client developer spends X hours to implement that XEP
does not mean it has to be kept from now on in experimental till the end of
time.

Actually i think implementations should have zero effect on any of these
decisions.

Of course it might be useful to revisit deferred XEPs.

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

Re: [Standards] Proposed XMPP Extension: Order-By

[Philipp Hörist]

Hi,

Few things i noticed while reading

- There is an attr missing that defines if the order should be ascending or
descending, just order by creation is not specific enough to me.

- There is a part where it says with RSM you can change the order. This is
kind of wrong. With RSM you can in a result set page backwards, but you
cant influence the order of items within the page.

- I feel its not really necessary to mention SQL and ORDER BY anywhere in
the document

- Business Rules: Its a first for me that a XEP depends on the order of
nodes in a stanza, i think it would be better to just add an attr that
defines the order. Also conflict seems the wrong word in this context to me.

Regards
Philipp



Am So., 6. Jan. 2019 um 15:18 Uhr schrieb Jonas Schäfer :

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Order-By
> Abstract:
> This specification allows to change order of items retrieval in a
> Pubsub or MAM query
>
> URL: https://xmpp.org/extensions/inbox/order-by.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
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Histroy tranfer idea

[Philipp Hörist]

Hi,

It seems you are talking about sending each message that should be
transfered like a regular message over xmpp.
I would also think that this is to complex.

But just defining a export/import format and transfering the messages out
of band, like upload it with httpupload. then just send a transfer message
with the link, sounds not that complex to me.

Regards
Philipp

Am Sa., 5. Jan. 2019 um 18:03 Uhr schrieb Ненахов Андрей <
andrew.nenak...@redsolution.ru>:

> > I think it's useful in case you want to transfer between to different
> > clients, there for you need some kind of standard! And transfer via
> > XEP-0313 isn't really usable because it just works with unencrypted
> > messages...
>
> Encrypted messages are not meant to be transferred. For example, OTR
> stands for Off The Record.
> Which means that messages should not be even recorded after being
> displayed. You've read them, that's it.
>
> If you want to transfer encrypted messages, use PGP like encryption,
> because what you suggest effectively
> cancels the difference between OMEMO and PGP/GPG.
>
> >1. CSV is a rather bad format and not fully standardized
>
> That was a joke. Of course, decent developers these days should use
> json for tasks like these.
>
> > Going a bit offtopic: we still have a lot of problems with message
> > delivery in XMPP, for example, we have no protection against server
> > failures during message delivery or we don't have reliable delivery
> > in presence of s2s failures. Yet, you want to add another source
> > of message delivery failures.
>
> Totally, this. We've developed a way to reliably deliver messages
> (modestly called 'reliable message delivery'), but regular chat
> messages are still vulnerable in cases of s2s failure.
>
> --
> Ненахов Андрей
> Директор ООО "Редсолюшн" (Челябинск)
> (351) 750-50-04
> http://www.redsolution.ru
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Histroy tranfer idea

[Philipp Hörist]

Hi,

1. CSV is a rather bad format and not fully standardized

2. > XEP-0313 isn't really usable because it just works with unencrypted
messages...

thats not true, it just doesnt work with encryptions that have the property
that a message can only be decrypted once.
For example it works fine with openpgp

regards
Philipp

Am Sa., 5. Jan. 2019 um 17:21 Uhr schrieb j.r :

> > Message history is already more or less OK 'transferred' from old
> > clients to newly added ones via XEP-0313 Message Archive. If some users
> > are willing to synchronize data that was/explicitly sent in a specially
> > encrypted form so it could not be possibly decrypted on any other device
> > rather than on device it was sent for,/ it should be done at app
> > developer's own responsibility. Such developer should transfer data
> > between his apps as he see fit, It should not be standard or something.
> > Besides, CSV format is already standardized, with a bunch of other which
> > are also capable to do this job.
>
> I think it's useful in case you want to transfer between to different
> clients, there for you need some kind of standard! And transfer via
> XEP-0313 isn't really usable because it just works with unencrypted
> messages...
>
> A second way I could think of to standardize the way how to
> export/import history via CSV so that all clients do the same job at
> this point!
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Simple Buttons

[Philipp Hörist]

Hi,

This should be an extension to dataforms, that way it becomes much more
useful.

Otherwise it will go fast into the same direction, first we have only a
button, then some people request some labels, and finally some other
fields, at which point everyone will ask itself why is this button element
not an extension of a dataform.

I see really no argument why this should not be in dataforms, every half
serious client already has to support some limited kind of dataform
understanding and parsing, so i dont see the way it is now as easier to
implement.

Regards

Philipp

Am Sa., 8. Dez. 2018 um 12:13 Uhr schrieb Jonas Schäfer :

> On Donnerstag, 6. Dezember 2018 20:43:07 CET Jonas Schäfer wrote:
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> >
> > Title: Simple Buttons
> > Abstract:
> > This specification provides a way to send simple buttons.
> >
> > URL: https://xmpp.org/extensions/inbox/buttons.html
> >
> > The Council will decide in the next two weeks whether to accept this
> > proposal as an official XEP.
>
> I am torn on this.
>
> I like the simplicity. However, I am worried that we end up with a half-
> solution which will quickly have to be extended by folks who request more
> features; and this solution at hand isn’t particularly extensible.
>
> My favourite example is a monitoring bot which posts an alert and offers
> buttons such as "Silence for N minutes", where N is a variable. With the
> current proposal, the bot would have to offer a fixed set of values for N,
> or
> the users would have to use manual text input (which *might* be fine,
> actually).
>
> What I like about this proposal is that it gracefully falls back to plain
> text
> only. It can also interact (although this was not written down) with
> XHTML-IM
> in the same way memberbot does (by marking up the answer options as links
> to
> xmpp:bot@foo.domain?body=yes (I think) for example).
>
> It is also reasonably simple to implement. It needs some editorial work
> though.
>
> I happen to know that there was a concurrent proposal which used a data
> form
> with a list-single field where each option represented a button. The
> client
> would then send the filled out form to indicate which button was pressed.
> This
> would also be simple to implement and might be able to interact with
> clients
> which already offer the processing of arbitrary data forms in a stream of
> messages.
>
> The data forms might be more extensible, but probably still need some
> protocol
> around them to make them actually useful as "buttons with variables" (see
> above).
>
> kind regards,
> Jonas___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0359 (Unique and Stable Stanza IDs)

[Philipp Hörist]

> But surely if a client connects and doesn't send an origin-id, you know
> the message id might not be unique?
>

Yes and thats the reason why origin-id is needed.
It seems like a useful information to know if a client uses unique ids or
not.

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

Re: [Standards] Carbons of XEP-0184 Receipts (Was: XEP-0280 (Carbons) proposals)

[Philipp Hörist]

Gajim uses type=chat only (so they will get carbon copied)

And Gajim still trys to do resource locking

regards
Philipp

Am Mo., 19. Nov. 2018 um 17:29 Uhr schrieb Jonas Schäfer <
jo...@wielicki.name>:

> On Mittwoch, 7. November 2018 10:19:44 CET Georg Lukas wrote:
> > So I spent another half hour today debugging why the green checkmark on
> > my outgoing messages only appeared on two of my three clients for one
> > contact, and only on one of my clients for another contact(*). It turned
> > out to be standard compliant behavior.
> >
> > XEP-0184 indicates (but doesn't mandate) type=normal for Receipts, which
> > is followed by most implementations. And thus, Receipts don't fall under
> >
> > Carbon rules:
> > | A  is eligible for carbons delivery if it is of type
> > | "normal" and it contains a  element.
> >
> > There is an old PR to improve the Carbons rules
> >  but it doesn't address this
> > specific case:
> >
> > * Georg Lukas  [2017-06-01 13:55]:
> > > Modern clients send bodyless messages with 0085 CSNs and 0184 ACKs to
> > > provide additional communication metadata. There is value in
> > > carbon-copying both of these message types, but there might be existing
> > > use-cases for bodyless messages where carbon-copying would do harm.
> > > Because I don't know all the use-cases for bodyless messages, I
> struggle
> > > to provide a rule for how to handle CSNs and ACKs.
> >
> > As XEP-0409 (IM Routing-NG) doesn't see wide adoption yet, I'd like to
> > move forward with improving 0280 / 0184, by one of the following:
> >
> > a) make 0280 apply to all 'normal' messages to a bare JID (akin to
> > Routing-NG) and state in 0184 that the Receipt should go to bare-JID.
> >
> > b) explicitly mention in 0184 that for chat content the Receipt should
> > also be of type=chat.
> >
> > c) All of the above.
> >
> > As 0280 rules are weasel-worded, changing them doesn't require a
> > namespace bump. In 0184 there is no mandate of the recipient JID form
> > (bare/full) nor the message type, so adding Business Rules for those
> > shouldn't require a bump either.
>
> I like to make '280 work more closely to what we expect IM-NG to do
> (option
> a), because it will give us more confidence in that IM-NG does the right
> thing.
>
> I also like to have the type of messages related to a conversation not
> flip-
> flop from one type to another, so type='chat' looks sensible to me (option
> b).
> So maybe write in '184 to mirror the type which was used for the message
> in
> reply to which the receipt is? Anything wrong with that (slightly more
> generic) approach?
>
> So all in all, I’m in for (c).
>
> kind regards,
> Jonas___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: LMC of a previous correction

[Philipp Hörist]

 



Or





i dont see why this should make a difference?

The last message gives you in both cases the current content, and you need
in both cases all other messages to display the correction history

Am Sa., 17. Nov. 2018 um 18:46 Uhr schrieb Ненахов Андрей <
andrew.nenak...@redsolution.ru>:

> I tend to think that title of this XEP is misleading and that any message
> should be possible to correct.
>
> Also, I'd rather use the original message ID, because the replaced message
> should be stored on original message place in history (with a timestamp of
> original message, though possibly amended with correction time). Using id
> of last correction would require to fetch all subsequent messages from
> archive to get to the original one and it's place in history. This is bad,
> especially for clients that could have been offline for some time and would
> have to do excessive work digging up message archive.
>
> On Sat, 17 Nov 2018, 21:35 Georg Lukas 
>> Hi,
>>
>> when correcting a previously corrected message, do you reference the
>> original message @id or the message @id of the last correction to that
>> message?
>>
>> The XEP proclaims:
>>
>> | A single message may be corrected multiple times by subsequent edits.
>>
>> which kind of leaves this question open, and from a quick survey, at
>> least poezio, Conversations and yaxim will reference the last
>> correction's message @id and not the original one.
>>
>> It would be great to clarify in the XEP business rules.
>>
>>
>> Georg
>> --
>> || http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
>> || gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
>> || Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
>> ++ IRCnet OFTC OPN ||_||
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: LMC of a previous correction

[Philipp Hörist]

Gajim corrects always the last message that was sent over the wire.

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

[Standards] XEP-0398: Avatar Conversion, resend presence

[Philipp Hörist]

Hi,

"Services will inject the hash in directed presences automatically but will
not resend the presence if the avatar gets updated. Thus clients MAY resend
directed available presence to all Multi-User Chats after receiving a
'urn:xmpp:avatar:metadata' update notification. The service will then
inject an updated version of the hash. To avoid sending unnecassary
presence updates, resending should only occur if the service annouces the
'urn:xmpp:pep-vcard-conversion:0' feature."

1. Can we not let the server resend presence after a vcard/0084 update?

2. "To avoid sending unnecassary presence updates, resending should only
occur if the service annouces the 'urn:xmpp:pep-vcard-conversion:0'
feature."

It basically says: Dont do the things that are mentioned in this XEP if the
server doesnt support this XEP. In this case resending presence after a
metadata node update. I think this is implied by any XEP, that if your
counterpart does not have support, things mentioned in this XEP do not apply

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

Re: [Standards] XEP-0384: Staleness of devices

[Philipp Hörist]

Yes you can call this a Heartbeat message, but it doesnt solve the Problem
it only makes it less likely.

I as a client developer want to secure my users Communication, i cant
depend for that on other devices sending me Heartbeat messages and
advancing the rachet.
I always have to have measures in place when a device does not answer for a
long time.
This does not even mean the device behaves wrong, it could just be that it
is offline for a month.
If i dont stop encrypting to it after X messages, an attacker who gets a
hold of this device can decrypt all messages a full month back.

As for the question if an amount X should go into the XEP. I dont think
this is a good idea.
After how many messages you should stop encrypting depends on your threat
model, and how and for what you use the application.
500 could be way too much or a way too low number.
I think every application should set their own numbers.

Regards
Philipp

Am Di., 28. Aug. 2018 um 16:28 Uhr schrieb Jonas Wielicki <
jo...@wielicki.name>:

> Note, I’m not familiar with OMEMO and it’s ratchet system, so take this
> with a
> grain of salt.
>
> On Dienstag, 28. August 2018 13:26:51 CEST Paul Schaub wrote:
> > Another countermeasure against stale devices is sending empty
> > ratchet-forward messages on a regular basis. Those messages do have the
> > same format as KeyTransportMessages [3], in that they do not contain a
> > body. Their purpose is to forward the ratchet without user interaction.
> > The downside is, that a device has to do this on its own, so this is not
> > a good defense against attackers devices.
>
> Would it be possible for devices which exist and are used by a user, but
> not
> for sending (for whatever reasons) to auto-reply with an empty message
> with
> e.g. a probability of 1/10 or whatever to each message? This would allow
> advancement of the ratchet (If I Understand This Correctly) without user
> interaction and it puts the burden on the device which still wants to
> receive
> messages (i.e. if an attacker chooses to not send these messages, they’re
> hurting themselves).
>
> But yeah, I have no idea about OMEMO. Just throwing stuff in.
>
> kind regards,
> Jonas___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0060: Item ordering

[Philipp Hörist]

Hm revert that, i actually dont know what ejabberds PEP impl does in this
case.

Regards
Philipp

2018-08-08 17:57 GMT+02:00 Philipp Hörist :

> And this brings us to the next critical question which affects all PEP
> reliant XEPs
>
> https://xmpp.org/extensions/attic/xep-0060-1.11.html#
> subscriber-subscribe-last
>
> What is the last published item? The last modified item or the last
> published under a new ID
>
> Seems all PEP implementation that i know choose the last modified item
> (Also ejabberd).
> But if the last published item is also the last modified then it follows
> that the most recent should also the last modified, otherwise i would find
> this not very consistent
>
> Regards
> Philipp
>
> 2018-08-08 17:48 GMT+02:00 Timothée Jaussoin :
>
>> Le mercredi 08 août 2018 à 16:32 +0100, Matthew Wild a écrit :
>> > On 8 August 2018 at 16:17, Peter Saint-Andre 
>> wrote:
>> > > On 8/8/18 3:17 AM, Philipp Hörist wrote:
>> > > > I always thought the most recent refers to the publish date/time of
>> the
>> > > > item, hence if i override a item it also changes the updated
>> time/date
>> > > > and it becomes the most recent
>> > >
>> > > That seems reasonable. So it's really "last modified item". I'm
>> curious
>> > > what Ralph thinks.
>> >
>> > Me too.
>> >
>> > I personally have always shared Philipp's interpretation. A publish of
>> > an item is a publish, whether another item already existed with that
>> > id or not.
>>
>> So it's a https://xkcd.com/1172/ case for me.
>> Having a "social network" implementation using Pubsub this behavior is
>> going against the current flow that I'm using in Movim.
>> If you edit an article on a social network or a blog it shouldn't move
>> back to the top of your feed. It is also, afaik, how ejabberd is
>> handling it.
>>
>> In both cases, does the disco#items (https://xmpp.org/extensions/x
>> ep-0060.html#entity-discoveritems) and query items (
>> https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-returnsome)
>> IDs order should be consistent then? If it's the case then
>> using RSM on disco#items should be enough to "refresh" what the client
>> missed on a node (give me all the items published after the ID
>> of the last updated item that I have in my cache) without actually having
>> to compare the payloads.
>>
>> I'm also wondering if this affects https://xmpp.org/extensions/xe
>> p-0395.html.
>>
>> Regards,
>>
>> Timothée
>>
>> >
>> > I'd say this interpretation also makes the most sense if you consider
>> > the perspective of someone subscribed to the node. Requesting the
>> > items will return the same items in the same order that you would have
>> > received them while subscribed, with the obvious exception of items
>> > that have been replaced.
>> >
>> > Regards,
>> > Matthew
>> > ___
>> > Standards mailing list
>> > Info: https://mail.jabber.org/mailman/listinfo/standards
>> > Unsubscribe: standards-unsubscr...@xmpp.org
>> > ___
>>
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0060: Item ordering

[Philipp Hörist]

And this brings us to the next critical question which affects all PEP
reliant XEPs

https://xmpp.org/extensions/attic/xep-0060-1.11.html#subscriber-subscribe-last

What is the last published item? The last modified item or the last
published under a new ID

Seems all PEP implementation that i know choose the last modified item
(Also ejabberd).
But if the last published item is also the last modified then it follows
that the most recent should also the last modified, otherwise i would find
this not very consistent

Regards
Philipp

2018-08-08 17:48 GMT+02:00 Timothée Jaussoin :

> Le mercredi 08 août 2018 à 16:32 +0100, Matthew Wild a écrit :
> > On 8 August 2018 at 16:17, Peter Saint-Andre 
> wrote:
> > > On 8/8/18 3:17 AM, Philipp Hörist wrote:
> > > > I always thought the most recent refers to the publish date/time of
> the
> > > > item, hence if i override a item it also changes the updated
> time/date
> > > > and it becomes the most recent
> > >
> > > That seems reasonable. So it's really "last modified item". I'm curious
> > > what Ralph thinks.
> >
> > Me too.
> >
> > I personally have always shared Philipp's interpretation. A publish of
> > an item is a publish, whether another item already existed with that
> > id or not.
>
> So it's a https://xkcd.com/1172/ case for me.
> Having a "social network" implementation using Pubsub this behavior is
> going against the current flow that I'm using in Movim.
> If you edit an article on a social network or a blog it shouldn't move
> back to the top of your feed. It is also, afaik, how ejabberd is
> handling it.
>
> In both cases, does the disco#items (https://xmpp.org/extensions/
> xep-0060.html#entity-discoveritems) and query items (
> https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-returnsome)
> IDs order should be consistent then? If it's the case then
> using RSM on disco#items should be enough to "refresh" what the client
> missed on a node (give me all the items published after the ID
> of the last updated item that I have in my cache) without actually having
> to compare the payloads.
>
> I'm also wondering if this affects https://xmpp.org/extensions/
> xep-0395.html.
>
> Regards,
>
> Timothée
>
> >
> > I'd say this interpretation also makes the most sense if you consider
> > the perspective of someone subscribed to the node. Requesting the
> > items will return the same items in the same order that you would have
> > received them while subscribed, with the obvious exception of items
> > that have been replaced.
> >
> > Regards,
> > Matthew
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0060: Item ordering

[Philipp Hörist]

I always thought the most recent refers to the publish date/time of the
item, hence if i override a item it also changes the updated time/date and
it becomes the most recent

Regards
Philipp

2018-08-08 11:06 GMT+02:00 Matthew Wild :

> The XEP is not very explicit about the order of items within a pubsub
> node. The closest it gets is referring to the ability to fetch "the
> most recent items".
>
> Item IDs are unique, so publishing an item with an existing ID
> replaces the original item.
>
> Is this new item "the last published item" (a term from the XEP), or
> does it sit in place of the item that originally had that ID?
>
> Regards,
> Matthew
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items

[Philipp Hörist]

>   but instead limit their queries to the newest item.

They cant, because thats an optional feature of the Server.

Its not about querying a ID, its about writing that the ID has to be set.
If you write MUST set "recent" as id, i think its a namespace bump, if you
dont write this, then you are in the same situation as now, it could be a
singleton Node, but also it couldnt.

Regards
Philipp

2018-07-27 17:01 GMT+02:00 Jonas Wielicki :

> On Freitag, 27. Juli 2018 16:41:57 CEST Philipp Hörist wrote:
> > I think this is a good addition to the XEP, although i fear this would
> be a
> > namespace bump, but from practical experience every PEP impl sends only
> the
> > last item, so this is until now a  academic problem
>
> This wouldn’t be a namespace bump in my reading of the rules, since
> setting or
> not setting the item ID does not pose an interoperability issue:
>
> * A new item which is pushed will always be the newest item irrespectively
> on
> whether it replaced an existing item or not.
>
> * Since the ID wasn’t fixed before, no implementation will be asking for
> this
> specific ID. We have to write down that implementations SHOULD NOT rely on
> this ID for queries, but instead limit their queries to the newest item.
>
> * No implementation should be relying on getting a history of OMEMO public
> keys, since many PEP implementations do or did not support this.
>
> kind regards,
> Jonas
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items

[Philipp Hörist]

Hi,

Didnt know about that PEP sentence, i dont know any implementation that
does this, but still if its possible we should limit 0384 to singleton Node
usage, but to be honest so should every other XEP that depends on PEP.

you misunderstood me with the max_items=1, yes you can configure a node
with max_items=1 but you can also specify this in a pubsub request of a
Node (not config):
https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-requestrecent

But this seems to be optional *also*

So indeed the only not optional thing here is Singleton Node

I think this is a good addition to the XEP, although i fear this would be a
namespace bump, but from practical experience every PEP impl sends only the
last item, so this is until now a  academic problem

Regards
Philipp

2018-07-27 16:26 GMT+02:00 Goffi :

> Hey, thanks for the quick feedback
>
> Le vendredi 27 juillet 2018, 16:10:38 CEST Philipp Hörist a écrit :
> > On the Pubsub Questions:
> >
> > 1. In Pubsub there is already defined the Singleton Node:
> > https://xmpp.org/extensions/xep-0060.html#impl-singleton, no need to
> > invent a new item id for that
>
> Oh great, I've missed this one. But it doesn't seems used by other clients
> unfortunately, would be nice to add an implementation note on that in
> XEP-0384
>
> > 2. I think its not specified because your client should not care how many
> > items are in a PubSub Node. Your Client either uses PEP and PEP should
> > only notify you about the last/most recent item on the node, i think
> > thats the reason PEP exists.
>
> XEP-0163 §4.3.4 says "When processing a new subscription, the service MAY
> send not only the last published item but instead all items that are
> currently associated with the node (i.e., up to the maximum number of
> items
> at the node, which might be one if the node is a "singleton node" as
> described in XEP-0060)", so it can send all items
>
> > 3. if you dont want to use PEP you can always request the most recent
> > item from a node with specifying max_items=1 in the request.
>
> It's not that I don't want to use PEP (I'm using it), it's that I don't
> want to have the same items recorded again and again for nothing.
> I've mentioned max_items=1 in my previous message, but this feature is
> optional, and if singleton is needed (which is the case), it should be
> indicated in the XEP-0384 in my opinion.
>
> > So my question would be, how do you get into a situation where a server
> > sends you all items of the Node?
>
> It's not in my notifications, I'm checking manually the content of my PEP
> nodes to check the workflow.
>
> >
> > regards
> > Philipp
>
> Thanks
> Goffi
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items

[Philipp Hörist]

On the Pubsub Questions:

1. In Pubsub there is already defined the Singleton Node:
https://xmpp.org/extensions/xep-0060.html#impl-singleton, no need to invent
a new item id for that

2. I think its not specified because your client should not care how many
items are in a PubSub Node. Your Client either uses PEP and PEP should only
notify you about the last/most recent item on the node, i think thats the
reason PEP exists.

3. if you dont want to use PEP you can always request the most recent item
from a node with specifying max_items=1 in the request.

So my question would be, how do you get into a situation where a server
sends you all items of the Node?

regards
Philipp

2018-07-27 16:03 GMT+02:00 Goffi :

> Hello,
>
> I'm currently working on OMEMO implementation in Salut à Toi thanks to the
> work of Syndace (https://github.com/Syndace/python-omemo), and I have two
> issues with it:
>
> - SàT is using xml:lang attribute, and I don't see a way to specify it
> with
> OMEMO, how should I do? What are business rules when several bodies are
> available (I know it's not common, but it's allowed by RFCs)?
>
> - only the first item of PEP nodes are used, and it seems that client are
> implicitly expecting max_items=1 (i.e. singleton pattern), but I don't see
> any mention of that in the XEP.  Furthermore, max_items support is
> optional
> in Pubsub, and I see in my PEP nodes the same items published several
> times. This could be mitigated by using a well known id for the item (e.g.
> the OMEMO namespace), so even pubsub services not featuring max_items
> would
> simply override the existing item.
>
> That's all for now, thanks
> Goffi
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Philipp Hörist]

> Why can't you decrypt OMEMO messages a second time? If you keep keys,
what would stop you?

then you implemented the signal protocol in a wrong way and you lose
forward secrecy

> yes, and I'd rather start with adding capability to delete messages from 
> server.

then do this, a call to the archive to delete a message can always be
added to a xep like that at a later point.

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

Re: [Standards] Disappearing timers for OMEMO proposal

[Philipp Hörist]

Thats why he wrote, it should only available for encrypted messages,
because we have no way to delete messages from an archive.

Also you can not decrypt OMEMO encrypted messages a second time, so if
you delete the message once from your device, its gone for good.

The idea in combination with OMEMO, minus all the proposed "try to
determine support on the other side" would be easy to implement and
would work

regards

2018-05-10 14:36 GMT+02:00 Ненахов Андрей :
> 2018-05-10 17:31 GMT+05:00 VanitasVitae :
>> I'd also rather not tie it to OMEMO.
>
> By the way ,self-destructing messages should also be deleted from
> message archives on both sender and recipients servers. For e2ee
> messages one can argue that it's not really important if messages are
> not deleted from server, however, it's just yet another way to make
> such 'ephemeral' messages reappear on recipient's device - just by
> reading from archive.
>
>
> --
> Ненахов Андрей
> Директор ООО "Редсолюшн" (Челябинск)
> (351) 750-50-04
> http://www.redsolution.ru
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on MIX adoption (and will MIX ever happen?)

[Philipp Hörist]

Im interested in implementing it in Gajim

It would be nice if someone could share the domains where a server
runs that offers some kind of MIX impl.

regards
Philipp

2018-05-10 10:36 GMT+02:00 Steve Kille :
>
> Having made the latest round of MIX edits,  I felt it was time to share some
> thoughts on MIX.
>
> It has been a number of years since work was started on MIX, and
> implementations are thin on the ground.  It seems sensible consider when and
> if this will change.
>
> There are a number of reasons why MIX take-up is likely to be slow:
>
> 1.  It is a big spec to implement for either client or server, even for a
> server with a good MAM and PubSub base.
>
> 2.   The is a chicken/egg situation with clients and servers.  A server
> implementor will wait until MIX clients are available and vice versa.
>
> 3.   This does not appear to be an exciting new service (but see later).   A
> simple view of MIX is that it is just a different way of providing an
> existing service, so there is not simple customer benefit or drive for MIX.
>
> 4.  MUC broadly works.   There are lots of little things broken, but there
> is no major issue to force replacing it.
>
> 5.   MIX needs a migration.This will inherently slow things down and
> inhibit starting stuff.
>
> 6.   Some in the community are working to address issues by updates to MUC.
> From my perspective, this is "string and duct tape" and is not addressing
> deeper problems. Such activity will delay MIX.
>
> 7.   Related to the above, some feel that MIX is just too much, and this
> definitely creates a feeling of "will MIX ever happen?".
>
>
> Predicting the future is hard, but.
>
> Isode is committed to both server (M-Link COTS product) and client (Swift
> free & open source) implementations of MIX.   We have strategic reasons to
> do this, particularly because of requirements on constrained networks.   We
> have lots of other things we also need to do, but MIX is going to happen in
> our product set.
>
> It may well be that others will produce general purpose MIX implementations
> first (e.g., Surevine), but let's suppose this does not happen.
>
> It seems conceivable that MIX will end up as a specification that is useful
> for specific purposes, but not widely implemented (e.g., like XEP-0365).
>
> However,  I do not think this will happen, as MIX has many benefits.  I
> think that initial implementations will encourage others, almost certainly
> gradually at first.Once there are a few implementations, more will
> follow.   Then MIX will be seen as something that modern XMPP
> implementations need to have and other implementations will play catch up.
>
> Let me justify this in terms of MIX benefits that I see:
>- Some of the broken bits of MUC that we all live with will become much
> clearer as MIX starts to be used.  There will be a "how did I ever live with
> that" experience
>- Multi-client will become more important, and MIX will avoid a slew of
> MUC problems
>- "proper" history support will add value
>- Message only option will be important for constrained bandwidth and
> will facilitate observers (avoiding "presence clutter" from observers
>- As we work to build richer multi-user communication, with shared files,
> shared pictures, comments and likes, MIX is going to be the building block
> we need (that MUC is not)
>
> I do not think that this is going to happen quickly, but my  (biased) bet is
> that MIX is going to happen
>
>
>
> Steve
>
>
>
>
>
>
>
>
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Philipp Hörist]

Your proposal seems very complicated and impossible to understand for
normal Users

- They dont even know to which device they are sending a message. Most
clients work on hiding resources from users, not bringing them back
into the UI. You want users caring about resources? Naming them
accordingly to the device, so other users can better guess what the
device is they are sending a message to?

- you cite *not for situations where your contact is your adversary*
and still take then multiple steps to ensure messages are deleted on
other devices. Its doomed to fail, dont even try.

- I dont even want to get into point 4.

In my opinion this XEP should be very small, add a  tag and use
it only with encryption, then hope most clients implement it - done.


regards

2018-05-10 2:12 GMT+02:00 Alexander Krotov :
> I propose to extend OMEMO with disappearing messages.
>
> There is already a thread with a subject: "Self-destruct" message timeout 
> deletion hints.
> It started with this message: 
> https://mail.jabber.org/pipermail/standards/2016-October/031515.html
> Continued in November: 
> https://mail.jabber.org/pipermail/standards/2016-November/031595.html
> Last message is from 2017: 
> https://mail.jabber.org/pipermail/standards/2017-February/032092.html
>
> The thread was started shortly after Signal announced its implementation
> of disappearing messages in October 2016.[1] Rationale provided in
> the blog post is worth repeating here to avoid talking about the
> goals of this feature again, because it causes confusion all the
> time (emphasis mine):
>> Disappearing messages are a way for you and your friends to keep
>> your message history tidy. They are a *collaborative feature* for
>> conversations where all participants want to automate minimalist
>> data hygiene, *not for situations where your contact is your adversary*
>> — after all, if someone who receives a disappearing message really
>> wants a record of it, they can always use another camera to take a
>> photo of the screen before the message disappears.
> See also the Signal FAQ entry for disappearing messages[2].
>
> Implementing Snapchat-over-XMPP is a non-goal, so we don't have to
> take into account hostile clients.  Someone may run a client that
> advertises support for disappearing messages and does not actually
> delete them, but it is the problem of trust between users.  Hostile
> user may just as well run a client that advertises end-to-end
> encryption, but leaks encryption keys or message contents later.
>
> The problem with previous thread is that it was about *message
> hints*, as defined in XEP-0334[3].  Legacy clients, as well as
> legacy or hostile servers, may not implement these hints and store
> messages permanently without any way for users to ensure their
> messages are deleted. Therefore, any plaintext message should be
> assumed to be stored permanently, and there is no point in implementing
> timers for them. Telegram developers seem to understand it too, and
> only implement timed messages for end-to-end encrypted "secret
> chats", in contrast to plaintext "cloud chats".
>
> What I propose instead of message hints is to extend OMEMO with:
> 1. a way to discover disappearing message timer support per device,
> 2. a way to specify timer value in messages,
> 3. specification of timer value semantics,
> 4. a protocol to negotiate common disappearing message timer.
>
> Signal solutions to these problems cannot be copied exactly for
> several reasons, which I describe below.
>
> 1. A way to discover disappearing message timer support per device.
>
> In XMPP, some devices will never get the support for disappearing
> messages. Therefore, disappearing messages must be encrypted only
> for devices which advertise their support.
>
> Signal didn't have to deal with this problem. All devices were
> eventually updated to the newest version of the Signal and processed
> disappearing messages.
>
> As I understand from OMEMO specification[4], the best place to
> advertise support for disappearing messages is the device bundle.
>
> As for UI, OMEMO+Timers can be treated simply as another encryption
> method. User will have to choose between None, OpenPGP, OTR, OMEMO
> and OMEMO+Timers. If user selects OMEMO+Timers, devices which only
> support OMEMO will receive a message they can't decrypt.
>
> Devices that don't support OMEMO+Timers will leave the trace of
> communication, but little can be done about it I believe. Proper
> metadata protection, i.e., hiding the fact of communication, is
> impossible in XMPP, so it is a non-goal for this proposal.
>
> 2. A way to specify timer value in messages.
>
> Timer value should be placed somewhere in  tag. I would
> also like to make it encrypted. Problem is, the only encrypted part
> of the message is the  which contains plaintext message
> corresponding to the contents of  and is not extensible.
>
> OX (XEP-0374) solves the problem by treating payload contents as
> the  contents, i.e., the pay

Re: [Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion

[Philipp Hörist]

But even that is not very useful, Laws change all the time.

At the same time you can write "Follow the local Laws"

And why would this only concern HTTPUpload, Laws also concern all kind
of data that run over the server.

Its really not the place of a standard document to remember people to
follow the law.

regards

2018-05-01 10:24 GMT+02:00 Kevin Smith :
> On 1 May 2018, at 09:03, Evgeny Khramtsov  wrote:
>>
>> Mon, 30 Apr 2018 13:20:38 +0200
>> Jonas Wielicki  wrote:
>>
>>> I agree with your stance about deletion. Which is why I made it a
>>> separate PR.
>>>
>>> What do you think about the independent extension to the text I
>>> proposed in https://github.com/xsf/xeps/pull/625 ?
>>
>> While I'm fine with having a separate extension, I'm against the PR
>> itself. I think the behaviour is up to a local policy. We shouldn't make
>> default recommendations based on some local laws (GDPR). Because if we
>> do that, we can easily add "NOT" to all "SHOULD"s, and in this case we
>> will describe the local law of Russia (where it is required to keep all
>> users data for at least 6 months). I would really advise XSF to avoid
>> making political statements. Not to mention that the text brings
>> nothing to the document and only increases its size: it doesn't
>> describe any protocol, it doesn't describe security considerations, it
>> doesn't describe UX, so what does it do? Can we replace the text with
>> "People SHOULD live in peace?" Because the meaning of the statement
>> doesn't change a lot and a reader can easily ignore it.
>
> I largely agree with Evgeny on this. I’m fine with having a single line 
> drawing attention to potential requirements (like the "The availability of 
> deletion might be a requirement in jurisdictions where users have a right to 
> have their data deleted on request.” in the PR), but I don’t think this 
> normative language is the right thing to do.
>
> /K
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0191 Blocking Command: Matching JID

[Philipp Hörist]

If domain and resource match, the jid is blocked, i find this pretty clear

regards

2018-04-27 10:08 GMT+02:00 Miguel Ángel Ortuño :
> Yeah, alteady read it. But does not seem to clarify my question at all. :(
>
> Sent from Mobile
>
>
> On vie, abr 27, 2018 en 09:59, Dave Cridland  escribió:
>
>
> On 27 April 2018 at 08:34, Miguel Ángel Ortuño 
> wrote:
>>
>> One short question. When specifying a JID of the form domain/resource,
>> should that block every single user of the form user@domain/resource? or
>> only the concrete domain/resource JID?
>>
>
> The latter. Section 6 seems to cover it.
>
> Dave.
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0249 (Direct MUC Invitations)

[Philipp Hörist]

You send a mediated invite if you dont know the real jid, and a direct
if you know

regards

2018-04-18 1:27 GMT+02:00, Tedd Sterr :
> So how would a client choose whether/when to send a mediated invitation or
> direct invitation?
>
> If mediated invitations can't necessarily be trusted, or won't necessarily
> even be received, are they useless?
> Always send a direct invitation? Send mediated, wait 10 minutes, then direct
> if no reply?
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

[Philipp Hörist]

2018-03-18 19:47 GMT+01:00 Ненахов Андрей :
> If the only reason to have bookmarks is to store there information about
> conference rooms, can we instead concentrate on better MUC standard that
> does not rely on various crutches like bookmarks to work properly across
> connected clients?
>

Bookmarks are not some workaround because of a bad MUC standard.

If you want to work on MUC, there are a hundred threads about the
upcoming MIX standard.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0394: too weak to replace XEP-0071

[Philipp Hörist]

Why would we make the body 393 compatible?

Is it too much to ask from developer to parse a markup tag and style the
string accordingly?!

we talk about max 5 lines of code here

start, end = getTag('emphasis').getAttrs()
string.addStyle('emphasis', start, end)

take this times 5 for the 5 elements 393 supports

thats an approximation
 but
i dont need much more in GTK/Python3

So i dont really see the reason why i should add some backup body for
clients who dont support that.

2018-03-15 15:46 GMT+01:00 Kozlov Konstantin :

>
>
> 15.03.2018, 16:31, "Jonas Wielicki" :
>
> Okay, so since I’m not going to get around to updating '394 this month and
> there’s considerable interest, I’ll write down what I have in mind:
>
> * Emphasis, Strong emphasis, inline-preformatted (code)
> * Enumerations
> * Itemized lists
> * Headings (two or three levels)
> * Paragraphs
> * XEP-0392-based colors (i.e. you only give a hue and the remainder is
> handled
> by the recipient)
> * Code blocks with annotation of the language for optional receiver-side
> highlighting
> * Maybe inline images
>
> It sounds promising. I just wonder why no links and no font customization?
>
> Now there has been a lot of discussion around how to make this degrade
> gracefully. I’m thinking of the following:
>
> Each markup annotation has a mandatory pre- and postfix in the body which
> is
> stripped once the markup is applied. That works like this (just a rough
> outline, don’t take the syntax for literal):
>
> This is the *new* markup.
> 
>   
> 
>
> Now  would be defined so that the selected range of  MUST
> start with "*" and MUST end with "*". If-and-only-if (iff) that is the
> case,
> the prefix and postfix is removed and the text is displayed with emphasis
> applied on the word "new".
>
> This is complex, and will not get less complex with more complex constructs
> like enumerations.
>
> The reason for this complexity is that it allows a '393-compatible 
> message, and also in general a good human-readable representation in
> clients
> which do not support it (if we chose the requirements well), while at the
> same
> time not allowing to "delete" arbitrary characters for some readers (it has
> been pointed out that this type of discrepancy can lead to problems).
>
> That idea is really interesting. An attempt to add compatibility to those
> two XEP's.
> But implementation  element like this without additional
> statements implies support of XEP-0393.
> IMHO it should be stated, that  element should be allowed only
> if other party explicitly supports not only XEP-0394, but also XEP-0393.
> Otherwise, it would be impossible to implement XEP-0394 without
> implementing XEP-0393, and XEP-0394 will be just an addition to XEP-0393.
>
> With my best regards,
> Konstantin
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0066: Out of Band Data

[Philipp Hörist]

1. What software has XEP-0066 implemented?



Gajim, only 3. communicating a uri via message



2. Have developers experienced any problems with the protocol as

defined in XEP-0066?



Not with 3., but cant comment on the other XEP Parts



3. Is the text of XEP-0066 clear and unambiguous? Are more examples

needed?



3. Is clear, cant comment on the rest



We implemented primarily as a hack so we can mark messages that contain
only a httpupload link, we add the uri also in the oob tag, and other
Clients can treat this message differently, for example displaying the
image, instead of displaying any random weblink that someone sends with a
message.



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