XSF Discussion - 2018-06-08

Link Mauve: to answer your question from yesterday. I'm not interested in bookmarks 2 per se but I'm interested in moving bookmarks to pep asap.

And I'm afraid bookmarks 2 is uncharted territory for a lot of reasons and harder to pull of then 48-on-pep

With only marginal improvements over 48-on-pep

Do bookmarks have any other use besides storing user's MUCs?

Andrew Nenakhov, I think some web folks put website bookmarks in there. Movim and SáT maybe

jonasw, Movim and SàT put PubSub URIs there AFAIK. ✏

Not web ones, but xmpp: ones.

daniel, that’s also my view of it.

I moved my pubsub uris back to a "non standard" pep node for now

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

ah yes, that’s also a nice issue with everything-in-one-item

it becomes tricky to deal with elements you don’t know, because normally in XMPP (as a client) you can just drop them ✏

in this case you need to preserve them

yup

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

jonasw: if it's just about that you can very easily do that with regular bookmarks as well

Conversations just ignores anything it doesn't know

it /can/ be done, but it’s not straightforward

I want to have bookmarklets, which can execute code in the context of the current MUC.

yeah, I’m pretty sure that aioxmpp drops everything not in XEP-0048

Ge0rG: what would they exactly do? send some text?

so if you’re using neither <url/> nor <conference/>, it gets lost

Wiktor, for instance your password.

I remember both Jappix and Empathy were victims of such RCE.

Oh, I didn't get the joke.

:p

I was thinking about mIRC scripts ;)

do I want to know, Link Mauve?

(yes, I do)

jonasw, https://usn.ubuntu.com/1250-1/

ah, but that wasn’t about bookmarks

Basically, /nick <img src=invalid onerror="alert('Hello world!')">

Ah, no.

good ol’ HTML nicknames

I wouldn’t exclude bookmark names from being vulnerable to that kind of things, in web clients. ^^'

… I should have such a bookmark in my test account!

gotta love the web

clever

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.

goffi, is it missed already though?

if gitlab, gogs and gittea are following, pretty much yes.

although, I can’t blame web applications for not wanting to run another daemon

we’d need a proper solution for stabily running a client or server or component in common web frameworks

goffi, maybe you could contribute there and turn it around?

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.

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.

Ge0rG: Submit first draft of Mobile Considerations #23 https://github.com/xsf/xeps/pull/23

Bunneh: Uhm, no.

:D

Same for Carbons. At least it's consistent.

now that’s news ✏

Ge0rG: are carbons ever type Chat though?

daniel: dunno. Weren't you sending chat carbons?

Ge0rG: why would I send carbons of any type?

if not(orig_type == "chat" or (orig_type == "normal" and stanza:get_child("body")) ) then you_shall_not_carbon_mam(); end

Oh, wait.

daniel: I mean: Weren't you sending chat *acks*?

Same holds true for markers and any other bodyless messages.

Type chat without body should be carboned but not MAM-stored right?

Ja deliberately make them type chat yes

Holger: who said that=

The XEPs?

CSNs are defined as `chat`.

Holger: now you make me sad.

Ge0rG, have a cookie

Holger: sad because of https://github.com/xsf/xeps/pull/434

Ge0rG, do some work on https://xmpp.org/extensions/xep-0409.html

jonasw: sure, when MIX is finished.

since when do you care about MIX?

Ge0rG: Ah, routing 2.0 will fix everything.

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"

0313 only asks for <body> messages to be archived

I'm not sure why anybody would want to archive any <chat> messages.

I am reading that xep for the first time now, and I like how it handles the NG vs. non-NG interop

jonasw: it's really intriguing, I'll need to think it through thoroughly

Kev has done some good work there, I expected much less given the time frame in which it was done.

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 ... I expected much less" Story of my life.

c’mon :)

do you think we can get a <stanza-id/> in the mandatory reflection to all resources?

(on the sender side)

that would be truly amazing

Yes, but is that MAM or routing?

Holger: No, I mean why people *would* want to archive bodyless chat messages.

Read markers for example?

Holger: also CSNs

Kev, good question; I would like to have it mandatory for every service implementing MAM though. this avoids us having to namespace-bump MAM.

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

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

Kev: mandatory stanza IDs for "important" messages are good enough for me, so MAM > routing

Ge0rG: I haven't, but not storing read markers sucks UX-wise and I'm sure there are more examples.

Holger: so we have two examples now of things that are of the same type but needs to be handled differently. What now?

Holger: I have thoughts on that too, but I've not written them up yet.

ACKs are of type=undefined, so even more meh.

But I think that you want your archive to be collating such things rather than storing verbatim.

Kev: that sounds like a database synchronization problem. Send deltas, update internal state.

Yes such optimizations would be nice. I'm just saying that throwing this stuff away is not a good solution.

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).

IIRC the archived version contains the <stanza-id/>

jonasw: yes, it should

it should or it SHOULD?

jonasw: don't ask me these questions please. It's friday and I'm having tremendous "fun" at work already.

I only started this because it bothered me that I didn't see ACKs of messages on my other client.

here, have a cookie

🍪

And there is no easy solution.

and you should please appreciate that I pasted you a cookie because you know how much that makes my poezio behave weird!

jonasw: sorry, but cookies trigger me since the GDPR faux-compliance of ignorant americans made cookie dialogs look like good UX

really sorry.

🍉

some cool water melon maybe?

jonasw: since running emoji_ascii the situation has considerably improved for me. Except for the jabber❌namespace.

Ge0rG, you’re not alone, github does it too: https://github.com/xsf/xeps/pull/664

it's a rainy 18°C here. But I had to change my munin cpu temp warning threshold from 70° to 80°

right, I forgot that only Dresden seems to be shielded from the bad^Wgood and plant-saving weather

LOL

☕

then that maybe^?

that made my day.

Ge0rG, finally found something good for you \o/

next time somebody complains, I'll point at that issue

I need to re-write the commit message, because I’m going to be complaining a lot ;-)

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.

The final words of the app owner were "I hope we are aligned now"

not sure if it was a command or a threat.

But back to the topic. Even with IM-NG, we'll still have to define rules for handling of legacy messages

So back to https://github.com/xsf/xeps/pull/434

Would it make sense to make 0184 and others use type=chat?

or type=<type of what you respond to>?

MUC ACKs should go to the MUC, so that we get O(n²), right?

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

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

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

What about CSNs?

are they of type headline or groupchat?

type=chat.

archived and copied.

At the Summit we discussed that they should really be presence rather than messages, FWIW.

I’ll make you a flow chart, Ge0rG.

jonasw: no thanks

:)

Kev, that, too

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"

Ge0rG, ah, put them into presence

that seems like a good solution for me

so the IM-NG server will translate directed presence with a CSN into a message on the border, and back?

need to think about implications of sending directed presence all the time, but on the first order this seems like a good thingf

Ge0rG, uh, interesting idea :)

directed presence will get cached on the server, right?

(but I was actually talking generally. clients should put them into presence)

directed presence is tricky

Yeah, so while you are constructing the IM-NG New World Order, I'm not receiving Carbons of my ACKs!

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.

So that you can't e.g. inject <transient/> in a chat stanza in order to maliciously evade archiving.

that sounds quite fragile

> maliciously evade archiving. That is very evil.

Because <no-store/> that your server listens to and your client doesn't care about is obviously bad.

but it might be worthwhile to have that

I mean provision this in IM-NG so that servers support it right away.

Ephemeral Messages are doomed now.

jonasw: Which that. My floaty idea, or the thing I say is bad?

and so that clients drop it right away

your floaty idea

Third idea is that we requisition headline.

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.

But now we're getting into even dodgier territory, potentially.

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

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.

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, …) ✏

(again)

But if we go with 'floaty idea', you have more or less that, without the server problem.

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

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.

jonasw: Right.

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?

what

And there is a huge fat `// WARNING! NO PERSISTENCE ABOVE THIS COMMENT` line in between?

Ge0rG: There's a few ways one could implement it, but something like that would work.

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

but in general you wouldn’t persist <transient/> stuff anyways

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

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.

(Not a literal forked process, obviously) ✏

Kev, I’m going to dump you a bit of commentary on XEP-0409 on the list in a minute btw

Ok. Be kind :)

will be

I’ll add a few points I already raised in this discussion so that we have them on-record somewhere

I hope nobody ever asks *me* to be kind on-list :D

jonasw: excellent!

Ge0rG, why would anyone? you’re the personified kindness.

Ge0rG, but not all points, I wasn’t paying attention consistently

jonasw: you just grilled my sarcasm detector.

Ge0rG, double-strike

sent