danielLink 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.
muppethhas joined
danielAnd I'm afraid bookmarks 2 is uncharted territory for a lot of reasons and harder to pull of then 48-on-pep
danielWith only marginal improvements over 48-on-pep
Andrew NenakhovDo bookmarks have any other use besides storing user's MUCs?
muppethhas joined
rishiraj22has left
rishiraj22has left
jonaswAndrew Nenakhov, I think some web folks put website bookmarks in there. Movim and SáT maybe
rishiraj22has left
SaltyBoneshas left
rishiraj22has left
rishiraj22has left
Chobbeshas joined
Dave Cridlandhas left
jubalhhas joined
rishiraj22has left
rishiraj22has left
SaltyBoneshas left
marmistrzhas left
blablahas left
Link Mauvejonasw, Movim and SàT put PubSub URIs AFAIK.
Link Mauvejonasw, Movim and SàT put PubSub URIs there AFAIK.
Link MauveNot web ones, but xmpp: ones.
Link Mauvedaniel, that’s also my view of it.
moparisthebesthas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
edhelasI moved my pubsub uris back to a "non standard" pep node for now
edhelasbecause 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
jonaswah yes, that’s also a nice issue with everything-in-one-item
jonaswit becomes tricky to deal with elements you don’t know, because normally in XMPP you can just drop them
jonaswit becomes tricky to deal with elements you don’t know, because normally in XMPP (as a client) you can just drop them
jonaswin this case you need to preserve them
edhelasyup
jonaswthis 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
danieljonasw: if it's just about that you can very easily do that with regular bookmarks as well
ThibGhas joined
danielConversations just ignores anything it doesn't know
jonaswit /can/ be done, but it’s not straightforward
Ge0rGI want to have bookmarklets, which can execute code in the context of the current MUC.
Andrew Nenakhovhas joined
jonaswyeah, I’m pretty sure that aioxmpp drops everything not in XEP-0048
SaltyBoneshas left
WiktorGe0rG: what would they exactly do? send some text?
jonaswso if you’re using neither <url/> nor <conference/>, it gets lost
Andrew Nenakhovhas left
SaltyBoneshas left
Andrew Nenakhovhas joined
Tobiashas joined
Link MauveWiktor, for instance your password.
Link MauveI remember both Jappix and Empathy were victims of such RCE.
pep.has joined
WiktorOh, I didn't get the joke.
Link Mauve:p
WiktorI was thinking about mIRC scripts ;)
jonaswdo I want to know, Link Mauve?
jonasw(yes, I do)
Link Mauvejonasw, https://usn.ubuntu.com/1250-1/
la|r|mahas joined
jonaswah, but that wasn’t about bookmarks
Link MauveBasically, /nick <img src=invalid onerror="alert('Hello world!')">
Link MauveAh, no.
jonaswgood ol’ HTML nicknames
Link MauveI 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!
jonaswgotta love the web
jonaswclever
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
goffihttps://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
jonaswgoffi, is it missed already though?
mimi89999has left
goffiif gitlab, gogs and gittea are following, pretty much yes.
lskdjfhas left
jonaswalthough, I can’t blame web applications for not wanting to run another daemon
jonaswwe’d need a proper solution for stabily running a client or server or component in common web frameworks
jonaswgoffi, maybe you could contribute there and turn it around?
mimi89999has joined
mimi89999has joined
lskdjfhas joined
goffijonasw: 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
Ge0rGDark 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.
BunnehGe0rG: Submit first draft of Mobile Considerations #23
https://github.com/xsf/xeps/pull/23
Ge0rGBunneh: Uhm, no.
jonasw:D
lskdjfhas left
mimi89999has joined
Ge0rGSame for Carbons. At least it's consistent.
mimi89999has joined
jonaswnow that’s
jonaswnow that’s news
danielGe0rG: are carbons ever type Chat though?
Ge0rGdaniel: dunno. Weren't you sending chat carbons?
mimi89999has joined
danielGe0rG: why would I send carbons of any type?
mimi89999has joined
Ge0rGif not(orig_type == "chat" or (orig_type == "normal" and stanza:get_child("body")) ) then you_shall_not_carbon_mam(); end
Ge0rGOh, wait.
Ge0rGdaniel: I mean: Weren't you sending chat *acks*?
Ge0rGSame holds true for markers and any other bodyless messages.
HolgerType chat without body should be carboned but not MAM-stored right?
danielJa deliberately make them type chat yes
Ge0rGHolger: who said that=
HolgerThe XEPs?
mimi89999has joined
Ge0rGCSNs are defined as `chat`.
Ge0rGHolger: now you make me sad.
lnjhas left
rtq3has left
flowGe0rG, have a cookie
mimi89999has joined
Steve Killehas left
Ge0rGHolger: sad because of https://github.com/xsf/xeps/pull/434
Steve Killehas left
jonaswGe0rG, do some work on https://xmpp.org/extensions/xep-0409.html
mimi89999has joined
Ge0rGjonasw: sure, when MIX is finished.
mimi89999has joined
jonaswsince when do you care about MIX?
HolgerGe0rG: Ah, routing 2.0 will fix everything.
j.rhas joined
Ge0rGHolger: 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"
Ge0rG0313 only asks for <body> messages to be archived
Ge0rGI'm not sure why anybody would want to archive any <chat> messages.
jonaswI am reading that xep for the first time now, and I like how it handles the NG vs. non-NG interop
Ge0rGjonasw: it's really intriguing, I'll need to think it through thoroughly
mimi89999has joined
jonaswKev has done some good work there, I expected much less given the time frame in which it was done.
mimi89999has joined
HolgerGe0rG:
> 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.
jonaswc’mon :)
jonaswdo you think we can get a <stanza-id/> in the mandatory reflection to all resources?
jonasw(on the sender side)
jonaswthat would be truly amazing
KevYes, but is that MAM or routing?
Ge0rGHolger: No, I mean why people *would* want to archive bodyless chat messages.
HolgerRead markers for example?
Ge0rGHolger: also CSNs
jonaswKev, good question; I would like to have it mandatory for every service implementing MAM though. this avoids us having to namespace-bump MAM.
jonaswi.e. make it mandatory in IM-NG for a service which also offers any XEP-0313 namespace to put <stanza-id/> in the reflections
Ge0rGHolger: not sure if you heard of it, but MAM storage of CSN made my MAM DB explode and yax.im melt down, just recently
Ge0rGKev: mandatory stanza IDs for "important" messages are good enough for me, so MAM > routing
HolgerGe0rG: I haven't, but not storing read markers sucks UX-wise and I'm sure there are more examples.
Ge0rGHolger: so we have two examples now of things that are of the same type but needs to be handled differently. What now?
KevHolger: I have thoughts on that too, but I've not written them up yet.
Ge0rGACKs are of type=undefined, so even more meh.
KevBut I think that you want your archive to be collating such things rather than storing verbatim.
lumihas left
Ge0rGKev: that sounds like a database synchronization problem. Send deltas, update internal state.
HolgerYes such optimizations would be nice. I'm just saying that throwing this stuff away is not a good solution.
jonaswoh, 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).
jonaswIIRC the archived version contains the <stanza-id/>
Ge0rGjonasw: yes, it should
jonaswit should or it SHOULD?
Ge0rGjonasw: don't ask me these questions please. It's friday and I'm having tremendous "fun" at work already.
Ge0rGI only started this because it bothered me that I didn't see ACKs of messages on my other client.
jonaswhere, have a cookie
jonasw🍪
Ge0rGAnd there is no easy solution.
jonaswand you should please appreciate that I pasted you a cookie because you know how much that makes my poezio behave weird!
Ge0rGjonasw: sorry, but cookies trigger me since the GDPR faux-compliance of ignorant americans made cookie dialogs look like good UX
Ge0rGreally sorry.
jonasw🍉
jonaswsome cool water melon maybe?
Ge0rGjonasw: since running emoji_ascii the situation has considerably improved for me. Except for the jabber❌namespace.
jonaswGe0rG, you’re not alone, github does it too: https://github.com/xsf/xeps/pull/664
Ge0rGit's a rainy 18°C here. But I had to change my munin cpu temp warning threshold from 70° to 80°
jonaswright, I forgot that only Dresden seems to be shielded from the bad^Wgood and plant-saving weather
Ge0rGLOL
jonasw☕
jonaswthen that maybe^?
Ge0rGthat made my day.
rtq3has joined
jonaswGe0rG, finally found something good for you \o/
Ge0rGnext time somebody complains, I'll point at that issue
jonaswI need to re-write the commit message, because I’m going to be complaining a lot ;-)
Ge0rGI'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.
Ge0rGThe final words of the app owner were "I hope we are aligned now"
j.rhas joined
Ge0rGnot sure if it was a command or a threat.
kasper.dementhas joined
Ge0rGBut back to the topic. Even with IM-NG, we'll still have to define rules for handling of legacy messages
Ge0rGSo back to https://github.com/xsf/xeps/pull/434
Ge0rGWould it make sense to make 0184 and others use type=chat?
Ge0rGor type=<type of what you respond to>?
Ge0rGMUC ACKs should go to the MUC, so that we get O(n²), right?
jonaswGe0rG, 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
jonaswplus:
> 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
jonaswso 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
Ge0rGWhat about CSNs?
jonasware they of type headline or groupchat?
Ge0rGtype=chat.
jonaswarchived and copied.
KevAt the Summit we discussed that they should really be presence rather than messages, FWIW.
jonaswI’ll make you a flow chart, Ge0rG.
Ge0rGjonasw: no thanks
jonasw:)
jonaswKev, that, too
Ge0rGjonasw: 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
jonaswGe0rG, ah, put them into presence
jonaswthat seems like a good solution for me
Ge0rGso the IM-NG server will translate directed presence with a CSN into a message on the border, and back?
jonaswneed to think about implications of sending directed presence all the time, but on the first order this seems like a good thingf
lnjhas joined
jonaswGe0rG, uh, interesting idea :)
Ge0rGdirected presence will get cached on the server, right?
jonasw(but I was actually talking generally. clients should put them into presence)
jonaswdirected presence is tricky
Ge0rGYeah, so while you are constructing the IM-NG New World Order, I'm not receiving Carbons of my ACKs!
KevThe 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
KevSo that you can't e.g. inject <transient/> in a chat stanza in order to maliciously evade archiving.
jonaswthat sounds quite fragile
Ge0rG> maliciously evade archiving.
That is very evil.
KevBecause <no-store/> that your server listens to and your client doesn't care about is obviously bad.
jonaswbut it might be worthwhile to have that
mikaelahas left
jonaswI mean provision this in IM-NG so that servers support it right away.
Ge0rGEphemeral Messages are doomed now.
Kevjonasw: Which that. My floaty idea, or the thing I say is bad?
jonaswand so that clients drop it right away
jonaswyour floaty idea
KevThird idea is that we requisition headline.
jonaswlemme 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.
KevBut now we're getting into even dodgier territory, potentially.
Ge0rGWhat 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
jonaswI’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
KevGe0rG: 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.
jonaswI’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)
KevBut if we go with 'floaty idea', you have more or less that, without the server problem.
jonaswthen 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
KevThe 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.
Kevjonasw: Right.
Ge0rGKev: 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?
jonaswwhat
goffihas joined
Ge0rGAnd there is a huge fat `// WARNING! NO PERSISTENCE ABOVE THIS COMMENT` line in between?
KevGe0rG: There's a few ways one could implement it, but something like that would work.
jonaswI’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
jonaswbut in general you wouldn’t persist <transient/> stuff anyways
jonaswthat’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
KevI'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.
Kev(Lot a literal forked process, obviously)
Kev(Not a literal forked process, obviously)
jonaswKev, I’m going to dump you a bit of commentary on XEP-0409 on the list in a minute btw
KevOk. Be kind :)
jonaswwill be
jonaswI’ll add a few points I already raised in this discussion so that we have them on-record somewhere
Ge0rGI hope nobody ever asks *me* to be kind on-list :D
Ge0rGjonasw: excellent!
jonaswGe0rG, why would anyone? you’re the personified kindness.
jonaswGe0rG, but not all points, I wasn’t paying attention consistently
Ge0rGjonasw: you just grilled my sarcasm detector.