jdev - 2020-05-24

hm if im joined a muc, and change my show, do i have to send the presence also directed at the muc? or is it enough to send it for my account

i know i dont have to if i go offline (unavailable)

lovetox: sending it to your account doesn't update the MUC, so yes, you probably want to send those separately

and this is expected? when i send a unavailable presence, all mucs get updated by the server

but not if i only change show and status, because one would probably send different show and status to those mucs?

I don't think the rules were necessarily created with MUCs in mind

The idea is that you can send directed presence to some entities, separate from your account presence. The only special thing is that if you go offline, the server will "cancel" any directed presence for you

I wanted to add a way to change this rule, negociated by the client with a supported server, and have any non-directed presence also update directed presences.

But never did so yet.

hey, do you know clients that are implementing and using 0012 ? (https://xmpp.org/extensions/xep-0012.html)

we have an (apparently broken) implementation in poezio

i'm wondering how it is actually implemented

like, when are you sending those requests, and how are they refreshed

mathieui, didn’t we switch to XEP-0319?

edhelas, for example if you open a information dialog of a contact

or if you hover for some seconds over a tooltip of a contact

but 0319 is better suited for that obviously

yes, i'm working with that one :)

We talked about removing it from poezio at all

0012

in Gajim i answer to 0012 requests

but i never request it

What do people say about the 402 / autojoin thread btw? More specifically my point on <extension/>, if any exists, don't randomly remove the bookmark

I can PR that to 402

It might be "obvious" for some, but the XEP only mentions preserving when editing

> Clients MUST preserve these (particularly preserving unknown elements) when editing items.

And it doesn't say anything about known elements

pep., IIRC I suggested, in a thread where dwd was also parcipating, special container elements: one for client generated extensions, and one for server generated extensions

this would also solve the cases where clients are unable to replay the elements in the client-generated extensions

That seems orthogonal to my case(?)

potentially, maybe I misinterpreted "my point on <extension/>"

https://mail.jabber.org/pipermail/standards/2020-May/037473.html and https://mail.jabber.org/pipermail/standards/2020-May/037471.html for more context

well <extension/> appears to be such a container for client generated extension elements

and my idea was to extend the protocl so that if a client does not explicitly include <extension/> on publish, the previous/current content of that container is preserved

I'm not sure what definition you're referring to but it's not really defined in 402

exactly, and IIRC there was a previous thread on standards@ how to extend things like bookmarks with custom annotations/(meta-)data ✏

My point is not about edition but removal. dunno if these two can/should be mixed?

Also the fact that extensions seems only to be defined in terms of clients not knowing about stuff inside :p

https://mail.jabber.org/pipermail/standards/2019-November/036640.html

yes I remember this

And I know that's where it comes from :x

pep., I am sorry, then I probably did not understand what "More specifically my point on <extension/>, if any exists, don't randomly remove the bookmark" is asking

Asking if anybody is against a PR specifying <extensions/> a bit more in this regard

402 has no schema. yay

pep., what would that additional specification entail?

I also usally encourage people to just present patches, be it for specs or source code, as those are easier to discuss ;)

Something along the lines of "If there is an extension that you didn't add yourself, don't automatically remove the entry (that is, without explicit user input)."

Isn't that what " Clients MUST preserve these [<extensions/>]" already does?

What about the "when editing items"?

Because I've heard a few client devs ready to remove these items witout blinking

Automatically when the user leaves a room

that sounds like non-compliant behavior

So many things a person can infer from half a specified sentence..

as the client clearly edited the item while not preserving things

Can we not just add a bit more text in there?

well sure

clarifications are always good, and it appears your clarification is within the spirit of the xep

it's just *very* hard to write specifications that are not open to different interpretations

pep., i think you misunderstanding the XEP

how?

because you talk about client devs removing items

of course a client can remove a item if it understand what it does

this is not an eternal archive of xml elements

Well I'll let the user be the judge

they have a purpose, one client puts an extension in, and another client can remove it

maybe thats the problem, you think this is some kind of User added thing?

lovetox, sure, that is not what I'm saying. I just don't want clients randomly removing items when leaving a room or sth (because the whole point of all our "bookmark" XEPs is to be client sync mechanisms)

(and I stand by this statement)

random? i dont know what you talking about

That's why I'm not comfortable hacking profiles on top of 402

if i unset the autojoin flag on a bookmark is this random for you?

so why would it if i modify an element in the extension node?

Ok remove the "random"

To me, a user leaving a room doesn't justify removing the item

I want the dumb list of bookmarks to be separated from the autojoin mechanism

but why? so we have to query more for the same functionality?

hmm?

if you want that make a proposal

but extension elements can be added by clients, and can of course be removed by them, this has nothing to do with profiles

Well if I could modify 402 right now to be a dumb list of bookmarks and a separate sync mechanism I would do it. But it's draft and I'm sure I'll get quite a few grumps

(so it's not "yet another bookmarks xep")

so you dont want the bookmarks in PEP?

No that's not the point

I want real bookmarks

And maybe a separate syncing mechanism :)

do you think when i talked about removing a item i talked about a bookmark?

what else?

nobody removes bookmarks on leave

we set the autojoin flag to false

but dont remove the bookmark

which sounds sensible IMHO

if you have now profiles, the autojoin flag is not enoguh anymore

Well apparently some do, (or would), and I'm just trying to prevent that

so you add a <profile name=mobil> into the extension

which means, all clients that have this profile treat this like a autojoin flag

I'm fine with switching autojoin off. It still irks me that 402 is just another client sync mechanism but I can live with it if I have guarantees

if such a client now leaves the MUC, he removes that profile node

not the whole bookmark

so other clients that have the profile dont join the MUC anymore

yeah

but client that dont have the profile can still honor the not modified autojoin flag

and that was just an idea out of the top of my head, if you have better proposal please come forward

yeah your proposal seemed fine, with the small detail I added in

but i want to state, nobody wants to delete bookmarks :)

but pep. everything you but in PEP is a sync thing or not?

thats why PEP exists to sync shit

I guess you're missing my point

PEP is fine

yeah i also think that, you want a "real" bookmark list?

Just a dumb bookmark list. without autojoin.

dont know what this means, nobody deletes automatically bookmarks, so why would that not be a real bookmark list?

why without autojoin? what do you gain if this is not in the XEP?

can you not simply ignore it?

no because it changes the meaning of the XEP

I can ignore the huge monster in front of me and live my life as usual, that doesn't remove the huge monster in front of me (ish)

Now, as I said above, I'm happy with what you suggested in the thread. It doesn't change the underlying semantics to me, but that works

There was a funny manga about that. :D

Where a girl who can see monsters tries to ignore them but is scared by them anyway.

pep., i dont even care about that, i dont even own a smartphone, and im joined 10 MUCs, i dont need profiles

i just out of interest want to understand what you think :)

I don't especially have the same usage of phones or desktop / console clients

i see autojoin as something you can ignore, other clients will modify it, but it will not change your bookmark list

lovetox, I would still have use for autojoin, I just don't think it fits in bookmarks and should be separate

Then you can have pointers to these bookmarks etc. and do howmanyxeps you want

but that would be a pain in the ass with race conditions

a bookmark list in pep, and then a autojoin list in pep

i really dont want to think about it ^^ ✏

Maybe the whole thing is flawed :x

no it works fine, just be fine with it :)

I'll "just" ignore this message :p

I can't think of a proper name otherwise I'd propose something else for 402

To reflect the semantics

great

now is sleep time, good night

:)