jdev - 2019-09-02

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?

That means anybody can freely request my presence

And I guess subscribing to PEP would be the same to some extent?

Zash: omemo dates back to a time when multiple items in a node wasn't a thing

And changing the access model is a later, backward compatible change. Using just one node is not

I also find the multiple nodes thing to be ugly but 🤷‍♂️

tom: some servers also allow you to set the access model server side

Daniel: no opinion on my question above?

pep., on the subscribe / not subscribe?

no not really. it is a tough question. i don’t have a good answer

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

> if I get a PEP notification and I don't have any tab for them anymore + not having mutual presence sub

That opens me to less things I guess? Sending directed presence automatically seems a bit meh privacy-wise? (Or am I missing something)

Yee

Yes ✏

(I'm not drunk, honest)

i follow that logic privacey wise. seems like a lot of hassle

plus unclear what happens if Conversations still has a tab open

can i subscribe full jid?

Well that means anybody can get a directed presence from me if they send me some kind of omemo attempt

You specify the JID to subscribe

pep., well in both cases i would first sub/send presence when you want to respond

Why?

I would refuse it. I don't want everybody in my contacts

pep-sub

I assume

yes

pep-subscription and directed presence

Ah

*or

Yes

Or yes

so either way it will be a) a little less harmfull privacey wise b) more of a just-in-time / just-if-needed approach

Ah I see what you mean

When you want to respond and not when you revive it

Receive*

yes

User signals intent, so seems fine.

Also directed presence then? Or do you think it's not useful? (Because there's no associated behaviour yet)

i mean the manually pep-sub / pep-unsub is really annoying because later on you will also want to pep-sub to muc participants

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

That will be fragile

and if not pep-unsub

Yeah that sounds annoying

yes that will be super fragile

that's why i haven’t done it yet either

that's why i kinda like the simplicity of the directed presence suggestion you had

but i also totally see the downsides of that

plus if you go the pep-sub route? do you unsub before logoff? do you resub on every login?

I probably would

since you can’t really know if you have succesfully subbed in a previous session you will probably have to resub on login anyway

so that's a lot of traffic

however you want to spin it it's going to be supper annoying

Hmm, I'm probably not a good example with my ratio of opened public channels vs private ones

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

Then maybe someday it'll get better deployment wise

> 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

That would require a change in the xep right?

A new disco thing?

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

Little things like that

Right

Little undocumented things? Even the part about adding all your other device IDs into a message because of implied 0280 isn't really documented.

little undocumented things? you mean xmpp?

No, that's the huge undocumented elephant in the room thing.

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

Ge0rG: we all know the omemo xep could be better. There's an effort to document that on the wiki already iirc

(Looking for it)

Where was that page again..

under tech pages

We should have a wiki category for Errata or somesuch, and link to it from https://xmpp.org/extensions/

Daniel: thanks

Ge0rG: agreed

luckily, you don't have to be on iteam to create wiki categories

Then go ahead :p

Also don't forget to submit your changes to xsf/xmpp.org

Or xeps

Also somebody should move the 2020 events from "Recent" into "Upcoming"

Somebody should

i'll do that

also gsoc is over, right?

Yeah, final evaluation is over almost

Hey, I already did that for https://wiki.xmpp.org/web/index.php?title=Category:Interop more or less.

There's also the remarks page

Daniel: please also add https://wiki.xmpp.org/web/Board_and_Council_Elections_2019

https://wiki.xmpp.org/web/XEP_and_RFC_Remarks

We could link to that

Oh that's a thing already

pep.: wait, is that like a Category page but manually maintained?

Dunno

Maybe it's just a page

We could make it a category yeah

pep.: it's a page that contains a list of other pages.

Yes please

"Errata"

Never done that, and I'm on the phone right now (biggest hurdle)

Category:Errata is good, I think. "Remarks" are slightly more than Errata, but I think it captures the meaing rather well

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

pep.: if you can schedule the time to do it in the next days, that would be great.

I like how you give work to others :p

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

pep.: "I'm on the phone right now" is a temporary state, and I read that "I'd like to do it, but"

pep.: also you said at FrOSCon that you have some free time for this kind of things ;)

That I'm using fully, don't worry about me ✏

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

Your nerdsniping skills could be improved!

pep.: oh, sorry! It would be really great if somebody volunteered to refactor that page into a wiki category... 😇

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

there’s an issue for that in the xeps repo

Seems I'm the goto person now. Ge0rG you can take example on jonas’

You can't really guarantee what users will do with page names

But we can definitely restrict what the build will use

pep., yes, the build needs a URL-template where only the XEP number is a variable.

it’ll still be fun & tricky to do because we can’t (hopefully) do that in XSLT

My xslt skills are almost nonexistent anyway

jonas’ is that a challenge?

Isn't xslt turing-complete?

Zash, it is, but it cannot request external resources in XSLT 1.0

Mmmmm, must be some wiki index that can be fetched and used somehow

jonas’: would it be insane to have a category for each XEP, and to link to that?

Ge0rG, yes, I think so

a page per XEP should do

do you have a concrete example where that isn’t sufficient? could we do a redirect to a category in those cases? ✏

jonas’: it would give us auto-linking of all pages related to a given XEP

Ge0rG, wait, a category per XEP for all XEP-related stuff, or a category per XEP for all errata for that XEP? ✏

a category per XEP for all XEP-related stuff (including a single page which is used for errata) makes sense to me

jonas’: a category per XEP and a link from the XEP to that category?

I think it's fine if a page doesn't exist on the wiki

Just link to it, and people can create it when necessary

Zash, does proxy65 have a timeout? between connecting and activation?

NAFAIK

Is this a XEP question or a Prosody question?

prosody. the xep doesn’t say anything in that regard

I'd have to look at the code but I don't remember any timeout in the module itself.

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.

Also this is not the prosody support room

it's a prelude to a broader question that concerns jdev

because ejabberd has one and it's causing problems in the way i use proxy65 with jingle

I imagine that the receiving end could have troubles if they don't say anything for ~14 minutes

yeah 14 min is probably fine

But that's after activatino

Large files and poor connections (mobile?) could probably reach that

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

But you're talking about a timeout between the inital connection(s) and the activation?

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

Zash, that's the one

but maybe i'm just not understanding jingle

I thought you could add/change/remove anything at any time, but then I haven't done much Jingle dev either.

Are there still MUC implementations that don't set status=110 on your reflected join presence?

I send xml message to openfire by spark to regieste an account

but Openfire report the error :

<field type="jid-single" label="The Jabber ID for the account to be added" var="accountjid"> <required /> </field>

Maybe you could pastebin the full stanzas you sent and received?

in fact , i have trasfered the JID parameter

<iq id="TQqV7UxKTUq+rBftv6naLA" from="admin@domain" type="set" to="domain" xmlns="jabber:client"> <command node="http://jabber.org/protocol/admin#add-user" xmlns="http://jabber.org/protocol/commands"> <x type="submit" xmlns="jabber❌data"> <field var="FORM_TYPE" type="hidden"> <value>http://jabber.org/protocol/admin</value> </field> <field var="accountjid" type="jid-single"> <value>hahaha@domain</value> </field> <field var="password" type="text-private"> <value>123456</value> </field> <field var="password-verify" type="text-private"> <value>123456</value> </field> </x> </command> </iq>

the stanza i 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>

Is that really how ad-hoc command flow goes?

https://xmpp.org/extensions/xep-0050.html#execute

i dont know what is the promlem

Not starting with this step? https://xmpp.org/extensions/xep-0050.html#example-8

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)

https://xmpp.org/extensions/xep-0050.html#example-8

it is OK

<iq to="admin@domain/Spark" id="isxaf-87" type="result"> <query xmlns="jabber:iq:private"> <scratchpad xmlns="scratchpad:tasks"> <tasks showAll="true"/> </scratchpad> </query> </iq>

i received this message

That looks unrelated

??

what shall i do ?

I don't know, I can't help you with that

thks!

<iq to="admin@domain/Spark" from="responder@domain" id="exec1" type="error"> <error type="cancel"> <item-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> </error> </iq>

it return like this

If that's in reply to a command then I would guess that you forgot the session id

Is there no library functions for dealing with ad-hoc commands?

MatriX

I've never used that, so I can't answer that question

you remind me: sessionid

i send a guid , the result is like this

<error code="400" type="modify"> <bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" /> </error>

The server includes it in the initial response

openfire didnot repost the JID error

how to get the sessionid?

https://xmpp.org/extensions/xep-0050.html#desc-command

It was in the first response you sent earlier

Save it and use it in the next request

i know.

i create an unique id as a seesion id

and i will received a stanza like this

<iq type="error" id="add-user_00001" from="domain" to="admin@domain/7154tif52" xmlns="jabber:client"> <command xmlns="http://jabber.org/protocol/commands" node="http://jabber.org/protocol/admin#add-user" sessionid="6ff594373fd6437aa8ac3439ebe83ae5"> <x xmlns="jabber❌data" type="submit"> <field var="FORM_TYPE" type="hidden"> <value>http://jabber.org/protocol/admin</value> </field> <field var="accountjid" type="jid-single"> <value>hahaha@domain</value> </field> <field var="password" type="text-private"> <value>123456</value> </field> <field var="password-verify" type="text-private"> <value>123456</value> </field> </x> </command> <error code="400" type="modify"> <bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" /> </error> </iq>

Should a client send 0184 receipts for all messages retrieved from MAM? :>

Ugh

Should the server save 184 recepits?

yes Ge0rG

yes Zash

Zash: yes

Zash: also message errors.

Ge0rG, you can wait the catchup and see if another client of yours already sent a 0184 receip

then you should not send another one

as receipts should be account based not resource based

If receipts are account based then the server should send them

Server cant know if client received a message

and then they change meaning to "saved into recipients archive"

receipt means a client successfully processed a message, in my opinion

and not "its in some archive"

though probably debateable

I agree with lovetox on that.

Otherwise I'd have suggested that before.

But there is real value in "this message arrived at a client", because it means the account isn't abandoned

I also need a mechanism to delay notifications for MAMed messages.

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

Has 333 been fixed to not duplicate parts of 184 and chat states?

... yet?

nope

but also nobody is forced to implement these parts :) ✏

Nobody is forced to implement 333 at all

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

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.