re https://mail.jabber.org/pipermail/standards/2019-August/036367.html, do I really want to send directed presences to anybody who initiates an OMEMO discussion with me?
pep.
That means anybody can freely request my presence
pep.
And I guess subscribing to PEP would be the same to some extent?
tomhas left
lksjdflksjdfhas left
bhaveshsguptahas joined
ajhas joined
bhaveshsguptahas left
tomhas joined
bhaveshsguptahas joined
tomhas left
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
Ge0rGhas left
Ge0rGhas joined
bhaveshsguptahas joined
tomhas joined
bhaveshsguptahas left
bhaveshsguptahas joined
wurstsalathas joined
moparisthebesthas left
moparisthebesthas joined
bhaveshsguptahas left
Daniel
Zash: omemo dates back to a time when multiple items in a node wasn't a thing
Daniel
And changing the access model is a later, backward compatible change. Using just one node is not
Daniel
I also find the multiple nodes thing to be ugly but đ¤ˇââď¸
Daniel
tom: some servers also allow you to set the access model server side
tomhas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
Alexhas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
marc0shas left
marc0shas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
larmahas left
bhaveshsguptahas joined
larmahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
pep.
Daniel: no opinion on my question above?
Daniel
pep., on the subscribe / not subscribe?
Daniel
no not really. it is a tough question. i donât have a good answer
pep.
I think I'll be subscribing to PEP manually when I get a message from a non-contact, and unsubscribe when either the user closes the tab, or I disconnect, or if I get a PEP notification and I don't have any tab for them anymore
Daniel
> if I get a PEP notification and I don't have any tab for them anymore
+ not having mutual presence sub
pep.
That opens me to less things I guess? Sending directed presence automatically seems a bit meh privacy-wise? (Or am I missing something)
i follow that logic privacey wise. seems like a lot of hassle
Daniel
plus unclear what happens if Conversations still has a tab open
Daniel
can i subscribe full jid?
pep.
Well that means anybody can get a directed presence from me if they send me some kind of omemo attempt
Zash
You specify the JID to subscribe
Daniel
pep., well in both cases i would first sub/send presence when you want to respond
pep.
Why?
pep.
I would refuse it. I don't want everybody in my contacts
Zash
pep-sub
Zash
I assume
Daniel
yes
Zash
pep-subscription and directed presence
pep.
Ah
Daniel
*or
pep.
Yes
pep.
Or yes
Daniel
so either way it will be a) a little less harmfull privacey wise b) more of a just-in-time / just-if-needed approach
pep.
Ah I see what you mean
pep.
When you want to respond and not when you revive it
pep.
Receive*
Daniel
yes
bhaveshsguptahas left
Zash
User signals intent, so seems fine.
pep.
Also directed presence then? Or do you think it's not useful? (Because there's no associated behaviour yet)
Daniel
i mean the manually pep-sub / pep-unsub is really annoying because later on you will also want to pep-sub to muc participants
Daniel
and then when a notification comes in you have to check for tab open, mutual presence and if you are in a muc with that person
Zash
That will be fragile
Daniel
and if not pep-unsub
pep.
Yeah that sounds annoying
Daniel
yes that will be super fragile
Daniel
that's why i havenât done it yet either
Daniel
that's why i kinda like the simplicity of the directed presence suggestion you had
Daniel
but i also totally see the downsides of that
Daniel
plus if you go the pep-sub route? do you unsub before logoff? do you resub on every login?
pep.
I probably would
Daniel
since you canât really know if you have succesfully subbed in a previous session you will probably have to resub on login anyway
Daniel
so that's a lot of traffic
Daniel
however you want to spin it it's going to be supper annoying
pep.
Hmm, I'm probably not a good example with my ratio of opened public channels vs private ones
bhaveshsguptahas joined
pep.
I think in any case we could make it so that PEP with access_model=open is sent if there is a directed presence. Independently of whether we use it for omemo
pep.
Then maybe someday it'll get better deployment wise
Daniel
> I think in any case we could make it so that PEP with access_model=open is sent if there is a directed presence. Independently of whether we use it for omemo
Yes as I said on list this probably won't hurt. And then some people can do that until we have something better
pep.
That would require a change in the xep right?
pep.
A new disco thing?
Daniel
Maybe we can also be a bit smarter about how we detect new devices. For example when I receive an omemo message from someone with an unknown device id (because they are using it to carbon copy to one of their other devices) I'll try to trigger a device list query again
Daniel
Little things like that
pep.
Right
Ge0rG
Little undocumented things? Even the part about adding all your other device IDs into a message because of implied 0280 isn't really documented.
Daniel
little undocumented things? you mean xmpp?
Ge0rG
No, that's the huge undocumented elephant in the room thing.
Daniel
also not true. from the omemo xep:
> for each intended recipient device, i.e. both own devices as well as devices associated with the contact
pep.
Ge0rG: we all know the omemo xep could be better. There's an effort to document that on the wiki already iirc
pep.
(Looking for it)
pep.
Where was that page again..
Daniel
under tech pages
Ge0rG
We should have a wiki category for Errata or somesuch, and link to it from https://xmpp.org/extensions/
pep.
Daniel: thanks
pep.
Ge0rG: agreed
Ge0rG
luckily, you don't have to be on iteam to create wiki categories
pep.
Then go ahead :p
pep.
Also don't forget to submit your changes to xsf/xmpp.org
pep.
Or xeps
Ge0rG
Also somebody should move the 2020 events from "Recent" into "Upcoming"
pep.
Somebody should
Daniel
i'll do that
Daniel
also gsoc is over, right?
pep.
Yeah, final evaluation is over almost
Ge0rG
Hey, I already did that for https://wiki.xmpp.org/web/index.php?title=Category:Interop more or less.
pep.
There's also the remarks page
Ge0rG
Daniel: please also add https://wiki.xmpp.org/web/Board_and_Council_Elections_2019
pep.
https://wiki.xmpp.org/web/XEP_and_RFC_Remarks
pep.
We could link to that
pep.
Oh that's a thing already
Ge0rG
pep.: wait, is that like a Category page but manually maintained?
bhaveshsguptahas left
pep.
Dunno
pep.
Maybe it's just a page
bhaveshsguptahas joined
pep.
We could make it a category yeah
Ge0rG
pep.: it's a page that contains a list of other pages.
Ge0rG
Yes please
pep.
"Errata"
pep.
Never done that, and I'm on the phone right now (biggest hurdle)
Ge0rG
Category:Errata is good, I think. "Remarks" are slightly more than Errata, but I think it captures the meaing rather well
Ge0rG
pep.: it's actually super-easy, just add the category tag at the bottom of each page, like this: https://wiki.xmpp.org/web/index.php?title=Interop_2010&curid=408&diff=11425&oldid=2346
Ge0rG
pep.: if you can schedule the time to do it in the next days, that would be great.
Syndacehas left
pep.
I like how you give work to others :p
Ge0rG
pep.: finally, move the https://wiki.xmpp.org/web/XEP_and_RFC_Remarks page into https://wiki.xmpp.org/web/index.php?title=Category:Errata
Syndacehas joined
Ge0rG
pep.: "I'm on the phone right now" is a temporary state, and I read that "I'd like to do it, but"
Ge0rG
pep.: also you said at FrOSCon that you have some free time for this kind of things ;)
Not that I don't want to do it, but not right now, also I don't like being told things, so you'll have to be more subtle next time :p
pep.
Your nerdsniping skills could be improved!
Ge0rG
pep.: oh, sorry! It would be really great if somebody volunteered to refactor that page into a wiki category... đ
jonasâ
pep., regarding errata, Iâd be interested in having a consistent naming scheme for that so that I can detect existing pages during xeps builds and add links from XEP -> Errata pages
jonasâ
thereâs an issue for that in the xeps repo
pep.
Seems I'm the goto person now. Ge0rG you can take example on jonasâ
pep.
You can't really guarantee what users will do with page names
pep.
But we can definitely restrict what the build will use
jonasâ
pep., yes, the build needs a URL-template where only the XEP number is a variable.
jonasâ
itâll still be fun & tricky to do because we canât (hopefully) do that in XSLT
pep.
My xslt skills are almost nonexistent anyway
Zash
jonasâ is that a challenge?
Zash
Isn't xslt turing-complete?
jonasâ
Zash, it is, but it cannot request external resources in XSLT 1.0
Zash
Mmmmm, must be some wiki index that can be fetched and used somehow
lksjdflksjdfhas joined
lksjdflksjdfhas left
bhaveshsguptahas left
Ge0rG
jonasâ: would it be insane to have a category for each XEP, and to link to that?
lksjdflksjdfhas joined
jonasâ
Ge0rG, yes, I think so
jonasâ
a page per XEP should do
jonasâ
do you have a concrete example where that isnât sufficient? could we do a redirect to a category in that case?✎
Zashhas left
jonasâ
do you have a concrete example where that isnât sufficient? could we do a redirect to a category in those cases? ✏
Zashhas joined
Ge0rG
jonasâ: it would give us auto-linking of all pages related to a given XEP
jonasâ
Ge0rG, wait, a category per XEP for all XEP-related stuff, or a category per XEP for all errata?✎
jonasâ
Ge0rG, wait, a category per XEP for all XEP-related stuff, or a category per XEP for all errata for that XEP? ✏
jonasâ
a category per XEP for all XEP-related stuff (including a single page which is used for errata) makes sense to me
Ge0rG
jonasâ: a category per XEP and a link from the XEP to that category?
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
pep.
I think it's fine if a page doesn't exist on the wiki
pep.
Just link to it, and people can create it when necessary
Daniel
Zash, does proxy65 have a timeout? between connecting and activation?
Zash
NAFAIK
Zash
Is this a XEP question or a Prosody question?
Daniel
prosody. the xep doesnât say anything in that regard
Zash
I'd have to look at the code but I don't remember any timeout in the module itself.
Zash
There are however socket timeouts that kick in if you're idle for some time and I don't think it has any keepalive logic.
Zash
Also this is not the prosody support room
Daniel
it's a prelude to a broader question that concerns jdev
Daniel
because ejabberd has one and it's causing problems in the way i use proxy65 with jingle
Zash
I imagine that the receiving end could have troubles if they don't say anything for ~14 minutes
Daniel
yeah 14 min is probably fine
Zash
But that's after activatino
Zash
Large files and poor connections (mobile?) could probably reach that
Daniel
so the way i use jingle is that i connect to my own candidates before i send the offer. (because there are chances that i canât reach my own proxy because firewall/missconfiguration and i canât retroactively kill one of my candidates
Zash
But you're talking about a timeout between the inital connection(s) and the activation?
Daniel
so if remote takes it's time to answer my offer, connect to the proxy as well / go through the dance; there might be more time passed than timeout before i can send proxy activate
Daniel
Zash, that's the one
Daniel
but maybe i'm just not understanding jingle
Zash
I thought you could add/change/remove anything at any time, but then I haven't done much Jingle dev either.
Ge0rG
Are there still MUC implementations that don't set status=110 on your reflected join presence?
bhaveshsguptahas left
chinaoceanhas joined
chinaocean
I send xml message to openfire by spark to regieste an account
chinaocean
but Openfire report the error :
chinaocean
<field type="jid-single" label="The Jabber ID for the account to be added" var="accountjid">
<required />
</field>
Zash
Maybe you could pastebin the full stanzas you sent and received?
<iq type="result" id="TQqV7UxKTUq+rBftv6naLA" from="domain" to="admin@domain/aiygy5xatq" xmlns="jabber:client">
<command xmlns="http://jabber.org/protocol/commands" sessionid="RArCgzJpZBzDIse" node="http://jabber.org/protocol/admin#add-user" status="executing">
<x xmlns="jabberâdata" type="form">
<title>Adding a user</title>
<instructions>Fill out this form to add a user.</instructions>
<field type="hidden" var="FORM_TYPE">
<value>http://jabber.org/protocol/admin</value>
</field>
<field type="jid-single" label="The Jabber ID for the account to be added" var="accountjid">
<required />
</field>
<field type="text-private" label="The password for this account" var="password" />
<field type="text-private" label="Retype password" var="password-verify" />
<field type="text-single" label="Email address" var="email" />
<field type="text-single" label="Given name" var="given_name" />
<field type="text-single" label="Family name" var="surname" />
</x>
<actions execute="complete">
<complete />
</actions>
</command>
</iq>
Zash
Is that really how ad-hoc command flow goes?
Zash
https://xmpp.org/extensions/xep-0050.html#execute
chinaocean
i dont know what is the promlem
Zash
Not starting with this step? https://xmpp.org/extensions/xep-0050.html#example-8
Zash
Rougly, for simple commands it goes something like
1. Execute command
2. Receive dataform
3. Submit dataform with values
4. Get result (or another form)
Should a client send 0184 receipts for all messages retrieved from MAM? :>
Zash
Ugh
Zash
Should the server save 184 recepits?
lovetox
yes Ge0rG
lovetox
yes Zash
Ge0rG
Zash: yes
Ge0rG
Zash: also message errors.
lovetox
Ge0rG, you can wait the catchup and see if another client of yours already sent a 0184 receip
lovetox
then you should not send another one
lovetox
as receipts should be account based not resource based
Zash
If receipts are account based then the server should send them
lovetox
Server cant know if client received a message
Zash
and then they change meaning to "saved into recipients archive"
lovetox
receipt means a client successfully processed a message, in my opinion
lovetox
and not "its in some archive"
lovetox
though probably debateable
Ge0rG
I agree with lovetox on that.
Ge0rG
Otherwise I'd have suggested that before.
Ge0rG
But there is real value in "this message arrived at a client", because it means the account isn't abandoned
Ge0rG
I also need a mechanism to delay notifications for MAMed messages.
lovetox
amazing how much more things you have to think about in a client if you implement this rather easy "get me these messages from the archive" XEP :9
Zash
Has 333 been fixed to not duplicate parts of 184 and chat states?
Zash
... yet?
lovetox
nope
lovetox
but also nobody is forced to implement these parts :9✎
lovetox
but also nobody is forced to implement these parts :) ✏
bhaveshsguptahas left
Zash
Nobody is forced to implement 333 at all
bhaveshsguptahas joined
Ge0rG
Sigh. Databases are hard. I want to switch android notifications from live-generated and appended-to, to database based. I'm looking for something like "unread incoming messages", but that conveniently leaves out delivery errors, because those get aggregated into the "outgoing transmitted but failed" messages
Ge0rG
I wonder if an SQLite index on (from_or_to, delivery_status) will even work efficiently for such a query. After all, from_or_to can take both possible values here.