Ge0rG: ah ok, I didn't remember the outcome but I remembered there was something about it
winfriedhas left
winfriedhas joined
Alexhas left
adiaholichas left
mukt2has left
zachhas left
zachhas joined
Alexhas joined
lovetox_has joined
Nekithas left
zachhas left
zachhas joined
Mikaelahas joined
chronosx88has left
chronosx88has joined
LNJhas left
ajhas left
Sevehas joined
Vaulorhas joined
adiaholichas joined
wurstsalathas joined
adiaholichas left
adiaholichas joined
adiaholichas left
adiaholichas joined
j.rhas left
zachhas left
zachhas joined
j.rhas joined
lovetox_
lately i ran into following problem with the MUC protocol
lovetox_
send a presence to a MUC
lovetox_
Muc does not answer for 20 seconds
lovetox_
i give the user a option to abort this join (close the window or whatever)
lovetox_
only this does not reflect the truth, i have not really a possibility to abort the join
lovetox_
so user presses abort, and naturally tries again to join the room
lovetox_
another presence is sent out, now suddenly server responds to the first presence, sends stuff, then does the same for the second presence
lovetox_
i have no possibility to know what happend because of first presence, and what happens because of last presence
lovetox_
now i could send a presence unavailable on first abort
lovetox_
this brings me into even more trouble, now the server sends all presences, then disconnects me from the muc, then starts again to send stuff
lovetox_
all in all nothing i want to really deal with
lovetox_
maybe i should remove the abort button
lovetox_
there is no aborting a muc join
Ge0rG
lovetox_: modern MUCs will treat a join presence (with an x element) as a request for a full sync.
Ge0rG
And yes, there is no way to abort anything in xmpp land.
Ge0rG
Which is why it's silly to have things end in a hard timeout.
goffihas joined
lovetox_
then this muc join is in limbo and if a user complains i just tell him server should answer eventually
Ge0rG
OTOH some network conditions may well lead to a request getting black holed.
Ge0rG
So that the MUC doesn't even know that you tried joining.
mukt2has joined
Ge0rG
This can be solved with s2s 0198, which nobody has ever tested.
larmahas left
Ge0rG
Because you know, TCP is a reliable protocol
jonas’
lovetox_, the second presence with <x/> should not screw up anything in the scenario you described
jonas’
in fact, I think it should be safe to re-send join presences with exponential back off similar to how TCP sends SYNs
larmahas joined
mukt2has left
j.rhas left
zachhas left
zachhas joined
kokonoehas left
jonas’
Kev, pinging you again regarding the hub.docker.com stuff. You seem to be the only one active who has the permissions.
adiaholichas left
Ge0rG
jonas’: but one needs to know where the old join ends and the new one starts.
adiaholichas joined
Ge0rG
Maybe we need a unique ID on the join stanza, and the server ignoring duplicates?
j.rhas joined
emushas joined
jubalhhas joined
sonnyhas left
flow
> Ge0rG> jonas’: but one needs to know where the old join ends and the new one starts.
do you?
jonas’
Ge0rG, that’d be great
zachhas left
zachhas joined
jonas’
Ge0rG, flow, not in the scenario lovetox_ described, I think. You’d get (a) a full initial set of presence, (b) all presence hcanges between a and c, and (c) another full set of initial presence
jonas’
there’s quite a bit of redundancy, but the state should be correct and complete
jonas’
although, it will be confusing if you requested MUC history
Mikaelahas left
Mikaelahas joined
COM8has joined
flow
jonas’, i'd guessed and hoped that something like that happens, but of course this could be MUC service (and client) implementation dependent. But nevertheless joining and (potentially other MUC actions) could and should get improved, and we should consider those things in groupchat-ng protocols
jcbrandhas joined
kokonoehas joined
Danielhas left
COM8has left
lskdjfhas joined
Danielhas joined
jubalhhas left
pdurbinhas joined
jcbrandhas left
emushas left
jubalhhas joined
Ge0rG
If only somebody thought that through for MIX
Shellhas left
zachhas left
zachhas joined
jonas’
mix is at least a step forward in that regard
jonas’
that we don’t have a proper solution for s2s failures yet is a problem, indeed
jonas’
but that’s not a problem unique to mix or muc actually
Danielhas left
Ge0rG
We also need something for mobile clients that are killed after 10s in the background. A solution that doesn't involve persisting all runtime state, MUCs, and contact presence to disk
Danielhas joined
Zash
Can you really fix that with protocol design?
jonas’
"WhatsApp works"
Ge0rG
Zash: yes
andyhas joined
Ge0rG
With roster versioning, no presence broadcast and MAM we already have a moderately expensive solution. We now only need to replace presence with a PEP based status thing, as suggested by Kev.
Douglas Terabytehas joined
Ge0rG
BTW, what are the rules for delivering subscription requests to clients that don't send presence?
jonas’
"don’t"?
Ge0rG
Oh, and the above thing doesn't include MUC. We don't have a solution for that yet
jonas’
Instead, if a subscription request
requires approval then the contact's server MUST deliver that
request to the contact's available resource(s) for approval or
denial by the contact.
4. Otherwise, if the contact has no available resources when the
subscription request is received by the contact's server, then
the contact's server MUST keep a record of the complete presence
stanza comprising the subscription request, including any
extended content contained therein (see Section 8.4 of
[XMPP-CORE]), and then deliver the request when the contact next
has an available resource.
jubalhhas left
eevvoorhas joined
Zash
It's XMPP, not XMP
jonas’
Ge0rG, MIX would help in that regard, because it’s the user’s server which fully manages the joins
jonas’
and those will be in a PEP node in the future so that you’re kept up-to-date to some extent.
rion
SIMS xep says "The file element is the same as from Jingle File Transfer (XEP-0234) [2]. It MUST specify media-type, size, description, and one or multiple hash elements"
Is "description" element really MUST?
Ge0rG
jonas’: yes, it's an improvement indeed. But will you get differential updates on the member list?
and supposedly there’s a way to MAM-query PubSub nodes, although I never understood how
jonas’
supposedly the MAM archive of a PubSub node would be the history of messages it sent✎
jonas’
supposedly the MAM archive of a PubSub node would be the history of notification messages it sent ✏
jonas’
in which case, yes.
Ge0rG
Is it a one item node like old bookmarks?
jonas’
I don’t think so
jonas’
> Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node.
Ge0rG
Zash: I'm sure we can figure out a way
flow
rion, appears so
mr.fisterhas left
Ge0rG
I don't think it makes much sense, though
flow
rion, although that appears to be not in line with xep234
flow
or, at least, I would expect that SIMS would require at least media-type, size and name (not description)
rion
Agreed
pdurbinhas left
Ge0rG
In JFT, the <description> is the required container element, and the description text is in the optional <desc> element
Ge0rG
So what are we talking about?
rion
<desc>
flow
which we may should rename to something like <description-text/>
j.rhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
mukt2has joined
zachhas left
zachhas joined
marc_has joined
mukt2has left
Yagizahas left
lovetox_
jonas, the problem is the UI with my scenario
lovetox_
of course a library in itself would have the correct state after 2 joins
COM8has joined
j.rhas joined
lovetox_
but having the UI display the correct state is the challenge
COM8has left
lovetox_
and yes it would be very helpful if we could add a unique join id to the presence, which is replicated on while joining on all the presences
lovetox_
i dont see a problem with subject and messages, you got to have message deduplication anyway
goffihas left
goffihas joined
lovetox_
hm presences should also not be a problem, i could just update the ones i have already in my roster
lovetox_
the real problem for me is that i dont know when the MUC join is finished
lovetox_
normally i display a "joining.." label
jonas’
lovetox_, you know it’s finished when you get the <subject/>
lovetox_
now i abort my first join, open the window again in haft of the first join, now i have half of all presences, then this join completes, i show the UI
lovetox_
but then the second join starts
jonas’
the second join is fully deduplicated, isn’t it?
lovetox_
yes .. still my plan was to *not* show the groupchat UI *while* joining
adiaholichas left
adiaholichas joined
LNJhas joined
lovetox_
so the first join signals my UI join completed, i show the UI with probably half of the users
lovetox_
then second join starts
Danielhas left
lovetox_
but yeah think these are edge cases
lovetox_
still a simple IQ flow would be much better
lovetox_
where i get at the end a IQ join=complete
lovetox_
like with mam
Danielhas joined
Zash
How is that different from subject?
lovetox_
because the subject only tells you *a* join completed
lovetox_
not which one
lovetox_
of the 3 you send, while the server didnt answer
Zash
right
Zash
It should still be idempotent tho?
lovetox_
idempotent?
Zash
If you get a second join result it should just set everything to the existing values
emushas joined
Zash
But wouldn't you be able to identify which join is which by looking at your own presence?
goffihas left
lovetox_
would i?
lovetox_
does the self presence has the same id as the join presence?
lovetox_
as we determined before, state should be correct even on 2 joins
lovetox_
the problem that i have is the first join signals my UI im finished, when i reality the second is still in progress
lovetox_
i think this is only solveable if we would have some identifier in the join presence, which is at some point returned
lovetox_
i think how muc join was made is a anti-pattern, much better to make things clear with IQs
Zash
I tend to agree
goffihas joined
Ge0rG
It's significantly improved over GC1.0 still
Zash
Yes
zachhas left
j.rhas left
zachhas joined
jonas’
ITYM Xabber Group Chat
debaclehas joined
winfriedhas left
winfriedhas joined
j.rhas joined
j.rhas left
zachhas left
zachhas joined
winfriedhas left
winfriedhas joined
j.rhas joined
adiaholichas left
gavhas left
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
zachhas left
zachhas joined
pdurbinhas joined
winfriedhas left
winfriedhas joined
gavhas joined
adiaholichas joined
gavhas left
pdurbinhas left
sonnyhas left
sonnyhas joined
mukt2has joined
kokonoehas left
kokonoehas joined
zachhas left
zachhas joined
mukt2has left
Chobbeshas joined
j.rhas left
adiaholichas left
adiaholichas joined
zachhas left
zachhas joined
adiaholichas left
adiaholichas joined
j.rhas joined
Chobbeshas left
gavhas joined
j.rhas left
zachhas left
zachhas joined
Danielhas left
COM8has joined
Danielhas joined
mimi89999has left
j.rhas joined
COM8has left
COM8has joined
winfriedhas left
COM8has left
winfriedhas joined
karoshihas left
karoshihas joined
adiaholichas left
zachhas left
zachhas joined
adiaholichas joined
Mikaelahas left
Mikaelahas joined
Shellhas joined
j.rhas left
adiaholichas left
zachhas left
zachhas joined
kokonoehas left
jubalhhas joined
Danielhas left
jubalhhas left
Danielhas joined
j.rhas joined
!XSF_Martinhas left
adiaholichas joined
debaclehas left
!XSF_Martinhas joined
pdurbinhas joined
adiaholichas left
zachhas left
zachhas joined
davidhas left
j.rhas left
Nekithas joined
j.rhas joined
Tobiashas left
Tobiashas joined
kokonoehas joined
adiaholichas joined
jmpmanhas joined
jubalhhas joined
pdurbinhas left
zachhas left
zachhas joined
Syndacehas left
mukt2has joined
Zash
Does anything use the 'continue' error type?
Zashlooks at https://xmpp.org/extensions/xep-0310.html#mucoccupant
adiaholichas left
Syndacehas joined
Zash
Might be nice to send some "keep calm and wait while we establish s2s"
jubalhhas left
mukt2has left
jubalhhas joined
Tobiashas left
Tobiashas joined
adiaholichas joined
zachhas left
zachhas joined
kokonoehas left
adiaholichas left
Nekithas left
jubalhhas left
mukt2has joined
jubalhhas joined
davidhas joined
zachhas left
zachhas joined
adiaholichas joined
xalekhas joined
zachhas left
zachhas joined
jubalhhas left
adiaholichas left
adiaholichas joined
chronosx88has left
chronosx88has joined
kokonoehas joined
waqashas joined
kokonoehas left
mimi89999has joined
kokonoehas joined
zachhas left
zachhas joined
jubalhhas joined
andyhas left
mukt2has left
kokonoehas left
mukt2has joined
jubalhhas left
rionhas left
rionhas joined
andyhas joined
mukt2has left
andyhas left
zachhas left
zachhas joined
mukt2has joined
andyhas joined
kokonoehas joined
jmpmanhas left
adiaholichas left
adiaholichas joined
mukt2has left
adiaholichas left
jubalhhas joined
adiaholichas joined
mukt2has joined
adiaholichas left
mukt2has left
jubalhhas left
adiaholichas joined
adiaholichas left
chronosx88has left
adiaholichas joined
kokonoehas left
kokonoehas joined
larma
Anyone had a chance to check my last weeks mail https://mail.jabber.org/pipermail/standards/2019-September/036495.html ?
!XSF_Martinhas left
derdanielhas joined
chronosx88has joined
adiaholichas left
kokonoehas left
!XSF_Martinhas joined
adiaholichas joined
pdurbinhas joined
mukt2has joined
jubalhhas joined
kokonoehas joined
pdurbinhas left
lovetox_
yeah also thought this would get at least one response :/
Zash
Multi-session-nick is fairly underspecified
Zash
larma, vcards have been public, so I'd say "no" to that part
andrey.ghas left
zachhas left
zachhas joined
mukt2has left
jonas’has left
jonas’has joined
jubalhhas left
lovetox_
Zash i think it would be nice if prosody adds a "Dont route IQs to other participants" room config option
lovetox_
ejabberd has this
Zash
File an issue. I also want to be able to disable PMs.
lovetox_
yes
mukt2has joined
Zash
Would that be full JID routing or also break all vcards?
lovetox_
of course it would break vcard, and thats actually exactly the use case
lovetox_
:)
lovetox_
1. routing just is doesnt work good or is underspecified for the multi session nick thing
lovetox_
2. its a privacy issue
eevvoorhas left
kokonoehas left
lovetox_
even more so now that prosody even routes it to the pubsub component
jonas’
prosody just routes (some IQs) to the bare JID
lovetox_
or rather the pubsub component answers for the user
jonas’
you mean PEP?
lovetox_
yes
Zash
No, it routes to the bare JID
jonas’
I wouldn’t call that "pubsub component" to avoid confusion
Zash
It was ejabberd that answers vCard requests to full JIDs
Zash
iric
Zash
iirc*
lovetox_
which is correct if you go by the XEP isnt it?
Zash
wat
lovetox_
the vcard xep says server should answer it for the user
Zash
wat
lovetox_
otherwise how would you request a vcard of an offline user?
jonas’
lovetox_, ask the bare JID?
Zash
wat
lovetox_
look either we want vcard in muc to work nicely, than a server should answer any vcard request for the user bare or full jid
lovetox_
or we dont want it in a muc (anon maybe), then the muc should not even start to route IQs
Zash
If the XEP says that the server should respond to requests to full JIDs then the XEP is wrong and diverges from how everything else in XMPP works.
lovetox_
no it says to respond to bare jid
lovetox_
and how is this ever going to work in MUC?
lovetox_
how can i address your bare jid in a anon room?
Zash
You can't.
Zash
Server can forward the request to your bare JID, like Prosody does
lovetox_
and you do this now for any IQ request
Zash
No, only for a small set of known namespaces, namely vcard-temp, pubsub and vcard4.
lovetox_
yeah and you dont see this as a problem?
Zash
No
lovetox_
this is nowhere specificed, its a hack
lovetox_
and one that is a privacy issue on top
Zash
As was the vcard-temp routing thing.
Zash
However that's considered public data
lovetox_
i consider it public data to people who know my adress
Zash
Don't put it in your globally public vcard then
Zash
What is the point of the JABBERID field?
mukt2has left
lovetox_
As i said its fine for people who know my adress, if i join a anon room, the point of the room is exactly to prevent people getting my real adress, but now it seems they dont even need it, because the server is happily routing to the bare jid and giving me the answer
lovetox_
im not saying we should prevent routing IQs, it just should be revisited for public anon rooms
lovetox_
and for non-anon rooms you dont have to route IQs at all
lovetox_
clients should just request the real bare jid
lovetox_
so who needs these public anon rooms that compromise the privacy of their participants? What use case do they fullfill exactly
lovetox_
You want Avatars, public omemo keys, other *private* data, then make your room non-anon and every user that joins knows what he gets into
lovetox_
this idea, i make my room anon, but still keep all features of non-anon rooms, is a bad solution
lovetox_
and i would argue its to the disadvantage of all users that join
Zash
I think you exaggerate the privacy impact somewhat.
Zash
I also never said I was against having this as a setting.
pep.
I don't think saying "public vcard is a privacy issue" is an eggageration :x
Zash
Don't put stuff there if you don't want it public for everyone everywhere, which is how vcard-temp works.
kokonoehas joined
jonas’
to be fair, I was also surprised that my avatar is exposed in anon MUCs
Zash
We got tons of complaints IIRC when we made vcards (via the PEP-conversion stuff) respect the privacy settings of the corresponding PEP nodes.
Zash
So, people have varying expectations.
pep.
Ah that reminds me I need to open an issue about that
lovetox_
yes Zash, thats because we did water down anon rooms, so people dont even know anymore what they are there for
Zash
Now Prosody makes those public by default, but still respects it if you change their settings.
pep.
Prosody still broadcasts my avatar hash in the presence even though I have access_model of vcard4 set to presence
pep.
in MUCs*
Zash
avatar and vcard4s are separate nodes tho
pep.
k
Zash
And you can have separate permissions. I do, in fact.
pep.
I also do have that node set to presence I think
Zash
If you query my vcard through here you only get the avatrarwavatar
lovetox_
And Zash, im not arguing against prosody here, this issue was raised by larma on the last sprint, and we discussed it, and now try to raise awareness in the community
lovetox_
so even if the discussion started with me, asking you for these settings, its more of a general discussion
Zash
Some of the problem is that there are two separate issues
lovetox_
in my opinion we should make the consequences clear what anon means, and follow through with it
Zash
Or more?
lovetox_
not try and find ways how we can water down anon
lovetox_
how we can bring features to anon that can not work with anon
mimi89999has left
Zash
You mean semi-anon? True anon rooms is dead afaik.
kokonoehas left
lovetox_
yeah of course
lovetox_
i would not go that route arguing true anon is not possible so also fuck semi-anon
Zash
I feel like this is a topic for a summit, rather than late saturday. :)
lovetox_
there is a good usecase for semi-anon
lovetox_
but just to be clear, there is no XEP or RFC that tells a muc to route IQs to the bare jid is it?
As I mentioned, you can fiddle with access control on the avatar and vcard4 nodes to do nice things.
lovetox_
so if i set it to presence, then my avatar is hidden
pep.
Maybe we need to add something like "also adjust presence broadcast if a user decides to use something else than open
jonas’
I always forget whether directed presence counts for `presence` or not
Zash
jonas’: not
jonas’
k
lovetox_
yeah fine workaround, im of the opinion we should deactivate IQ routing in anon rooms by default
jonas’
lovetox_, I tend to agree with that
Zash
"presence" is an awkward name for it since it's based on roster (presence) subscriptions
larma
The whole privacy model of vcard and public pep is based on the idea that a person still needs to know your real jid to access them. With semi-anon MUCs that's not the case anymore. Especially in prosodys now also routing pubsub IQs such that they can actually be replied by the server means that I only have two options: Not use OMEMO with non-roster contacts *or* reveal my identity in every semi-anon MUC
larma
(I would probably opt for the first, if not every client would now by default make OMEMO pep nodes public)
lovetox_
Zash, whats the motiviation behind not allowing PMs?
zachhas left
zachhas joined
Zash
lovetox_, ever had people join your support room and then PM you support questions?
Zash
IIRC it's also been requested by others. Don't remember their motivation. I'm sure there's use for it.
Danielhas left
Danielhas joined
jonas’
I would like to turn off PMs as a user right now.
larma
My problem is that I can not rely in any way on IQ routing in semi-anon MUCs, because behavior is diverting between servers. That's why we should at least define the correct behavior. And IMO correct behavior is not to randomly send some IQs to bare and some to full JID
Danielhas left
wurstsalathas left
Danielhas joined
jonas’
larma, I agree on the first part, but I’m not sure on the second part
jonas’
although if we had to pin it down one way, I’d say "route to bare JID"
Danielhas left
Danielhas joined
wurstsalathas joined
larma
Well, if we say some IQs are routed to bare and some to full, we would need servers to somehow indicate what they are doing, because it might update...
jonas’
similar to how we version carbon rules at the moment, indeed
lovetox_
larma, server should add a config options to muc, default to not route IQs, and advertise the setting in disco info
lovetox_
then the client can warn its users before joining such a anon but still routing IQs MUC
chronosx88
Hey, guys. Does MAM support for chat room state changes? (E.g. chat room name or subject)
larma
lovetox_, yes that would work
jonas’
chronosx88, subject yes, name not
Zash
Does it?
chronosx88
And how offline user will know, that room name is changed?
lovetox_
jonas, i dont think subject changes are in MAM
jonas’
lovetox_, oh
derdanielhas left
jonas’
chronosx88, I guess you’d query that when you rejoin the room
chronosx88
Ehm...
lovetox_
chronosx88, you do a disco info to the muc before you join
lovetox_
and if the room name changes, the muc has to issue a status code for changed configuration
lovetox_
which should trigger your client to do again a disco info to get the new name
chronosx88
I just comparing XMPP and Matrix by technical abilities and simplicity
debaclehas joined
lovetox_
MAM is a message archive, it does not hold any configuration infos of MUCs
lovetox_
all configuration info is available via disco info to the muc jid
lovetox_
and all changes to the configuration are announced via message to joined and even not joined participants
lovetox_
(if they are in the member list of a muc=)
chronosx88
And... How it can synchronized when user didn't open client?
lovetox_
and you should disco info a muc before you join if you certain configuration fields like muc name are important to you
chronosx88
> And... How it can synchronized when user didn't open client?
Or really is offline.
lovetox_
im not sure what you mean, if you are offline per definition nothing can be synced
lovetox_
because you are offline
chronosx88
Yeah
lovetox_
if you start your client, and join the rooms the user was in last time
lovetox_
before you join, the client sends a disco info to the muc, to get the current configuration
pdurbinhas joined
lovetox_
you could call that the "sync"
chronosx88
Ok
lovetox_
from that point on if you are joined, and configuration changes while you are online and joined
lovetox_
the muc informs you about it
Nekithas joined
chronosx88
Another question: how I can sync unread messages count between clients?
lovetox_
your best bet is XEP-0333 chat markers
Danielhas left
chronosx88
And point in chat room, when I last time stopped reading
Danielhas joined
chronosx88
> your best bet is XEP-0333 chat markers
Hm... Ok, will read it
lovetox_
where you stopped reading is a client UX problem, with chat markers, you can mark the messages you read on a client
lovetox_
and sync this info to your other clients, which can act accordingly
Zash
Did anyone have plans to make a PEP based unread message tracking thing?
Danielhas left
Danielhas joined
larma
Zash, why?
APachhas left
Zash
IIRC there was talk about something like that, or at least changing 333.
Danielhas left
Danielhas joined
pep.
Zash, on, I'd like that
pep.
To sync reading state between clients
larma
but you can already do that using MAM, no?
pep.
Can you?
Zash
How?
larma
well if a 333 marker is send as a message, MAM should store it
larma
> Clients SHOULD use Message Archiving (XEP-0136) [7] or Message Archive Management (XEP-0313) [8] to support offline updating of Chat Markers. Chat Markers SHOULD be archived, so they can be fetched and set regardless of whether the other users in a chat are online.
from 333
pep.
Sending only 333 to myself then?
Zash
Never seen that before.
pep.
I don't especially want others to know
Danielhas left
Danielhas joined
lovetox_
pep., i think this would be possible
lovetox_
you could send chatmarkers to yourself
lovetox_
its very ugly because you get a hell of duplicated messages
pep.
yeah
lovetox_
but i think this would work
larma
Ah right, If you don't want the other end to know, 333 is probably not best suited
lovetox_
BUT only if you use unique stanza ids in every conversation
pdurbinhas left
lovetox_
otherwise you lose the context
larma
Yeah, makes sense, if you don't want to send to other end, PEP is better than MAM
Shellhas left
Shellhas joined
chronosx88has left
Nekithas left
chronosx88has joined
Mikaelahas left
Mikaelahas joined
lovetox_
you could do this analog to bookmarks 2
lovetox_
one node, with X items, and item-id = jid of contact