jonasw, Movim and SàT put PubSub URIs there AFAIK. ✏
Link Mauve
Not web ones, but xmpp: ones.
Link Mauve
daniel, that’s also my view of it.
moparisthebesthas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
edhelas
I moved my pubsub uris back to a "non standard" pep node for now
edhelas
because it was creating conflicts with the clients that are starting to put bookmarks in PEP (all the list in one item) clearing out the Pubsub URIs that Movim saved
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
jonasw
ah yes, that’s also a nice issue with everything-in-one-item
jonasw
it becomes tricky to deal with elements you don’t know, because normally in XMPP you can just drop them✎
jonasw
it becomes tricky to deal with elements you don’t know, because normally in XMPP (as a client) you can just drop them ✏
jonasw
in this case you need to preserve them
edhelas
yup
jonasw
this would be much easier with one-item-per-bookmark, because you can just ignore items you don’t know and only update those you do know
daniel
jonasw: if it's just about that you can very easily do that with regular bookmarks as well
ThibGhas joined
daniel
Conversations just ignores anything it doesn't know
jonasw
it /can/ be done, but it’s not straightforward
Ge0rG
I want to have bookmarklets, which can execute code in the context of the current MUC.
Andrew Nenakhovhas joined
jonasw
yeah, I’m pretty sure that aioxmpp drops everything not in XEP-0048
SaltyBoneshas left
Wiktor
Ge0rG: what would they exactly do? send some text?
jonasw
so if you’re using neither <url/> nor <conference/>, it gets lost
Andrew Nenakhovhas left
SaltyBoneshas left
Andrew Nenakhovhas joined
Tobiashas joined
Link Mauve
Wiktor, for instance your password.
Link Mauve
I remember both Jappix and Empathy were victims of such RCE.
I wouldn’t exclude bookmark names from being vulnerable to that kind of things, in web clients. ^^'
Link Mauve
… I should have such a bookmark in my test account!
jonasw
gotta love the web
jonasw
clever
lumihas joined
lorddavidiiihas left
mimi89999has joined
mimi89999has joined
j.rhas joined
rtq3has joined
mimi89999has joined
mimi89999has joined
Steve Killehas joined
Guushas left
andyhas joined
lorddavidiiihas left
Dave Cridlandhas left
Dave Cridlandhas left
rishiraj22has left
muppethhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Guushas left
muppethhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
rishiraj22has left
lskdjfhas joined
Dave Cridlandhas left
Valerianhas left
Valerianhas joined
Dave Cridlandhas left
la|r|mahas joined
la|r|mahas joined
la|r|mahas joined
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
rionhas joined
alacerhas joined
lorddavidiiihas left
alacerhas left
alacerhas joined
lorddavidiiihas left
Guushas left
Guushas left
Guushas joined
Valerianhas left
Valerianhas joined
Valerianhas left
Zashhas joined
moparisthebesthas joined
moparisthebesthas joined
alacerhas left
lnjhas left
rionhas left
rionhas joined
muppethhas joined
muppethhas joined
andyhas left
lorddavidiiihas left
Valerianhas joined
mikaelahas left
mimi89999has joined
mimi89999has joined
marmistrzhas left
mimi89999has joined
mimi89999has joined
rionhas left
rionhas joined
muppethhas joined
Valerianhas left
Valerianhas joined
muppethhas joined
mikaelahas joined
rtq3has left
mikaelahas left
mikaelahas left
mikaelahas joined
lskdjfhas joined
lskdjfhas left
Guushas left
Guushas left
Guushas joined
Dave Cridlandhas left
Guushas left
Dave Cridlandhas left
Guushas joined
danielhas left
danielhas left
Wiktorhas joined
lskdjfhas left
lskdjfhas left
rionhas left
mikaelahas left
lskdjfhas joined
lskdjfhas left
lskdjfhas left
lskdjfhas left
goffi
https://github.com/git-federation/gitpub ==> and now they re-invent something on activityPub, it's a pitty to see coming a missed occasion for XMPP, once again.
lskdjfhas left
jonasw
goffi, is it missed already though?
mimi89999has left
goffi
if gitlab, gogs and gittea are following, pretty much yes.
lskdjfhas left
jonasw
although, I can’t blame web applications for not wanting to run another daemon
jonasw
we’d need a proper solution for stabily running a client or server or component in common web frameworks
jonasw
goffi, maybe you could contribute there and turn it around?
mimi89999has joined
mimi89999has joined
lskdjfhas joined
goffi
jonasw: I'm already working on XMPP based web framework, and I'm doing it on my freetime, I can't fight at all fronts.
ThibGhas joined
ThibGhas joined
Dave Cridlandhas left
Dave Cridlandhas left
lnjhas joined
rishiraj22has left
rionhas joined
mimi89999has joined
mimi89999has joined
Alexhas joined
mimi89999has joined
mimi89999has joined
lskdjfhas left
rtq3has joined
lskdjfhas joined
mimi89999has joined
mimi89999has joined
moparisthebesthas joined
lskdjfhas left
moparisthebesthas joined
mimi89999has joined
mimi89999has joined
mimi89999has joined
mimi89999has joined
lskdjfhas left
mimi89999has joined
lskdjfhas left
mimi89999has joined
mikaelahas joined
mimi89999has joined
mimi89999has joined
mimi89999has joined
mimi89999has joined
mimi89999has joined
mimi89999has joined
blablahas joined
mimi89999has joined
mimi89999has joined
lskdjfhas left
rishiraj22has left
rionhas left
mimi89999has joined
mimi89999has joined
mimi89999has joined
andyhas joined
mimi89999has joined
mimi89999has joined
mimi89999has joined
Andrew Nenakhovhas left
marmistrzhas joined
mimi89999has joined
Andrew Nenakhovhas joined
danielhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Guushas left
mimi89999has joined
rionhas joined
Dave Cridlandhas left
rtq3has left
Guushas left
lskdjfhas left
marchas joined
lskdjfhas left
lnjhas left
lskdjfhas left
Valerianhas left
Valerianhas joined
lskdjfhas left
doshas joined
Dave Cridlandhas left
tahas left
Valerianhas left
Valerianhas joined
lskdjfhas left
jubalhhas left
lskdjfhas left
jubalhhas joined
lskdjfhas left
rtq3has joined
j.rhas joined
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
rionhas left
Andrew Nenakhovhas left
j.rhas joined
j.rhas joined
Andrew Nenakhovhas joined
kasper.dementhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
lskdjfhas left
rionhas left
Guushas left
Guushas left
Guushas joined
Valerianhas left
lnjhas joined
lskdjfhas left
Guushas left
Guushas left
Guushas left
Guushas left
Guushas joined
danielhas left
mimi89999has joined
mimi89999has joined
andyhas left
tahas left
jerehas joined
danielhas left
mimi89999has joined
mimi89999has joined
mimi89999has joined
mimi89999has joined
Ge0rG
Dark corners of XMPP. Lection #23: prosody will put 0184 ACKs from some clients into MAM, but not from others. It depends on whether they are type=chat.
Bunneh
Ge0rG: Submit first draft of Mobile Considerations #23
https://github.com/xsf/xeps/pull/23
if not(orig_type == "chat" or (orig_type == "normal" and stanza:get_child("body")) ) then you_shall_not_carbon_mam(); end
Ge0rG
Oh, wait.
Ge0rG
daniel: I mean: Weren't you sending chat *acks*?
Ge0rG
Same holds true for markers and any other bodyless messages.
Holger
Type chat without body should be carboned but not MAM-stored right?
daniel
Ja deliberately make them type chat yes
Ge0rG
Holger: who said that=
Holger
The XEPs?
mimi89999has joined
Ge0rG
CSNs are defined as `chat`.
Ge0rG
Holger: now you make me sad.
lnjhas left
rtq3has left
flow
Ge0rG, have a cookie
mimi89999has joined
Steve Killehas left
Ge0rG
Holger: sad because of https://github.com/xsf/xeps/pull/434
Steve Killehas left
jonasw
Ge0rG, do some work on https://xmpp.org/extensions/xep-0409.html
mimi89999has joined
Ge0rG
jonasw: sure, when MIX is finished.
mimi89999has joined
jonasw
since when do you care about MIX?
Holger
Ge0rG: Ah, routing 2.0 will fix everything.
j.rhas joined
Ge0rG
Holger: 0280 rules tl;dr are "a server may do anything, or not do it, or make demons fly out of your nose and be compliant"
Ge0rG
0313 only asks for <body> messages to be archived
Ge0rG
I'm not sure why anybody would want to archive any <chat> messages.
jonasw
I am reading that xep for the first time now, and I like how it handles the NG vs. non-NG interop
Ge0rG
jonasw: it's really intriguing, I'll need to think it through thoroughly
mimi89999has joined
jonasw
Kev has done some good work there, I expected much less given the time frame in which it was done.
mimi89999has joined
Holger
Ge0rG:
> I'm not sure why anybody would want to archive any <chat> messages.
You mean why people would *not* want to archive bodyless chat messages?
Kev
"Kev ... I expected much less"
Story of my life.
jonasw
c’mon :)
jonasw
do you think we can get a <stanza-id/> in the mandatory reflection to all resources?
jonasw
(on the sender side)
jonasw
that would be truly amazing
Kev
Yes, but is that MAM or routing?
Ge0rG
Holger: No, I mean why people *would* want to archive bodyless chat messages.
Holger
Read markers for example?
Ge0rG
Holger: also CSNs
jonasw
Kev, good question; I would like to have it mandatory for every service implementing MAM though. this avoids us having to namespace-bump MAM.
jonasw
i.e. make it mandatory in IM-NG for a service which also offers any XEP-0313 namespace to put <stanza-id/> in the reflections
Ge0rG
Holger: not sure if you heard of it, but MAM storage of CSN made my MAM DB explode and yax.im melt down, just recently
Ge0rG
Kev: mandatory stanza IDs for "important" messages are good enough for me, so MAM > routing
Holger
Ge0rG: I haven't, but not storing read markers sucks UX-wise and I'm sure there are more examples.
Ge0rG
Holger: so we have two examples now of things that are of the same type but needs to be handled differently. What now?
Kev
Holger: I have thoughts on that too, but I've not written them up yet.
Ge0rG
ACKs are of type=undefined, so even more meh.
Kev
But I think that you want your archive to be collating such things rather than storing verbatim.
lumihas left
Ge0rG
Kev: that sounds like a database synchronization problem. Send deltas, update internal state.
Holger
Yes such optimizations would be nice. I'm just saying that throwing this stuff away is not a good solution.
jonasw
oh, it’s in there already:
> When reflecting an IM-NG client's outbound bare-JID messages, the server SHOULD reflect the archived version (i.e. after any transforms have taken place).
jonasw
IIRC the archived version contains the <stanza-id/>
Ge0rG
jonasw: yes, it should
jonasw
it should or it SHOULD?
Ge0rG
jonasw: don't ask me these questions please. It's friday and I'm having tremendous "fun" at work already.
Ge0rG
I only started this because it bothered me that I didn't see ACKs of messages on my other client.
jonasw
here, have a cookie
jonasw
🍪
Ge0rG
And there is no easy solution.
jonasw
and you should please appreciate that I pasted you a cookie because you know how much that makes my poezio behave weird!
Ge0rG
jonasw: sorry, but cookies trigger me since the GDPR faux-compliance of ignorant americans made cookie dialogs look like good UX
Ge0rG
really sorry.
jonasw
🍉
jonasw
some cool water melon maybe?
Ge0rG
jonasw: since running emoji_ascii the situation has considerably improved for me. Except for the jabber❌namespace.
jonasw
Ge0rG, you’re not alone, github does it too: https://github.com/xsf/xeps/pull/664
Ge0rG
it's a rainy 18°C here. But I had to change my munin cpu temp warning threshold from 70° to 80°
jonasw
right, I forgot that only Dresden seems to be shielded from the bad^Wgood and plant-saving weather
Ge0rG
LOL
jonasw
☕
jonasw
then that maybe^?
Ge0rG
that made my day.
rtq3has joined
jonasw
Ge0rG, finally found something good for you \o/
Ge0rG
next time somebody complains, I'll point at that issue
jonasw
I need to re-write the commit message, because I’m going to be complaining a lot ;-)
Ge0rG
I've had a 1.5h conference call today, where the application owner and me tried to explain to the indian chief developer that exposing an SQL-like API over the internet, with some regex filters strapped on top for access control, just doesn't cut it.
Ge0rG
The final words of the app owner were "I hope we are aligned now"
j.rhas joined
Ge0rG
not sure if it was a command or a threat.
kasper.dementhas joined
Ge0rG
But back to the topic. Even with IM-NG, we'll still have to define rules for handling of legacy messages
Ge0rG
So back to https://github.com/xsf/xeps/pull/434
Ge0rG
Would it make sense to make 0184 and others use type=chat?
Ge0rG
or type=<type of what you respond to>?
Ge0rG
MUC ACKs should go to the MUC, so that we get O(n²), right?
jonasw
Ge0rG, the rules are defined in there:
> In order for interoperability with other entities (contacts, remote servers etc.) that don't support IM-NG, old-style full-JID messages also need to be handled. When a server receives a message with type other than than 'groupchat' or 'headline' that does not contain an <im-ng xmlns='urn:xmpp:im-ng:0'> element it is to be routed by the above rules as if they were sent to the bare JID
jonasw
plus:
> Any message that is routed to all IM-NG clients is stored in the MAM archive, where available, and any message that would not be routed to all IM-NG clients is not stored in the MAM archive
jonasw
so if to bare JID => archived and copied. if to full JID and not groupchat and not headline => archived and copied. if to full JID and (groupchat or headline) => routed to full JID
Ge0rG
What about CSNs?
jonasw
are they of type headline or groupchat?
Ge0rG
type=chat.
jonasw
archived and copied.
Kev
At the Summit we discussed that they should really be presence rather than messages, FWIW.
jonasw
I’ll make you a flow chart, Ge0rG.
Ge0rG
jonasw: no thanks
jonasw
:)
jonasw
Kev, that, too
Ge0rG
jonasw: my question wasn't "what happens to CSNs under these rules". I was able to figur that out on my own, I think. My intention was "what *should* happen to them, as the rules are obviously inadequate"
Valerianhas joined
jonasw
Ge0rG, ah, put them into presence
jonasw
that seems like a good solution for me
Ge0rG
so the IM-NG server will translate directed presence with a CSN into a message on the border, and back?
jonasw
need to think about implications of sending directed presence all the time, but on the first order this seems like a good thingf
lnjhas joined
jonasw
Ge0rG, uh, interesting idea :)
Ge0rG
directed presence will get cached on the server, right?
jonasw
(but I was actually talking generally. clients should put them into presence)
jonasw
directed presence is tricky
Ge0rG
Yeah, so while you are constructing the IM-NG New World Order, I'm not receiving Carbons of my ACKs!
Kev
The other idea I have floating around is having <transient/>, which is rougly <no-store/>, and carefully speccing that a CSN is <transient/>, and that anything that is <transient/> and "shouldn't be" shouldn't be processed by a client.
tahas left
Kev
So that you can't e.g. inject <transient/> in a chat stanza in order to maliciously evade archiving.
jonasw
that sounds quite fragile
Ge0rG
> maliciously evade archiving.
That is very evil.
Kev
Because <no-store/> that your server listens to and your client doesn't care about is obviously bad.
jonasw
but it might be worthwhile to have that
mikaelahas left
jonasw
I mean provision this in IM-NG so that servers support it right away.
Ge0rG
Ephemeral Messages are doomed now.
Kev
jonasw: Which that. My floaty idea, or the thing I say is bad?
jonasw
and so that clients drop it right away
jonasw
your floaty idea
Kev
Third idea is that we requisition headline.
jonasw
lemme rephrase:
The <transient/> thing sounds a bit fragile, but it might be worthwhile to put that into IM-NG right away because it’s likely that we’ll need such a thing down the road.
Kev
But now we're getting into even dodgier territory, potentially.
Ge0rG
What about we define a list of rules which messages are to be handled as transient, like in https://xmpp.org/extensions/xep-0280.html#which-messages
jonasw
I’m not 100% sure about CSN-in-<presence/> either, because that has interesting implications regarding directed presence and things which do things with directed presence (MUC, Invisible Command, …)✎
kasper.dementhas joined
Kev
Ge0rG: Because it's important that we don't have a situation where a server's MAM implementation needs complete knowledge of all standard and non-standard extensions.
jonasw
I’m not 100% sure about CSN-in-<presence/> either, because that potentially has interesting implications regarding directed presence and things which do things with directed presence (MUC, Invisible Command, …) ✏
jonasw
(again)
Kev
But if we go with 'floaty idea', you have more or less that, without the server problem.
jonasw
then only the client needs to know about it, and that is probably fine because it needs to know about the message payload anyways to do something sane with it
Kev
The server listens to the <transient/> flag, and the client is responsible for checking that a message that should be archived wasn't received without it.
Kev
jonasw: Right.
Ge0rG
Kev: so that client-side message processing has two stages. Stage 1 is for all messages, and may not add anything to the database, and stage 2 is for non-transient messages only and may add new items?
jonasw
what
goffihas joined
Ge0rG
And there is a huge fat `// WARNING! NO PERSISTENCE ABOVE THIS COMMENT` line in between?
Kev
Ge0rG: There's a few ways one could implement it, but something like that would work.
jonasw
I’d probably go more with: a general stage which works like the servers MAM (i.e. ignore anything with <transient/> on it) and down the road in the pipeline some component might add something to the database in response to a message which was <transient/> if and only if it makes sense to do so
jonasw
but in general you wouldn’t persist <transient/> stuff anyways
jonasw
that’s the point of transient. I mean you could have been offline at the time and wouldn’t have gotten the message, so storing it seems not needed in any case
Kev
I'd probably go with an initial screen process that rejects any stanza that doesn't verify the right transientness for the present payloads, but yes, any of these work.