Re: [Standards] [XEP-0384] OMEMO: MUST silently discard [..]

[forenjunkie]

Hi,
As Daniel wrote, MUST is probably to strong here, it is enough to 
mention that it can lead to problems if you dont discard such messages.
If you have a client that always shows the user if a decryption fails, 
this also means you need a client that has absolute perfect 
deduplication in any kind of scenario.
Otherwise you show the user he misses a message when in reality he 
doesnt miss a message. Pepare for many Bug reports.
At the time the XEP was written, even mam:2 was not widley deployed, so 
saying any client can have perfect deduplication was far fetched.
Nobody wants to use a standard that constantly gives the impression you 
miss messages when there is no problem at all.


Also there are still quite a few mam:1 servers out there, so good luck 
deduplicating if the message is encrypted and there is no stanza-id :)



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

Re: [Standards] XEP-0313: Treatment of type=groupchat in user archive with or without hint

[forenjunkie]

I agree that for “catch-up”, it’s not particularly useful, but knowing exactly 
what messages you’ve seen is.



Makes sense if we see the Archive as Store of all messages we have seen.
I often forget thats that the original idea, because of OMEMO PFS i does 
not serv that purpose.


Also if we lose our device, and we want a copy of the archive, we would 
not want to have all groupchats we ever were part of to get our messages 
back.


So for the backup use case this makes sense.

For the message sync between devices use case its not needed/wanted.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313: Treatment of type=groupchat in user archive with or without hint

[forenjunkie]

is and what would client
developers want?


i also found this out the hard way, thats why i drop all messages 
type=groupchat immediatly on a user archiv query.


i dont see a use for this.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0384: OMEMO Encryption - Feedbacks and proposals

[forenjunkie]

Hi,

I see no downside with your proposal, but the upsides are not as plenty 
as you described.


1. every client gets notified already if a update to the device list is 
made, otherwise OMEMO would not work half of the time


2. there is no code that is added *only* to prevent the race condition, 
a device has always be aware of all device ids that are published, and 
also has to have the ability to delete the whole device list. So in any 
case you need code that sees if your own device id is not in the list 
anymore, and can add itself to the devicelist again. this code is 
additionally also what prevents the race condition. I dont know if its 
easier to just overwrite the list like we do now, or delete all items of 
a node.


It still maybe a cleaner implementation, im not very knowledgeable on 
pupsub/pep.



Am 06.01.2017 um 09:36 schrieb Jaussoin Timothée:
The current usage of PEP is, for me, not optimal and overly complex. 
Having a list of devices that needs to be synchronized on a node and 
their related bundles on some others brings race-conditions issues 
(actually mentioned in the Example 2.) and forces the clients to 
implement extra checks to ensure that everything is properly 
synchronized.


Proposal :

I propose to simply publish the bundles on several items in one unique 
"urx:xmpp:omemo:0" node. Each item ID will be the device ID.


To discover the device ID list a simple 
http://jabber.org/protocol/disco#items query would then be sufficient 
and will rely on existing PEP/Pubsub implementations (client and 
server wise). Furthermore, each client could be instantly notified 
when a device has been added or retracted from the list.


A similar behavior has already been standardized in XEP-0277: 
Microblogging over XMPP.


This seems to already work with servers like Metronome and ejabberd 
(not Prosody for now) and should not cause issues with existing OMEMO 
implementations that are still based on Axolotl and using the 
eu.siacs.conversations.axolotl namespace.


Regards,

Timothée Jaussoin aka edhelas



___
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] Unread syncing

[forenjunkie]

Ah now im understanding, basically the server should give you a list of 
contacts to query for messages.


i would see this as a simply addition to MAM.

The Archive already could know what messages you read, because of 
chatmarkers. it would only need to hold the last read marker stanza id 
for every contact in roster, and perform some SQL magic on query.


it would send you a list of contacts and afterwards you could start 
querying the archive for messages of these contacts.



Am 02.12.2016 um 17:14 schrieb Kevin Smith:



On 2 Dec 2016, at 16:03, forenjunkie <forenjun...@chello.at> wrote:

Why would you querry the whole archive?

Because the question isn't "do I have unread messages for contact X?" It's "in what 
chats do I have unread messages and how many?" on login. I don't see a way to solve this using 
the building blocks we have without exhaustive querying of the archive. The case of fetching 
context when the user later opens a chat is the easy part.

This is why I asked with a specific example, for which I don't think we 
currently have protocol. Can you show me what the protocol would look like for 
the case I mentioned earlier?

/K


if you open a chat with a contact you querry "Give me the last X messages for 
contact A"

And if you open the chat window with contact B you do the same for contact B.

I never did write a implementation of MAM myself, but if im reading the XEP, 
you can filter with various attributes, you dont have to step through EVERY 
message.


Am 02.12.2016 um 16:57 schrieb Kevin Smith:

On 2 Dec 2016, at 15:49, forenjunkie <forenjun...@chello.at> wrote:
Its not written down somewhere that its up to the client, but it makes no sense 
to put a selflimiting hard rule on a archiving XEP like MAM and exclude certain 
messages per XEP rule.



We have store hints, the most prominent servers respect these. And it would 
make no sense to not respect it if a client explicitly wishes for a message to 
be stored.

Oh, it’d make lots of sense. Server admins can very reasonably want to choose 
how their archive is populated, rather than having remote clients do so.


So to make it more clear, if i want to save a message on a current prosody or 
ejabbered MAM implemenation, i can do this as a client with a store hint.

While that’s nice for you, Prosody and ejabberd are certainly not the whole 
world ;)


you dont have to querry the whole archive, you just querry until you get a read 
marker, then you know everything that comes before that was already read so i 
dont have to query it.

This is untrue, though. If I have two contacts, it’s quite easy for me to have 
unread messages for contact A that are hundreds or thousands of messages older 
than my messages from contact B, all of which are read. If I merely read the 
archive backwards until I found a read marker, I wouldn’t find the unread 
messages for contact A.

/K


Am 02.12.2016 um 16:34 schrieb Kevin Smith:

On 2 Dec 2016, at 15:26, forenjunkie <forenjun...@chello.at> wrote:
in a single chat conversation, it makes no sense to query unread messages.

I’m not sure that’s true at all, but putting that to the side for the minute...


you could just query the last 10 MAM Messages, if no readmarker comes with it, 
query another 10. such a implementation of MAM would be very weird to me, but 
you could do it and get only unread messages with it. So this already works 
without problem with the MAM and 0333 XEP.
And in single chat its not possible to "miss" a message in between, which you 
would want to query.

I think you’re missing the details of what I asked - how do you achieve this 
where there are a sufficient number of messages that just keeping querying 
until you have every message in your local archive isn’t viable?


And this is not a theory, XEP-0333 are stored by the server if the client 
wishes that, and working implementations of MAM and 0333 together you can 
witness for example in Conversations.

It’s not up to the client whether 333 is stored by the server or not.


All i see in this proposal is adding complexity to the whole process in 
introducing another thing the server has to support.

Referring back to my previous question, can you provide an example of how to 
achieve this case with just 313 and 333 (in protocol)?

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

___
Standards mailing list
Info: https://mail.jabber.org/mailman/list

Re: [Standards] Unread syncing

[forenjunkie]

Why would you querry the whole archive?

if you open a chat with a contact you querry "Give me the last X 
messages for contact A"


And if you open the chat window with contact B you do the same for 
contact B.


I never did write a implementation of MAM myself, but if im reading the 
XEP, you can filter with various attributes, you dont have to step 
through EVERY message.


Am 02.12.2016 um 16:57 schrieb Kevin Smith:

On 2 Dec 2016, at 15:49, forenjunkie <forenjun...@chello.at> wrote:

Its not written down somewhere that its up to the client, but it makes no sense 
to put a selflimiting hard rule on a archiving XEP like MAM and exclude certain 
messages per XEP rule.




We have store hints, the most prominent servers respect these. And it would 
make no sense to not respect it if a client explicitly wishes for a message to 
be stored.

Oh, it’d make lots of sense. Server admins can very reasonably want to choose 
how their archive is populated, rather than having remote clients do so.


So to make it more clear, if i want to save a message on a current prosody or 
ejabbered MAM implemenation, i can do this as a client with a store hint.

While that’s nice for you, Prosody and ejabberd are certainly not the whole 
world ;)


you dont have to querry the whole archive, you just querry until you get a read 
marker, then you know everything that comes before that was already read so i 
dont have to query it.

This is untrue, though. If I have two contacts, it’s quite easy for me to have 
unread messages for contact A that are hundreds or thousands of messages older 
than my messages from contact B, all of which are read. If I merely read the 
archive backwards until I found a read marker, I wouldn’t find the unread 
messages for contact A.

/K



Am 02.12.2016 um 16:34 schrieb Kevin Smith:

On 2 Dec 2016, at 15:26, forenjunkie <forenjun...@chello.at> wrote:

in a single chat conversation, it makes no sense to query unread messages.

I’m not sure that’s true at all, but putting that to the side for the minute...


you could just query the last 10 MAM Messages, if no readmarker comes with it, 
query another 10. such a implementation of MAM would be very weird to me, but 
you could do it and get only unread messages with it. So this already works 
without problem with the MAM and 0333 XEP.
And in single chat its not possible to "miss" a message in between, which you 
would want to query.

I think you’re missing the details of what I asked - how do you achieve this 
where there are a sufficient number of messages that just keeping querying 
until you have every message in your local archive isn’t viable?


And this is not a theory, XEP-0333 are stored by the server if the client 
wishes that, and working implementations of MAM and 0333 together you can 
witness for example in Conversations.

It’s not up to the client whether 333 is stored by the server or not.


All i see in this proposal is adding complexity to the whole process in 
introducing another thing the server has to support.

Referring back to my previous question, can you provide an example of how to 
achieve this case with just 313 and 333 (in protocol)?

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

___
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] Unread syncing

[forenjunkie]

Its not written down somewhere that its up to the client, but it makes 
no sense to put a selflimiting hard rule on a archiving XEP like MAM and 
exclude certain messages per XEP rule.


We have store hints, the most prominent servers respect these. And it 
would make no sense to not respect it if a client explicitly wishes for 
a message to be stored.
So to make it more clear, if i want to save a message on a current 
prosody or ejabbered MAM implemenation, i can do this as a client with a 
store hint.


you dont have to querry the whole archive, you just querry until you get 
a read marker, then you know everything that comes before that was 
already read so i dont have to query it.



Am 02.12.2016 um 16:34 schrieb Kevin Smith:

On 2 Dec 2016, at 15:26, forenjunkie <forenjun...@chello.at> wrote:

in a single chat conversation, it makes no sense to query unread messages.

I’m not sure that’s true at all, but putting that to the side for the minute...


you could just query the last 10 MAM Messages, if no readmarker comes with it, 
query another 10. such a implementation of MAM would be very weird to me, but 
you could do it and get only unread messages with it. So this already works 
without problem with the MAM and 0333 XEP.
And in single chat its not possible to "miss" a message in between, which you 
would want to query.

I think you’re missing the details of what I asked - how do you achieve this 
where there are a sufficient number of messages that just keeping querying 
until you have every message in your local archive isn’t viable?


And this is not a theory, XEP-0333 are stored by the server if the client 
wishes that, and working implementations of MAM and 0333 together you can 
witness for example in Conversations.

It’s not up to the client whether 333 is stored by the server or not.


All i see in this proposal is adding complexity to the whole process in 
introducing another thing the server has to support.

Referring back to my previous question, can you provide an example of how to 
achieve this case with just 313 and 333 (in protocol)?

/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] Unread syncing

[forenjunkie]

Hi,

in a single chat conversation, it makes no sense to query unread messages.

you could just query the last 10 MAM Messages, if no readmarker comes 
with it, query another 10. such a implementation of MAM would be very 
weird to me, but you could do it and get only unread messages with it. 
So this already works without problem with the MAM and 0333 XEP.
And in single chat its not possible to "miss" a message in between, 
which you would want to query.


And this is not a theory, XEP-0333 are stored by the server if the 
client wishes that, and working implementations of MAM and 0333 together 
you can witness for example in Conversations.


All i see in this proposal is adding complexity to the whole process in 
introducing another thing the server has to support.


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

Re: [Standards] "Self-destruct" message timeout deletion hints

[forenjunkie]

But it doesnt work with a decentral, open source kind of system.

a feature like that depends on the other side deleting the message.

you are lying to your users the minute you offer this feature in your 
client and not show a disclaimer.
you promise the message will self destruct, but you can never be sure, 
because you have no control over the other side.
you would have to show a disclaimer: We dont know if it gets deleted, we 
hope it does.


and who would send sensitive information after reading this disclaimer?

regards
lovetox

Am 01.11.2016 um 18:17 schrieb Chris Ballinger:
Regardless of whether or not "we" think it's a good idea, users are 
starting to demand the feature, especially because it's now present in 
almost every mainstream messaging app.


At some point we will probably implement it because it's a relatively 
simple feature with a lot of demand. When that time comes, I'd like 
other apps to be able to interoperate with us.


On Tue, Nov 1, 2016 at 3:24 AM, Ivan Vučica > wrote:


On Wed, 19 Oct 2016, 19:40 Kim Alvefur, > wrote:


The question becomes why should we standardize something that
only works
in a closed system? 



The reason to standardize is, as with open systems, so that
multiple servers and clients can provide the same feature.

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