pep.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
Ge0rGlovetox_: modern MUCs will treat a join presence (with an x element) as a request for a full sync.
Ge0rGAnd yes, there is no way to abort anything in xmpp land.
Ge0rGWhich 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
Ge0rGOTOH some network conditions may well lead to a request getting black holed.
Ge0rGSo that the MUC doesn't even know that you tried joining.
mukt2has joined
Ge0rGThis can be solved with s2s 0198, which nobody has ever tested.
larmahas left
Ge0rGBecause 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
Ge0rGjonas’: but one needs to know where the old join ends and the new one starts.
adiaholichas joined
Ge0rGMaybe 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
flowjonas’, 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
Ge0rGIf 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
Ge0rGWe 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
ZashCan you really fix that with protocol design?
jonas’"WhatsApp works"
Ge0rGZash: yes
andyhas joined
Ge0rGWith 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
Ge0rGBTW, what are the rules for delivering subscription requests to clients that don't send presence?
jonas’"don’t"?
Ge0rGOh, 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.
jonas’ 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
ZashIt'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.
rionSIMS 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?
Ge0rGjonas’: yes, it's an improvement indeed. But will you get differential updates on the member list?
jonas’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.
Ge0rGIs 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.
Ge0rGZash: I'm sure we can figure out a way
flowrion, appears so
mr.fisterhas left
Ge0rGI don't think it makes much sense, though
flowrion, although that appears to be not in line with xep234
flowor, at least, I would expect that SIMS would require at least media-type, size and name (not description)
rionAgreed
pdurbinhas left
Ge0rGIn JFT, the <description> is the required container element, and the description text is in the optional <desc> element
Ge0rGSo what are we talking about?
rion<desc>
flowwhich 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
ZashHow 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
Zashright
ZashIt should still be idempotent tho?
lovetox_idempotent?
ZashIf you get a second join result it should just set everything to the existing values
emushas joined
ZashBut 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
ZashI tend to agree
goffihas joined
Ge0rGIt's significantly improved over GC1.0 still
ZashYes
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
ZashDoes anything use the 'continue' error type?
Zashlooks at https://xmpp.org/extensions/xep-0310.html#mucoccupant
adiaholichas left
Syndacehas joined
ZashMight 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
larmaAnyone 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 :/
ZashMulti-session-nick is fairly underspecified
Zashlarma, 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
ZashFile an issue. I also want to be able to disable PMs.
lovetox_yes
mukt2has joined
ZashWould 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
ZashNo, it routes to the bare JID
jonas’I wouldn’t call that "pubsub component" to avoid confusion
ZashIt was ejabberd that answers vCard requests to full JIDs
Zashiric
Zashiirc*
lovetox_which is correct if you go by the XEP isnt it?
Zashwat
lovetox_the vcard xep says server should answer it for the user
Zashwat
lovetox_otherwise how would you request a vcard of an offline user?
jonas’lovetox_, ask the bare JID?
Zashwat
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
ZashIf 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?
ZashYou can't.
ZashServer can forward the request to your bare JID, like Prosody does
lovetox_and you do this now for any IQ request
ZashNo, only for a small set of known namespaces, namely vcard-temp, pubsub and vcard4.
lovetox_yeah and you dont see this as a problem?
ZashNo
lovetox_this is nowhere specificed, its a hack
lovetox_and one that is a privacy issue on top
ZashAs was the vcard-temp routing thing.
ZashHowever that's considered public data
lovetox_i consider it public data to people who know my adress
ZashDon't put it in your globally public vcard then
ZashWhat 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
ZashI think you exaggerate the privacy impact somewhat.
ZashI 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
ZashDon'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
ZashWe got tons of complaints IIRC when we made vcards (via the PEP-conversion stuff) respect the privacy settings of the corresponding PEP nodes.
ZashSo, 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
ZashNow 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*
Zashavatar and vcard4s are separate nodes tho
pep.k
ZashAnd you can have separate permissions. I do, in fact.
pep.I also do have that node set to presence I think
ZashIf 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
ZashSome 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
ZashOr 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
ZashYou 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
ZashI 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?
ZashAs 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
Zashjonas’: 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
larmaThe 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
Zashlovetox_, ever had people join your support room and then PM you support questions?
ZashIIRC 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.
larmaMy 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
larmaWell, 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
chronosx88Hey, guys. Does MAM support for chat room state changes? (E.g. chat room name or subject)
larmalovetox_, yes that would work
jonas’chronosx88, subject yes, name not
ZashDoes it?
chronosx88And 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
chronosx88Ehm...
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
chronosx88I 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=)
chronosx88And... 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
chronosx88Yeah
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"
chronosx88Ok
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
chronosx88Another question: how I can sync unread messages count between clients?
lovetox_your best bet is XEP-0333 chat markers
Danielhas left
chronosx88And 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
ZashDid anyone have plans to make a PEP based unread message tracking thing?
Danielhas left
Danielhas joined
larmaZash, why?
APachhas left
ZashIIRC 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
larmabut you can already do that using MAM, no?
pep.Can you?
ZashHow?
larmawell 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?
ZashNever 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
larmaAh 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
larmaYeah, 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
lovetox_then add the current stanza id that you read