lovetoxis a type error presence, always generated as a response? Meaning is there a situation where the server would route a error presence to my client, without the client first sending out some presence?
MattJYou might get error responses from your contacts after sending initial presence, which is somewhat similar
MattJSpecifically, in this case you might receive multiple errors in response to a single presence
mhhas left
MattJI suspect that *may* also happen in some circumstances the event that another client on your account comes online and triggers presence probes
mhhas joined
navhas joined
jubalhhas left
nephelehas joined
navNow that leaves me with the problem of what happens when someone does recycle an old JID.
antranigvhas joined
navWould it be useful to have some kind of unique (opaque) registration identifier to distinguish between two uses of the same JID?
goffihas left
navSomething like an UUID that is associated with a JID for the lifetime of the account. When a JID gets recycled a new UUID is associated with it.
navThen other services can query for the UUID to establish whether it is the same registration.
Laurahas left
Laurahas joined
KevI think the basic solution is 'never allow re-use'.
dezanthas joined
antranigvhas left
atomicwatchhas joined
MattJI think that's for the best. Otherwise every single slot where we currently have a JID, we would need to replace with JID and UUID
navKev: It's one solution, but not always feasible. For instance because of a catastrophic server failure with loss of data or even GDPR considerations.
MattJEven sending a message. What if you send a message to someone, and it was delayed for a few minutes, but they deleted their account and somebody recreated it?
MattJThe logical conclusion is to replace JIDs with UUIDs :)
navMattJ: I was thinking more of an as-needed approach, where the onus is on the receiving entity to validate, if they want to, that they're dealing with the same registration.
MattJBut more feasible would be: treat usernames as human-readable UUIDs
nephelethat problem is fun, if you have a UUID you can also move servers
navFor instance, via a disco#info query returning the UUID.
nepheleif you disallow reuse you might have users that you cannot use for *some* instances because they know your hostname and users that used to be on it, but can use it for other instances that don't know about it... might be a problem if you get a dns name that had a previous owner beforehand
MattJSure. For Snikket I disallow hostname reuse for this reason, too.
navOf course, it doesn't cover the case where someone recycles JIDs mid-conversation. ☺
nephelei'm enviromentally friendly, reuse before recycling! :D better to steal the account mid-conversation
Apollohas left
navnephele: I wasn't considering active attacks. If that is a concern, then you'd want to be using encryption.
nephelewell, the dns entry expiring and beeing re-registered mid conversation seems quite unlikely to me?
MattJIt's an extreme example of course, but certainly I could send a delayed reply to someone whose domain expires and was reregistered by someone else
nepheleI mean, what exactly would a UUID *reasonably* protect against that a JID does not? if it does not have any crpytographic gurantees it could also be recycled mid conversation
navhas left
navhas joined
nephelesay, if a caching entity is not told that it was recycled and maintains a wrong association of jid<->uuid
navActually, I wonder if using encryption would be a viable approach. In theory that would allow both endpoints to authenticate each other.
navnephele: Yes, good point.
Link Mauvenav, you mean like SASL EXTERNAL, which validates against TLS certificates? :p
nepheleI personally like the aproach of "your public key *is* your adress"
nephelei am not sure if that is viable, but it would be quite neat ;)
navLink Mauve: Possibly, but how do you get say your external component to ask the user connecting to it to authenticate himself that way?
navnephele: Yeah PKA makes sense.
navI'll need to have a read of the relevant XEPs see how much hassle it is to implement something like OX on something like a component.
Apollohas joined
marc0shas left
marc0shas joined
Samhas left
Samhas joined
navhas left
Stefanhas left
kujiuhas left
antranigvhas joined
kikuchiyohas left
Wojtekhas joined
Apollohas left
Zashhas joined
kikuchiyohas joined
pasdesushihas left
atomicwatchhas left
pasdesushihas joined
marc0shas left
marc0shas joined
Wojtekhas left
mhhas left
marc0shas left
marc0shas joined
goffihas joined
nephelehas left
navhas joined
mhhas joined
navBit of a problem. Encryption support appears to be largely limited to message stanzas but not IQ or commands.
antranigvhas left
navIt's not encryption per se that I'm concerned about but a way of verifying that you're dealing with the same identity you were dealing with at some unspecified point back in time. Maybe signed presence stanzas will fill the gap.
Link Mauvenav, that was a thing in XEP-0027 fyi.
marc0shas left
marc0shas joined
navLink Mauve: Presence signing?
Link MauveYes.
mhhas left
navYup, at least Blabber supports it.
navKind of out of the box if you've configured an OpenPGP key for the account.
pasdesushihas left
pasdesushihas joined
selurveduhas joined
navWhich is nice because that means the component is getting the signed message essentially for free.
atomicwatchhas joined
navIf the component can be bothered to discover the user's public keys and cache them, then a change in the advertised fingerprints may mean that the user could be someone else (or has replaced his keys). That the advertised fingerprints are valid can be checked by verifying the signed presence message.
thomaslewishas joined
Laurahas left
pasdesushihas left
navhas left
navhas joined
mhhas joined
navAnd in principle, this can be done transparently and in a way that's compatible with no OpenPGP use. ☺
Laurahas joined
thomaslewishas left
flownav: i am not confinced that presence signing is a good idea
flowmessage signing, of course, but presence probably not
flowfor starters, presence signing probably significantly increases the time your OpenPGP signing key is unencrypted
pasdesushihas joined
mhhas left
mhhas joined
thomaslewishas joined
mhhas left
mhhas joined
pulkomandyhas joined
thomaslewishas left
dezanthas left
atomicwatchhas left
Samhas left
marc0shas left
atomicwatchhas joined
pulkomandyhas left
Samhas joined
marc0shas joined
thomaslewishas joined
xeckshas left
thomaslewishas left
norayrhas left
navhas left
navhas joined
xeckshas joined
norayrhas joined
navhas left
navhas joined
nikhas left
inkyhas joined
thomaslewishas joined
Stefanhas joined
marc0shas left
marc0shas joined
jubalhhas joined
marc0shas left
marc0shas joined
thomaslewishas left
marc0shas left
marc0shas joined
mhhas left
nephelehas joined
nephelehas left
mhhas joined
antranigvhas joined
thomaslewishas joined
Paul G Websterhas left
xeckshas left
nikhas joined
Alastair Hoggehas left
heartyhas left
heartyhas joined
larmahas left
jubalhhas left
heartyhas left
pasdesushihas left
xeckshas joined
navhas left
navhas joined
thomaslewishas left
alhas joined
pasdesushihas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
thomaslewishas joined
inkyhas left
debaclehas left
debaclehas joined
thomaslewishas left
gregoryhas left
gregoryhas joined
marc0shas left
marc0shas joined
Dele Olajidehas left
pulkomandyhas joined
marc0shas left
marc0shas joined
inkyhas joined
dezanthas joined
marc0shas left
marc0shas joined
Ingolfhas left
thomaslewishas joined
marc0shas left
marc0shas joined
nikhas left
marc0shas left
marc0shas joined
Dele Olajidehas joined
marc0shas left
marc0shas joined
thomaslewishas left
larmahas joined
nikhas joined
alhas left
Ingolfhas joined
pasdesushihas left
raghavgururajanhas joined
Laurahas left
pasdesushihas joined
sonnyhas left
selurveduhas left
dezanthas left
MSavoritias (fae,ve)has left
atomicwatchhas left
pasdesushihas left
dezanthas joined
MSavoritias (fae,ve)has joined
pasdesushihas joined
colemanhas left
Samhas left
Samhas joined
thomaslewishas joined
marc0shas left
marc0shas joined
atomicwatchhas joined
Samhas left
sonnyhas joined
Samhas joined
Ge0rGhas left
Laurahas joined
atomicwatchhas left
Ge0rGhas joined
PapaTutuWawahas left
atomicwatchhas joined
nikhas left
navflow: The same consideration applies whether you're signing and/or encrypting messages as it does to presence. In any case, at least Blabber automatically signs presence stanzas if you have a PGP key associated with your account.
flownav, the thing is, sending a message is a conscious action, whereas presences are mostly send without the user being aware
flowgranted, the problem was more severe in the days where whe shove everything into presence, like "the current song you are listening to"
ZashXEP-0027 signed presences are *huge* and get broadcast to all your contacts every now and then
ZashDoesn't feel efficient
flowin those situations, your pgp key practically never got re-locked, and it always stayed unlocked, which wouldn't be the case if only messages are signed
flowZash, I think that modern cipher woulds produce smaller signed presences
navXMPP is hardly efficient to start with. As for presence stanzas, they're not being sent all the time but only when your presence status changes.
ZashOpenPGP?
thomaslewishas left
navZash: ?
flownav, depending on the used extension protocols, your presence status changes quite often
navflow: For instance?
Zashauto-away etc
flowxep256
flowbut shoving stuff into presence is now large considered an anti-pattern, rightfully, if I may add✎
flowbut shoving stuff into presence is now largely considered an anti-pattern, rightfully, if I may add ✏
navflow: Why would 0256 increase the rate at which <presence/> is being sent?
Zashflow, XEP-0319 too!
navIt's, as you say, just adding some more stuff into it.
ZashConversations for example has a feature where it sends presence every time you focus or unfocus it.
ZashDisabled by default IIRC
PapaTutuWawahas joined
ZashIn any case, it was agreed in the XMPP community long long ago not to shove so much stuff in presence, instead use PEP
navXEP-0319 is a better example, but as long as it's under control of the user I still don't see the problem
flowxep256 isn't the best example, but it was the best I could dig up in short time
navYup, PEP is a good idea.
flownav, but as I wrote, we had previously XEPs that put the last user tune in presence
ZashOX!
flowso every 3 minutes or so, you would emit a new presence
flowfurthermore presence gets amplified by MUCs
flowimagine you are in 3 MUCs with the same people
navflow: Yeah, I remember that fad!
flowevery time someone emits a new presence, you get it 4 times
flow(assuming you are also subscribed to the presence0
flowand finally, I am not sure what a signed presence gets you
ZashI think it might vary a bit actually, some clients don't send presence updates to MUC
flowlike what do you do with that information?
flowhow would you behave if it wasn't signed
flowhow do you behave differently if it was signed?
flowZash, hmm isn't the server doing that?
flowbut you are the expert on that topic :)
ZashProsody doesn't. Maybe it should? But you get problems.
flowI assumed that MUC presence is based on RFC 6121 § 4.6 Directed Presence
ZashLike, it gets weird if you change nickname. Should the server broadcast your presence to both nicks?
navflow: "how do you behave differently if it was signed?" Well, that's what I was getting at. I could make certain assumptions as to whether the JID is under control of the same user.
Zashnav, your phone gets stolen. now what?
flownav, I am not sure if this answers my question
flowcould you give a concrete example?
flowdon't get me wrong, 20 years ago I also believed that signed presence is cool
flowbut today, I see only drawbacks and no advantages of presence signing
navflow: See the discussion around 1130Z today for background to the discussion.
flowkk
flowand fwiw, I believe signed presences should include a timestamp, for hopefully obvious reasons
flowbut then you need to define a time-to-live for those
flow1h, 3h, 24h, 7d?
navIt all comes from the fact that yesterday I accidentally deleted my account 🙄
flowin any case you now inveted a new mechanism that causes presences updates
ZashWasn't that one of the problems with XEP-0027, no replay protection?
flownav, probably the better solution would be a signed pep item in a well-defined pep node
navBut the component I was testing at the time still kept all the information associated with my JID.
navIt dawned on me that the component will wipe out your info if you unregister with it, but not if you unregister from your own server and someone else takes over your JID.
navflow: That sounds sensible.
marc0shas left
marc0shas joined
flowI get that point, and I think the solution lies in PEP, not in Presence :)
flowyou basically want to place a proof of ownership in the PEP node
navMy first thought was some kind of UUID but as was pointed out above that was kind of daft and then someone brought up crypo, and here we are.
navIndeed that sounds like a good solution! ✔
mhhas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
navI could get people to register a password with the component but the usability is not quite as good.
mhhas joined
MSavoritias (fae,ve)has left
navWhat about discovering and remembering OMEMO nodes?
MSavoritias (fae,ve)has joined
flowif you work out a protcol with one crypto scheme it is easy to apply to the same to another crypto scheme which is able to sign bytes
navOn second thought, that probably would not work.
flowthe main issue is that OMEMO, unlike OpenPGP, has no concept of a primary key
flowat least IIRC
navExactly
Samhas left
navI like the signed PEP node approach. The disadvantage is that it requires explicit client support.
flowhow could something like that *not* require explicit support from implementations?
navI should have said explicit client support which is not there at the moment. ☺
ZashDeploying new things 🤷️
Samhas joined
navThat's why I was hoping to piggyback on signed <presence/> stanzas, as some clients already do those.
flowisn't that always the issue: that we imagine those kewl new protocol extensions, but then suddenly realize that someone needs to implement them? :)
navThe cool thing about the signed PEP is that it could be used by people wanting to prove control over a JID *or a group of JIDs*
Zashopen standards go brrr
navFor instance people who have accounts on different servers.
marc0shas left
marc0shas joined
moparisthebestwhat's it proving? that someone with that private key at some point had access to that account and/or server ?
navmoparisthebest: Yup
navNo more and no less.
Dele Olajidehas left
moparisthebestwhat's the intended way to use that info ?
navWith reference to the red warning on XEP-0086 (https://xmpp.org/extensions/xep-0086.html)…
nav…considering that I am dealing with handling error conditions in the context of XEP-0030 (https://xmpp.org/extensions/xep-0030.html), I guess I should ignore that warning, right?
Zashhttps://xmpp.org/rfcs/rfc6120.html#stanzas-error is where you should look for syntax of errors.
navThanks!
ZashAnd service-unavailable is the error you must return for any iq-get or set that you do not understand.
navRoger that.
navIs that specified somewhere, off the top of your head?
navOr just customary practice?
ZashIn the RFC I just linked
navYup, just found it, ta. https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-service-unavailable
marc0shas left
marc0shas joined
Zash10.3.3. IQ
> If the IQ stanza is of type "get" or "set" and the server does not understand the namespace that qualifies the payload, the server MUST return an error to the sending entity, which MUST be <service-unavailable/>.
jubalhhas joined
navCool, that makes life easier. ☺
ZashThere should also be text to the effect that every iq-get and iq-set must have a matching iq-result or iq-error
kfvhas left
kfvhas joined
techmetx11has joined
techmetx11hi
techmetx11how would you implement multiple nicknames in a vcard
navZash: True
techmetx11the DTD says that multiple <NICKNAME> elements can exist, but multiple nicknames must be a comma-seperated list
techmetx11(talking about vcard-temp)
ZashMy personal advice: Ignore vcard-temp.
ZashAll the cool kids use vcard4
techmetx11how much servers do you think support vcard4
ZashAll Modern XMPP servers support PEP, and that is all you need for vcard4
techmetx11Zash: i mean multiple nicknames in a vcard-temp
techmetx11also the vcard4 xep is deferred
Zashvcard-temp is Historical
Zashaka ugly things from before there was a standards process
techmetx11... but still active?
Zashdeferred just means it hasn't moved forward in the standards process for a year
techmetx11if you could just please answer my question
Zashwith how slow the standards process is, one year doesn't really mean much
Dele Olajidehas joined
Dele Olajidehas left
techmetx11i'll try to send a hand-crafted vcard4 retrival request
techmetx11and see if it works
techmetx11has left
techmetx11has joined
colemanhas joined
Zashall I can say is that the Prosody module handling vcard-temp simply takes the XML and saves it as-is
PapaTutuWawahas left
techmetx11has left
techmetx11has joined
techmetx11disroot's server errored out with "No module handling this query"
techmetx11so i'm gonna assume, that this isn't as widely implemented as it might seem
techmetx11now anyway, my question was
miruxhas left
techmetx11how do you implement multiple nicknames in a vcard
thomaslewishas joined
thomaslewishas left
thomaslewishas joined
antranigvhas joined
antranigvhas left
antranigvhas joined
kfvhas left
kfvhas joined
thomaslewishas left
antranigvhas left
atomicwatchhas left
marc0shas left
Yagizаhas left
techmetx11i'm gonna assume multiple elements
Alacer_dsrthas joined
Alacer_dsrthas left
adxhas left
marc0shas left
marc0shas joined
atomicwatchhas joined
Zashhas left
Zashhas joined
marc0shas left
marc0shas joined
kujiuhas joined
Patigahas joined
alhas joined
wurstsalathas left
marc0shas left
marc0shas joined
thomaslewishas left
thomaslewishas joined
Patigahas left
Patigahas joined
debaclehas left
thomaslewishas left
techmetx11has left
techmetx11has joined
thomaslewishas joined
atomicwatchhas left
navhas left
navhas joined
xnamedhas left
techmetx11has left
techmetx11has joined
lovetoxhas left
Kevhas left
thomaslewishas left
thomaslewishas joined
lovetoxhas joined
Kevhas joined
thomaslewishas left
thomaslewishas joined
navtechmetx11: I've just tested and multiple elements does not work with ejabberd.
navIn theory, according to the DTD on XEP-0054 it should be allowed, but also the XEP does not prescribe what to do with multiple instances of the same tag. Ejabberd just keeps the last received.
Patigahas left
navThe DTD does say, in a comment, that "Multiple nicknames must be specified as a comma separated list value" (I guess you've already seen that), and that is also how RFC 6350 specifies it:
NICKNAME-param = "VALUE=text" / type-param / language-param
/ altid-param / pid-param / pref-param / any-param
NICKNAME-value = text-list
(https://datatracker.ietf.org/doc/html/rfc6350#section-6.2.3)