lovetoxif i end a stream correctly, does the server send unavailable presences out?
lovetoxor do i have to do this myself befor i end the stream
ZashServer sends unavailable when the session ends, if it's still available at that point.
lovetoxhm not sure this answers my question
pep."yes, if the server is not down"?
lovetoxi send </stream> and end my stream
Zashlovetox: the answer is yes
lovetoxok thanks :)
Zashthe server will send unavailable if you don't
lovetoxok and its not considered bad by the client to not send it themself
KevI'd consider it daft to do so.
lovetoxKev, its daft to send presence themself as client?
KevYeah. The server's going to do it for you, so I think it's daft for a client to maintain code to duplicate that.
lovetoxgreat, i thought so too :)
ZashIn theory you can set a status message while you're offline, but I don't think the server is required to keep that.
ZashProbably made more sense before always-on mobile clients
asterixExcept if you want to set a good bye status message.
lovetoxhm yeah true we actually have a good bye message feautre
lovetoxand im pretty sure servers keep that
ZashI'm reminded of the disussions around having status messages in PEP instead of presence
lovetoxi see that all the time if people leave a muc
lovetoxand going offline
pep.Zash: a "bye message" in PEP?
lovetoxand of course they have to keep it
lovetoxits a presence i send, the server does not know that im going to go offline in a sec
Zashlovetox: no, they just have to broadcast it
lovetoxi thought thats what keeping it means
lovetoxor do you send a second unavailable presence after i send mine and end the stream
lovetoxi think not
ZashProsody does not keep unavailable presence around after broadcasting them
lovetoxwhy would i need the server to store the message?
Zashand after that there's no point of generating unavailable on disconect
lovetoxi told everyone that is online that im going offline
ZashI'm not sure I follow what you're saying
Sam WhitedWhat if I'm offline when you send that message, you go offline, then I come online? I might also want your status message (which is why it should be in PEP in my opinion).
lovetoxyeah thats not possible
KevSam Whited: I have a TODO from the Summit to write presence-over-PEP, BTW.
lovetoxbut thats not a reason to not tell the people who are online and are able to receive it, to not tell them
ZashI believe there's a hint in one of the RFCs that the server could keep the last unavailable presence of the last resource and send in response to probes later, but I'm pretty sure it's optional and at least Prosody doesn't do this.
Sam WhitedKev: oh that's interesting, I was just thinking about specifics like a status messages being a new thing in PEP, not presence in general and all the other information it conveys. I'll be curious to see that
KevSam Whited: I mean status/show, really.
KevSo <presence/> becomes device information, and PEP becomes user information.
lovetoxits just much much more traffic for nearly no gain
lovetoxpreviously it was 100 presences on coming online, then its doubled because everybody puts status and show in pep
lovetoxalso its probably fine to have a account wide status
lovetoxif i come online i get the last pep info, show = online
lovetoxbut no presence means offline
lovetoxalso there is an information loss, if i see a work pc as away, but the smartphone as online
lovetoxi can assume a person is not at his workplace right now
Sam WhitedI'd be okay with that; personally I prefer to treat status as an account thing. You can either reply to messages or not and I shouldn't have to think about what clients are busy and online and away.
Sam WhitedWith carbons and MAM it becomes way less important to have each individual device have more granular status than online and offline.
Kevlovetox: I don't think you can assume that at all.
KevI frequently have my phone with me when I'm in the office, but have stepped away from my desk.
lovetoxthats what i meant with not at your workplace
Sam Whitedlovetox: but why would it be marked as away? I suspect most people don't change their status every time they step away from their desk for a few minutes, and they still have their phone on them so it's not like they're going to miss your message if you send them one?
lovetoxPoint is, right now we have the possibility to maintain a show value per client, this is a feature, for some people this is useless, others find it veryuseful, it depends on the circumstances
lovetoxyou want to take this away, and i simply ask, what for, what is the gain we have from that?
lovetoxSam Whited, auto away is a thing
Sam WhitedA much simpler system for users.
lovetoxIf you want to make it simple for YOUR users, nobody forces you to display the show value from each device
Sam WhitedWho finds it very useful? Are people still sending messages to individual clients?
lovetoxSam Whited, its about the information, not about sending messages
lovetoxA device is autoaway for 20 minutes
lovetoxthats a device status, and a device show
Sam Whitedlovetox: I don't understand what people are doing with this information then.
lovetoxthis information is useufl
Sam WhitedIt seems like an anti-feature to me.
jonas’it becomes useful once you have to deal with device-to-device communication
lovetoxyou dont have to, point is xmpp offers that information
jonas’like jingle file transfers and calls
lovetoxif you dont want to show it to your users, dont
lovetoxyou dont need a show in pep, to reduce to presence shows to one
lovetoxyou dont need a show in pep, to reduce two presence shows to one
jonas’having an account-wide show is also a useful thing though
Sam Whitedlovetox: it's not just about showing it, it's about setting it. I already do only show one to my users
jonas’having a user-controlled account-wide show is also a useful thing though
lovetoxlike all other clients
lovetoxso i dont see any gain for the user here
Sam WhitedIMO anything that involves individual clients we should be fixing or getting rid of; eg. Jingle too. If someone sends me a file I should pick what device to receive it on, not them.
lovetoxnow its one, afterwards its one
lovetoxi see XMPP can deal with multiple devices as a feature
lovetoxyes its tricky sometimes
lovetoxyes its not easy for devs to make this easy for users
lovetoxbut its nevertheless a big feautre, that other messengers like whatsapp never had for years
lovetoxand still to this day its not even near XMPP
lovetoxi think todays users can be trusted to get the gist of a system with multiple devices
lovetoxwe dont have to treat them as super dumb
jonas’I’m not sure that’s true
Sam WhitedI still really don't see the use case, "having more features than WhatsApp" isn't a usecase, and may not even be a good thing.
KevI'm not sure providing features that make sense is about user being stupid.
lovetoxim now a few years in very near contact with users of Gajim, and never had even one asked what it means that there are 2 devices listed with different show
lovetoxKev what is the feature you are talking about
lovetoxas we already said, all clients show ONE show value already
lovetoxmoving this into pep, and afterwards showing ONE show value
lovetoxmakes 0 difference for any user
KevAllowing a user to set a status message applicable for themselves, rather than a device.
lovetoxwe talk since 10 minutes about show
lovetoxbut yes i agree, account wide status can be useful
KevAnd to be able to say that they're "Do Not Disturb" and not have that change because a client that had disconnected suddenly gets a connection again.
Sam WhitedI probably confused that, I always call that status but I meant online/away/busy not the status message
Sam WhitedAnd if you're just asking your users who already use XMPP that's a very self-selecting sample set. We're trying to make the network make sense and be easier for everyone, not just existing XMPP users.
lovetoxyou make it easier in one department, and loss stuff in the other
Sam WhitedWhat are we losing? I still don't see any use case for per-device show values. The Jingle one makes sense, but we need to fix jingle not keep this weird state where show is per-device.
lovetoxobviously the show from each device, if you only have one
jonas’> If someone sends me a file I should pick what device to receive it on, not them.
how are you going to do that if you’re AFK?
Sam WhitedAgain: what is the use case? I understand *technically* what information is being lost, I don't understand why we care about that information.
lovetoxbut lets leave this for now, i see you dont find it useful so it has to go
jonas’will the transfer be stuck until you "accept the call" on one device?
lovetoxwhat about the PEP spam?
jonas’will you configure a default preference?
lovetoxhow much more info you want to put in different PEP nodes?
Sam Whitedjonas’: I dunno, we can figure that out later. Completely different discussion
jonas’Sam Whited, I find this not completely different, but ok
lovetoxwhen i come online, how many MB data do i have to download from the server, just so im up to date with everyone
jonas’lovetox, good question!
lovetoxPut it into PEP, is not a scaleable solution
lovetoxand we/you should think rather sooner about how to solve this
jonas’it’d be more scalable if PEP updates from a single contact were aggregated in a single stanza
Sam WhitedOh, is the argument changing to scalability now? The goalposts appear to be moving.
lovetoxSam Whited, why is a goalpost moving, if i have multiple points why this is bad?
lovetoxi respect that you dont share my opinion about show per device is useful
Sam WhitedThe points are changing without actual answers to the previous questions. I agree, we should talk about scalability too though, but I'm less concerned about the technical side of things, we can solve that when we write the XEP.
Kevlovetox: The proposal isn't that per-device presence payloads become illegal. Just that they're not used if what you're trying to convey is the status of the user rather than a device.
lovetoxyou cant solve pep scalability by writing another UserStatus xep
Sam Whitedlovetox: do we know that it's not scalable before we write the XEP? How do we know it doesn't save us a lot of stanzas?
Sam WhitedFor example, let's say we have a system like the original we were describing where status messages work even if the user is offline. If we did that in the current presence based system, every time the user is online they have to do a presence probe for all of their offline contacts. In PEP they just get that pushed down only for contacts that have actually pushed a presence. That probably saves a lot of round trips.
lovetoxYou compare something, nobody actually does, and nobody will ever do (probing offline users) against your PEP proposal
lovetoxbut yeah that would save roundtrips
KevOffline users do get probed when you come online, all your contacts do.
KevThat's how you find out that they're offline (or not)
Sam WhitedSure, the point is that there are ways it could save us stanzas and we won't know until we figure out how it's used and write the XEPs.
Sam WhitedLet's take the show example (I'm not suggesting this is how we should do it, I'm just saying that your assumption that it's more traffic isn't necessarily true): if we move show into PEP we could imagine a system where after we come online we get a single presence for only online devices like we get today. That contains the accout status value then *after* that we start getting updates from PEP. Now we have the niceties of device/account information being separated, but still get the same number of stanzas on login
Sam WhitedOr we could get show from PEP on login and not get presences at all, then probe accounts for devices only if/when we need them lazily. This would likely drastically reduce the amount of traffic on login (I think? Maybe we always need caps right away so this wouldn't work). Again, not suggesting we should do these things, just that "it will increase traffic" isn't something we know yet.
lovetoxSam Whited, really you are talking about changing stuff in the whole eco system
lovetoxwe just talked about putting show into PEP
lovetoxand yes this would double traffic, given all ccontact use this
Sam WhitedYes, these are the things putting show in PEP eventually could allow us to do. I'm not suggesting we do them right away or that they're even possible necessarily, just that they're good examples of why "it will increase traffic" isn't a good argument.
Sam WhitedIt might double traffic, or it might make it lesser overall once we start moving more things into PEP.
lovetoxare we talking about the same thing? you know how PEP works or?
Sam WhitedWe won't know until we think about it a lot more, write the XEP, maybe start getting implementation experience.
lovetoxPEP says, on +notify, it pushes the last node of every contact, for every node you subscribe to
lovetoxso yes this is not scaleable
lovetoxunless you fundementally change PEP / Pubsub, putting more stuff in PEP will increase traffic
Sam WhitedMaybe "account info" is a node that contains lots of things in one big payload that previously would have been sent by many different presence/message/IQs.
Sam WhitedMaybe offline nodes are removed and the deletion signals offline (unless we have a feature where we keep a status message around or something). Now we stop getting updates from those and it's basically the same as presence was. There are all kinds of ways this could reduce the amount of traffic sent.
lovetoxyeah thats thinking about scaleability
lovetoxand that what we should do before adding more things into PEP
Sam WhitedRight, which is why I think we can't just say "it will double traffic" without an XEP and possibly implementation experience.
Sam WhitedI dunno, maybe it's not enough traffic to matter what happens before moving more things to PEP. Or maybe it is. The point is we don't know right now.
lovetoxi know, Gajim implements every UserPEP Xep there is
lovetoxand believe me even on accounts with 20 users, this means endless stanzas
Sam WhitedYou're wanting me to argue that it absolutely will reduce traffic, and I'm not arguing that. I'm just arguing that your assertion that it will double traffic may or may not be true and it's not a good argument for why we shouldn't bother to move show/status into PEP.
lovetoxmy assertion was it will double traffic, if you copy UserPEP XEP XY and do the same with status and show
lovetoxand that was definitly on the mind of everybody when this discussion started
Sam WhitedWhy are you thinking that's what would happen when you haven't read Kevs theoretical XEP?
lovetoxnow we moved the goalpost to, oh yeah that XEP would have to keep scalability in mind
lovetoxand im fine with that :)
lovetoxKev can share it and prove me wrong, im happy if we have good solutions for problems
Sam WhitedAnyways, I shouldn't have let myself be drawn into pivoting this into a technical discussion. We're not there yet. My argument is that we need to think about use cases and users, and I don't see one for how the existing system works.
lovetoxalso MUC incompatibility with PEP is a problem since a longer time, dont know if we have the same problem with MIX
Sam WhitedI sometimes think that we need to treat the public network as a service when we're writing XEPs. Maybe we need a Jabber product manager (or product mangaer committee) who puts together a cohesive vision for what the Jabber Service should look like in the future, and then decides if XEPs guide us towards or away from that.
Sam WhitedYah, MUC would definitely have to be thought about, that's always tricky. Still though, that's all a ways out and isn't an argument for why we shouldn't write the XEP. It's definitely worth thinking about while writing it.
Sam WhitedAnyways, I need to step out now and get ready to leave. Please think about use cases. I'd really like to know if there actually is one for the current system.
lovetoxis it possible from the outside to see that a websocket connection is a xmpp connection?
ZashBased on looking at the TLS connection? Probably not easily.
lovetoxas i understand websocket, first a normal HTTPS connection is made
ZashTimeing information might leak that it's not following the common request-response pattern of HTTP
lovetoxthen within that the protocol is upgraded to websocket
lovetoxok so if i want to conceil the fact that its an xmpp connection, this is probably a safer bet than xep0368
lovetoxwe announce a protocol xmpp-client with 0368
lovetoxis this transfered in plaintext, within the tls negotiation
lovetoxor afterwards is the question
ZashALPN is sent in plain text in the beginning of the TLS handshake
lovetoxyep so trivial to see that its an xmpp connection
moparisthebestUnless you don't send it, it's not mandatory, if you need to conceal this you should not send it
moparisthebestSame with SNI
ZashCan't get around the certificate being returned in the clear tho.
moparisthebestThough encrypted SNI is almost here, I expect encrypted alpn to follow shortly
moparisthebestZash: iirc that's fixed already in TLS 1.3 ?
lovetoxhm if i dont send the protocol than a webserver also running on 443 will not know that i want to talk to the xmpp server or?
lovetoxi think i ran into that problem early in my implementation
moparisthebest> The difference is that in TLS 1.3, a lot less is in the clear. For example, in TLS version 1.2 you were able to witness the disclosure of the Subject Alternative Name (SAN) in the Certificate but in 1.3, this is encrypted and not made available for inspection by any intermediate system.
moparisthebestFrom our favorite company https://blogs.cisco.com/security/tls-version-1-3-change-is-here-and-encrypted-traffic-analytics-has-got-your-back
moparisthebestlovetox: depends on how the server is set up, maybe, maybe not, that's why it's important you keep trying all the SRV records
moparisthebestUnless you must not be detected of course, in which case you abort
lovetoxhm problem is when connection succeeds i will not try others
lovetoxmaybe i should wait for the first <stream> to make that decision
moparisthebestAlso if TLS verification fails you should keep trying
lovetoxeh actually im in the camp to not shadow a badley setup server with various workarounds
moparisthebestI haven't had problems with gajim, but dino won't connect to my server unless I patch out their xep 368 module because of that error
moparisthebestYou aren't, you are allowing easy DOS
lovetoxif a cert verify fails, why would it not fail on a other connection method?
lovetoxcan you give me the address of your xmpp server so i can try if it works in my new code?
moparisthebestAny mitm can accept a TCP connection
moparisthebestlovetox: mitm ?
lovetoxa mitm that only mitm on one connection method?
moparisthebestburtrum.org , feel free to poke, so if you don't send alpn over ipv4 you'll end up taking to nginx
moparisthebestlovetox: absolutely? Plenty of ways, v4 vs v6, servers in different datacenters
moparisthebestMaybe captive wifi is only set to mitm 443 not 5223
moparisthebestBasically your code should never stop trying based on anything an attacker could cause
lovetoxbut this is too complex
lovetoxcert on my server is expired
lovetoxi dont care, gajim shows me the error, i tell it to connect anyway
lovetoxtrying everything first and remembering the first cert fail, then if everything fails coming back to that and offer the user to connect anyway
lovetoxreally dont want to implement that
lovetoxalso if you assume every cert fail is an attacker
lovetoxthen you simply cant connect to a server anymore that has no valid cert
lovetoxwhich is also a choice i want to give to the user
lovetoxi can connect fine to your server btw
lovetoxalso i dont see it as my responsibility to make Gajim into a tool that can withstand a DOS
pep.lovetox: if you remember the cert you might allow the user for some more time.. I always find this weird tbh, this expiry thing. Tge cert expired but you're still connected so you don't care, even if it's been a week already, and when you reconnect you (the client) is like "omg the world is burning"
lovetoxyeah i also fail to see how a expired cert is suddenly insecure
lovetoxif its expired for 2 years
lovetoxok an attacker had plenty of time to attack that cert
lovetoxbut a week? ..
pep.I guess it mostly shows how much the admin is active :p
pep.or how skilled in cron they are!
moparisthebestRight but I want gajim to connect from sleazy free WiFi if possible, not give up on first mitm or blocked port
moparisthebestThat entirely defeats the purpose of srv
ZashI don't think SRV was invented as a way to avoid MITM or blocks
lovetoxwait, blocked port is different story
lovetoxGajim will try until it has a successful connection with the host and port gathered via SRV
moparisthebestA mitm can accept a TCP connection though
moparisthebestYou shouldn't give up until you have cryptographic proof you can't successfully connect to the server
Zashprove a negative?
moparisthebestLike, they provide a proper cert and then reject you with bad password, for instance
moparisthebestAnd srv explicitly was invented to prevent dos, one service is down or unreachable or misconfigured, try the others
ZashWhere does it say that?
moparisthebestWhat other purpose could it possibly have? Otherwise just use a well known port like http
ZashRFC says it's for moving services and designate backup servers. There's one mention of "denial of service", in the context of SRV being used *for* it.
moparisthebestDon't need backup servers if nothing can go wrong at your primary
moparisthebestIf something can go wrong though, why not try the backup
defanorFWIW, that's the thing that bothered me about both "happy eyeballs" and looping through SRV records too: there can be scenarios in which a connection is possible, yet a client would fail to connect while following those. But fighting potential DOS via an unknown MITM (or poor connectivity) seems like a rabbit hole: even if you succeed in establishing a TLS connection, a MITM or a poor network could simply start dropping packets after
defanorpassing a few.
moparisthebestThat's fine, xmpp works fine over those kind of networks