This is probably me being stupid, because I'm sure that I've done this before, but how do you get entity caps for the account JID? You're not likely to have a presence subscription to yourself and the stream feature is for the server, so if you need to check if your own account supports something you have to just do a disco#info request and can't cache the caps hash, I guess?
machas left
xnamedhas left
9lakeshas left
Zash
Something about giving clients a pile of (jid, caps-hash) pairs is on my XEP wishlist.
Zash
I may even have a prototype somewhere, tho focused on e.g. components
Wojtekhas joined
jalalhas left
Dele Olajidehas joined
jonas’
Sam, I don't think that the account even gives you a disco#info caps hash
Sam
So I have to store features mapped to JIDs and features mapped to hashes mapped to JIDs? That doesn't seem ideal.
Sam
(but it tracks with how everything in XMPP is special cased; I also just discovered that there's *another* bookmarks compatibility thing I forgot about in 0411 and the whole time I was looking at conversations code it was actually using that and not the PEP native stuff, so I'm about ready to table flip and give up on developing an XMPP client at this point). Thanks for the confirmation anyways.
Zash
Hmm, JID→feature-set mapping seems sensible to have, no?
Zash
and caps hash can be derived from feature-set
Sam
Sure, it's sensible by itself, but not if I *also* have to do a JID->caps->feature-set and keep both and check both just in case a jid has or does not have caps
Wojtekhas left
Zash
What about the rare case of caps injection?
qwestionhas joined
Sam
What is caps injection?
Zash
or whatsitcalled, if someone manages to have two disco#info sets with the same caps✎
Zash
or whatsitcalled, if someone manages to have two disco#info sets with the same caps-hash ✏
Wojtekhas joined
Sam
That would be bad, but it seems reasonable to assume the hash method is safe and that's not going to happen.
Zash
Wasn't the current disco#info and caps broken that way already due to something with separator characters?
machas joined
Sam
*facepalm* of course it would be, I'll have to look
Sam
There's a security considerations mention of caps poisoning, but it only mentions it for the legacy format (which I'm not bothering to support)
jonas’
"the legacy format"?
jalalhas joined
Sam
It's part of the spec. Caps was updated at some point so the spec contains a bunch of "how to be compatible with old caps" stuff
jonas’
to be clear: 0115 is still broken. 0390 is not broken, or at least I wouldn't know it was
Sam
0115 is broken but doesn't mention it anywhere?
jonas’
that seems accurate
jonas’
nothing stops you from stuffing a `>` in some var or so to generate a collision
Sam
Where can I find info about this? It seems *really* important that it be in the security considerations section or something
jonas’
mailing list post from 2008 or so
Zash
as usual 😱️
Sam
I really should just give up on XMPP, this is infuriating. Rage quitting for the day and will get back to this later. Thanks for letting me know.
More and more server-side forklift upgrade modules! ✏
jonas’
Sam, oh, so there's a bandaid in '115:
> Note: If the four characters '&', 'l', 't', ';' appear consecutively in any of the factors of the verification string S (e.g., a service discovery identity of 'SomeClient<http://jabber.org/protocol/muc') then that string of characters MUST be treated as literally '<' and MUST NOT be converted to the character '<', because completing such a conversion would open the protocol to trivial attacks.
jonas’
but this is unclear, weird and I would be surprised if it was watertight (what about `&lt;`?) or if everyone implements this correctly
Zash
:<
Link Mauve
Sam, 0411 has been superseded by 0402 though.
Sam
Link Mauve: yup, I'm using 0402. Turns out Other things are still using 0411 though.
Sam
(it also appears deprecated, not superseded, but that's a minor nit; it would just be easier to discover the new thing if we updated, that, might be worth doing at some point; adding it to my list of cleanup stuff to do / mail the list about)
Link Mauve
Superseded means another specification provides the same usecase, while deprecated and obsolete are statuses for the specification itself.
Link Mauve
A specification can be deprecated/obsoleted without any superseding one.
Sam
"deprecated but not superseded" I should say.
Sam
Oh, no, it is, nevermind
Link Mauve
The big red thing at the top mentions both.
Link Mauve
The one everyone conveniently skips. ^^'
Sam
I do the same thing every time (look at column headers for a "suprseded by" and don't read the boilerplate text that is different sometimes. Just a formatting thing.
pulkomandy
> The big red thing at the top mentions both.
> The one everyone conveniently skips. ^^'
The web trained us to ignore big flashing bright things because usually, they are ads and not relevant content (there is an ux study about this somewhere)
Sam
Anyways, regardless, back to the original issue: apparently I have to treat the account disco different from every other disco because I can't use caps for the first but can for everything else.
jonas’
Sam, no, you cannot use caps for MUC either, for instance
jonas’
(for instance)
jonas’
(nor for pubsub)
Link Mauve
For anything not sending you its presence.
jonas’
yeah
jonas’
Sam, FWIW, how I do it in aioxmpp is that the disco#info client code has a cache and the caps code listens for presences and injects stuff in the disco#info cache based on (validated) caps hash -> disco#info mappings (which it may also look up).
jalalhas left
Link Mauve
This is also how we do it in slixmpp fyi.
Sam
Cool, thank for confirming. I've got a lot of rewriting to do, but it's likely not happening this morning or I'm going to lose it. Time to step away from the computer and stop dealing with this for now. Thanks again.
Wojtekhas left
Wojtekhas joined
nephelehas joined
jonas’
pulkomandy, FTR, I skipped any kind of headers even before I started using the web ;)
machas left
nephelehas left
Zash
What's that, we need a deprecated+see-other-XEP metacombo?
jonas’
check in the xslt if there's any superseded by?
9lakeshas joined
Sam
It's in the appendix as well; I'm going to submit a PR to add it to the top in a (hopefully?) more visible way too before I head out
me9has joined
Sam
Okay, I fixed at least the most minor of the things that have been bothering me this morning. I feel slightly better: https://github.com/xsf/xeps/pull/1167
jalalhas joined
Link Mauve
The big bright red place was not enough?
Vaulorhas left
Link Mauve
“Developers desiring similar functionality are advised to implement the protocol that supersedes this one (XEP-0402).” ← here.✎
Sam
It's easier to pull data out of a table quickly than it is to find it in paragraph
Link Mauve
“Developers desiring similar functionality are advised to implement the protocol that supersedes this one (XEP-0402).” ← here. ✏
Link Mauve
“Developers desiring similar functionality are advised to implement the protocol that supersedes this one (XEP-0402).” ← here. ✏
homebeachhas left
Matrix Traveler (bot)has left
Matrix Traveler (bot)has joined
homebeachhas joined
Sam
Plus this is a standard warning so you don't expect it to change so you glance right over it and don't read it because you've read it a thousand times before and it doesn't include a link at the end
Dele Olajidehas left
Sam
(or at least, I do)
9lakeshas left
Dele Olajidehas joined
Dele Olajidehas left
Dele Olajidehas joined
Dele Olajidehas left
machas joined
marc0shas left
marc0shas joined
pasdesushihas left
pasdesushihas joined
Dele Olajidehas joined
Dele Olajidehas left
qwestionhas left
jubalhhas left
jonas’
Sam, I like it, thanks!
jonas’
will be in the next round of XEP rebuilds (tuesday)
Vaulorhas joined
Millesimushas left
Sam
jonas’: Thanks, that should fix me always missing that anyways
cedarhas left
selurveduhas left
selurveduhas joined
cedarhas joined
J Marinarohas left
emushas left
xnamedhas joined
xnamedhas left
machas left
emushas joined
xnamedhas joined
Laurahas left
machas joined
Laurahas joined
xeckshas left
xeckshas joined
me9has left
Dele Olajidehas joined
qwestionhas joined
Yagizаhas left
J Marinarohas joined
Wojtekhas left
jubalhhas joined
Millesimushas joined
Dele Olajidehas left
debaclehas joined
jubalhhas left
alacerhas joined
alacerhas left
alacerhas joined
jubalhhas joined
cedarhas left
cedarhas joined
jubalhhas left
alacerhas left
jubalhhas joined
cedarhas left
cedarhas joined
PapaTutuWawahas joined
xeckshas left
machas left
emushas left
xeckshas joined
emushas joined
me9has joined
Sam
How are others defending against the pre-image attacks listed in this email from earlier? I'm back at my desk now and I can do the note the XEP mentions for attack 1, but as the email mentioned I see no way it's possible to defend against some of the others. Attack 4 can be worked around, but are people doing that? the XEP doesn't even mention that one.
jonas’
probably not
Zash
By not worrying too much about it, I imagine.
jonas’
Sam, there's a reason I made XEP-0390 after all
Zash
You could also separate caches
Sam
yah, that's what I suspected. That's unfortunate. Maybe it's not worth actually implementing the fix since there will be other trivial ones that can't be fixed.
homebeachhas left
Matrix Traveler (bot)has left
Matrix Traveler (bot)has joined
homebeachhas joined
Link Mauve
I usually try to make sure to have one cache per JID, which somewhat defeats the point.
Link Mauve
I also try to advocate for XEP-0390, but with few results so far.
Link Mauve
I made a Prosody module which gives 0390 hashes to every local user which has published caps.
Zash
Doesn't defeat the point, I think, you reduce traffic to 1 query per client/change at least.
Link Mauve
Yeah.
Zash
And it's probably possible to store the data efficiently, if you e.g. use the '390 algorithm or some XML normalization to deduplicate the disco#info payloads
Zash
As in, use it internally
PapaTutuWawahas left
jubalhhas left
SouLhas left
qwestionhas left
nephelehas joined
xnamedhas left
nephelehas left
nephelehas joined
SouLhas joined
nephelehas left
nephelehas joined
nephelehas left
nephelehas joined
nephelehas left
xnamedhas joined
paulhas left
jubalhhas joined
paulhas joined
SouLhas left
SouLhas joined
me9has left
atomicwatchhas left
xeckshas left
xeckshas joined
nephelehas joined
qwestionhas joined
nephelehas left
nephelehas joined
nephelehas left
mathieui
do we have some kind of consensus-ish view on how media cards should be standardized in XMPP?
mathieui
(the main issue here in my opinion is privacy considerations, should a server proxy/cache media if it can, what should be the default, etc)
Zash
do we have some kind of definition of what "media cards" are?
Link Mauve
mod_ogp’s kind?
mathieui
I think twitter has the gist of it, declined differently on all the different platforms though of course, https://developer.twitter.com/en/docs/twitter-for-websites/cards/overview/abouts-cards
pasdesushihas left
pasdesushihas joined
mathieui
Link Mauve, yeah, somewhat
mathieui
ofc there is also the question of embedding media & players, which is done through iframes in the various web things
Link Mauve
Right, we can’t really have iframes in poezio.
Link Mauve
… or can we?
mathieui
DON’T
Link Mauve
:3
jalalhas left
Link Mauve
I think what we’re really lacking in poezio so far is WebGL.
Link Mauve
Thankfully, I have a half-block backend in GLFW, using a render node directly!
mathieui
can’t we run a virtual display with llvmpipe enabled, then run a webgl-capable browser in fullscreen and take 30 screenshots a second, converted to half-blocks?