-
MattJ
Holger, is xpath currently used in ejabberd? Would there be any objection if it was a XEP dependency? (or at least a subset)
-
MattJ
I'm pretty wary of XPath, but also wary of NIH something equivalent
-
MattJ
https://github.com/clopen/xpath-receive-email
-
Kev
I'm pretty wary of XPath. I don't think there's any danger of us needing to NIH something *equivalent*, which is where the danger in it lies.
-
Sam
Was trying to figure out a good way to say just that. What Kev said.
-
Kev
What we're likely to need is to NIH a way of referencing a path to an XML element, which ... is a long way short of XPath.
-
Kev
Bonus points if we used constrained XPath so that you could either use an xpath library, or implement something non-insane yourself just to do basic path lookups.
-
Sam
{space:local}/local/{space:*}>someattr there, wrote a whole spec with all the features you could want.
-
Kev
I think even xpath 1 lets you define functions etc. doesn't it? The path formats themselves aren't insane, I think, and are implementable oneself without excessive pain, unless I misremember.
-
Kev
But anything that lets you define functions seems...ill-advised.
-
Sam
"constrained XPath" sounds exactly as bad as "constrained XML" which I have had multiple bugs as a result of us doing (and found multiple issues in other things). That way leads to madness and implementations just ignoring the constraints.
-
Sam
Or security issues when they accidentally ignore the constraints or there's some way to smuggle some escaped function past their constraining code.
-
Kev
There ... is some truth in that.
-
Kev
Actually, looking at XPath, I think even the Location Paths are probably more than anything we'd need in XMPP.
-
Kev
MattJ What's the problem getting solved?
-
MattJ
Kev, clients need to tell their server what information should be sent to their push notification server when offline
-
MattJ
Current spec approach is "just send <body/>", which nobody actually does because of privacy
-
Kev
So something a lot lot simpler than xpath would work fine, presumably?
-
MattJ
Non-standard approach by Tigase is to extract some specific stuff, transform it into JSON, and send that
-
MattJ
But that loses all extensibility
-
MattJ
Yes, definitely (hence why I said "subset")
-
MattJ
But as Sam said, "just" supporting a subset when available libraries implement the full thing can be dangerous
-
MattJ
People will pick off-the-shelf libraries and either fail to disable the dangerous parts or make inadequate attempts to sanitize things
-
Kev
Even ignoring Sam's (I think valid) concerns, using an xpath library for this on the server sounds like some amount of pain - at least for us it'd involve serialising temporarily, parsing that into an appropriate XML doc, running the XPath on it, and then converting into the internal format again, for then reserialising later (or similar).
-
MattJ
Sure, it would be some amount of pain for Prosody too
-
Kev
Probably (with no data to support this) doubling the cost of processing each stanza or something.
-
MattJ
That's a bit over the top, since this wouldn't run on every stanza
-
Kev
Every eligible stanza, right.
-
Kev
But I think that's probably every message, as 'most people' don't have their phone app open 'most of the time'.
-
Kev
But you're right, and that's not on its own a reason to not do it. The inconvenience might be, and the security concerns probably are.
-
MattJ
Okay, so say you're right and it doubles... it goes from how many microseconds to how many microseconds?
-
Kev
^
-
MattJ
I'm not saying bringing in XPath is something I'd enjoy. But I'm trying to get a feel for all our options, because this issue has been stalling progress in this area for years now.
-
MattJ
We have an internal custom "XPath lite" in Prosody, which is of course non-standard
-
MattJ
and as you say, just allows a path to an element, attribute or text content
-
MattJ
As far as I'm concerned, standardizing that (or something like it) is the NIH approach
-
MattJ
Which is not to say it's automatically wrong, if nothing else is suitable
-
MattJ
Thankfully this is also something that would only be needed on servers
-
Kev
I’m pretty comfortable with NIHing something that’s just {NS}ele/… or similar if the alternative is xpath. I think integrating full xpath would actively be a mistake if we only need the former, and Sam’s concerns about subsetting it seem valid.
-
MattJ
So do we have consensus for XEP-xxxx: Element Path Queries?
-
Kev
WFM
-
MattJ
I'll write something up for discussion
-
Kev
Ta.
-
Sam
Excellent, thanks MattJ
-
lovetox
Sorry for my ignorance, what is the use case for that?
-
lovetox
it that not something on the xml lib level, and not the xmpp?
-
MattJ
Use case: > clients need to tell their server what information should be sent to their push notification server when offline
-
MattJ
And XML libraries provide XPath, if they provide anything at all
-
MattJ
SAX parsers like expat (a popular choice for XMPP) tend not to provide XPath because they don't store the document or expose any kind of DOM
-
lovetox
ok thanks
-
goffi
MattJ: As you're working on this use case, I would like to use push notification with a trusted component to send email to users when they get a pubsub notification while offline. For instance says that you have a new comment on a blog post, I would need the pubsub element to construct the email. Privacy is not a problem here as it would be a trusted component with the same admins as the server itself.
-
goffi
MattJ: thus if the protoXEP you're working on or planning to work on would take this use case into account, it would be great
-
MattJ
Yes, it should suffice for that use-case too
-
goffi
neat
-
goffi
MattJ: regarding XPath, I think too that we don't need a full features XPATH and can make our own stuff. XPath is handy to check complex XML trees, but in the case of XMPP it's often not deep, and we can probably filter with simple stuff like element name/namespace + optionally attribute or maybe a index if there are several elements with same name/namespace. Do we need something that can be put in an attribute, or can we use dedicated element for that? Something like `<find_element name="body">` ? Advantage is that we could extend it if necessary in the future.
-
goffi
MattJ: we could also use `id` to put them in attribude, something like: `<something-useful use-element="find_123" /><find-element id="find_123" name="something-useful" ns="urn:example:bla:0" xmlns="urn:example:find-element:0" />`
-
MattJ
That can easily start to get very complex to implement
-
goffi
I don't think so, you end up with simple filtering data that you can either use directly in a loop, or transform easily to an XPATH or equivalent internally. But anyway, it was just random thought, you'll end up with something cool I'm sure.
-
MattJ
https://pad.nixnet.services/s/g9orugzSq is an initial draft
-
Kev
Would it be easier to not have implicit namespace inheritance?
-
MattJ
My feeling is "no" :)
-
MattJ
But maybe
-
MattJ
It would be easier if we actually had a single standard root namespace in XMPP
-
Kev
Ah. Because of stream namespace. Right.
-
MattJ
But we can always specify in the downstream XEPs that everything is in jabber:client or something
-
MattJ
But if it's about implementation complexity for the components without a namespace, we already do that in Prosody and it's not much effort (but I'd be curious to hear if that's not the case in other codebases)
-
goffi
MattJ: what about several elements with same name/namespace (e.g. in your example, you would have an extra `<entry title="The Hobbit" />`
-
goffi
)
-
MattJ
Yeah, I intentionally avoided that for now :)
-
goffi
but we need to know if we get first or last elements
-
goffi
in this case
-
pep.
It only matters if the order of elements is guaranteed I guess. But this spec can still specify it
-
goffi
with <message> it's important as we can have several bodies (with different languages), for blog we have text and xhtml content
-
MattJ
Prosody gives the first
-
MattJ
But I suspect we may want to add indexing and predicates
-
MattJ
I think we're doing this for extensibility, people are going to find uses for those things
-
pep.
Registering to your server features you don't want to see? Curious if that'd be a use-case
-
pep.
"no chatstates, no chat markers, no receipts plz"
-
MattJ
pep., meet https://xmpp.org/extensions/xep-0273.html :)
-
pep.
That title sounds..
-
MattJ
It's from 2009, assume innocence
-
pep.
^^'
-
MattJ
Okay, I got a bit daring and added some more advanced stuff: https://pad.nixnet.services/s/g9orugzSq
-
goffi
MattJ: It looks good to me. It's very similar to lxml's ElementPath.
-
Zash
speccing stanza:find() ?
-
MattJ
Something like that
-
Zash
except it's more limited✎ -
Zash
except stanza:find() is more limited ✏
-
MattJ
But still, I'm now going back to https://hg.prosody.im/prosody-modules/file/8231774f5bfd/mod_cloud_notify_encrypted/mod_cloud_notify_encrypted.lua#l88 to see what that logic would look like translated to XML/paths, and... I don't know
-
Sam
Is there a behavioral difference between entries/entry@title and entries/entry[title]@title?
-
Zash
or upload an util.datamapper schema?
-
Zash
my guess would be that the former may match a tag without the attribute?
-
MattJ
Exactly
-
moparisthebest
Just have the client upload some JavaScript the server can execute to construct what to send...
-
Sam
So one returns empty string one returns no match?
-
Sam
If the attribute doesn't exist do they both return no match?
-
MattJ
Yes
-
Zash
Any need to collect lists of things?
-
MattJ
I'm not sure
-
MattJ
I suspect that the answer is "maybe" but can usually be deduced from the context rather than needing some operator
-
MattJ
i.e. if only one result is expected, just take the first
-
MattJ
Which is probably going to be the most common
-
MattJ
But as I say, unless we can figure out how to actually apply this, I'm unconvinced it's useful
-
Link Mauve
I remember a discussion recently where someone wanted to send wasm blobs to other entities for processing. :°)
-
moparisthebest
Hey that's better than JavaScript let's do it
-
MattJ
goffi, I think in your case you'd be happy bouncing the whole stanza to the push server, I assume
-
MattJ
Because you're going to email it, and I assume that won't be encrypted, so you don't have anything to hide from the push service
-
goffi
MattJ: indeed, I would be happy with the whole stanza, the component is trustable no privacy problem there.
-
MattJ
The problem for the Siskin-style push notifications is that they need to be 1) summarized (Apple has size limits on notifications) and 2) encrypted (so neither Apple nor the push service see any message details)
-
MattJ
#2 is easy enough, but #1 is currently implemented using logic on the server side that isn't extensible and right now even depends on experimental XEPs
-
MattJ
Some discussion is at https://github.com/tigase/tigase-xeps/issues/4
-
MattJ
An alternative approach is to spec the summarization process, and make sure that can be negotiated and evolved over time
-
Zash
Per XEP treatment? Would be sorta in line with MAM, CSI, Carbons etc
-
MattJ
Okay, so instead of all the path query stuff: https://pad.nixnet.services/s/GPBR4xa4k
-
MattJ
Encode some rules directly into the server, handling all current use cases, allow for future extensibility if new ones arise
-
pep.
"MattJ> Because you're going to email it, and I assume that won't be encrypted, so you don't have anything to hide from the push service" I want to challenge the reasoning about not having to hide from the push service if it's not encrypted :x
-
pep.
I mean, I don't find this as obvious
-
MattJ
Read it as "you don't have anything that can be hidden"
-
pep.
from whom
-
MattJ
The push service
-
pep.
Well you may trust your server and the MTA but not the push service
-
MattJ
Okay. So what are you going to do about it?
-
pep.
I don't know, I'm just saying I don't find it as obvious as you made it sound
-
MattJ
Okay
-
pep.
Text as sibling isn't valid in XMPP right? So you don't need to worry about it?
-
MattJ
I don't think anything actually forbids it, other than our collective common sense
-
MattJ
I meant to note that it would result in undefined behaviour
-
pep.
Good job for the spec :)
-
MattJ
I've been working with SASL2, and just wanted to see how much of this tangle of semi-related XEPs we could sort out at the same time
-
Link Mauve
Email actually has some deployed e2ee, namely OpenPGP and S/MIME.
-
Link Mauve
Both could be used also with a gateway.
-
MattJ
Link Mauve: someone else can have the fun of specifying and implementing that 🙂
-
Link Mauve
Yup.
-
MattJ
For the 5 users it will ve used by✎ -
Link Mauve
I’ve successfully avoided e2ee on XMPP altogether so far, hoping to keep under the radar. o:)
-
MattJ
For the 5 users it will be used by ✏