XSF Discussion - 2018-08-21

could MAM be enabled for this room?

+1

Ge0rG: no, and I'm not either

Revisiting my question from yesterday - can anyone find any evidence that routing behaviour for presence type='error' is defined anywhere in 6120/6121?

3921 said it must be routed to the user, but not using what rules, and 6121 seems to be completely silent, unless I'm just missing it.

Kev, it does appear to be missing indeed

no erratum either

So, full-JID is routed, bare JID is dropped, logically, right?

Hm, where would error-replies to probes go?

bare

Bare, which wouldn't be delivered to the user. Which is right, I think.

OTOH the error in response to the broadcast presence /would/ be delivered to the user, because that's to=full.

(which is also right)

Yes.

“15:43:43 Zash> Next Prosody won't allow GC1.0 joins, have we seen any ill effects of it yet?”, a tiny usability issue on my side, I used to just change my status in poezio after a network or power outage of my server, and it would automatically reconnect me back to all rooms, but without GC1.0 it instead gets an error back (which it could totally handle and issue a join, so that’s only a client needing to be fixed).

Link Mauve: https://xkcd.com/1172/ ?

I'm assuming that's a fairly common workflow though, I do the same.

Pretty much.

stupid question probably, but MAM RSM wise is it proper to return item-not-found if paging before/after a certain index (which actually exists) yields no results?

The spec explicitly talks about the entry not existing otherwise not the page before/after it being empty.

Yes, my understanding is that you'd return an empty page in that case.

Holger, considering some clients seem to trample on empty pages without an error though...

Huh.

(e.g. Movim)

I would've expected clients will usually honour the 'complete' attribute and not even issue such a request in the first place.

Holger, movim doesn't apparently

I.e. I would've thought this is a corner case where messages were deleted from the DB while the client is querying it.

it will just send an query with rsm <after /> with the last entry.

And how does it then "trample"?

which results in an empty page and just starts endlessly looping on that

^

Ugh.

edhelas: ^

Holger, he knows

:P

Ah.

I already reported the issue of it not respecting the complete attribute.

Sounds like two issues to me.

Holger, but I wonder if I should do anything to prevent this with any other clunky/old implementation

sending the error instead of the empty page works for Movim at least

Holger, well as long as I didn't miss anything behaving this way doesn't seem to break any MUST/SHOULD that I can see.

Maranda: Hehe, yes strictly speaking I'd agree, but I think you can deduce from the text that it goes against the intention.

I'm not sure there's use-cases where the clients would be interested in the difference between a real item-not-found and an empty page.

Probably not.

Holger, question does ejabberd include in results the entry specified in either after/before elements?

I hope not!

I'll double-check if you have any indication that it does :-)

That would clearly go against the spec.

Holger, I'm trying to understand why apparently Movim doesn't trample with ejabberd as well.

Me too, especially as I think ejabberd is violating that item-not-found MUST in that it *never* returns that error.

> does ejabberd include in results the entry specified in either after/before elements? Ok I checked, answer is "no".

But not I'm wondering whether I should add that item-not-found thing. Opposite problem of yours :-P

Would add code ugliness.

Holger, the only thing that looked slightly off in that empty page was the <set /> element but otherwise was correct so I'm a bit in a 🤷‍♂️ mode atm 🤣

hehe

Maranda: In the empty page returned by Metronome?

yes

and it also sported complete="true"

but anyways since just throwing an error makes Movim happy... for now :P

We already query an additional message from the DB (and then throw it away) in order to set complete=true/false. So we'd need another one to decide on whether to return that error.

Grr, why did the mailman URLs change?

did you delete a message?

On Fri, 2011-08-19 at 22:04 +0200, Andreas Monitzer wrote: > Why doesn't it use plain PEP, instead defining its own protocol? It did, see this thread: http://mail.jabber.org/pipermail/standards/2011-April/024355.html

Date: Sat, 20 Aug 2011 20:49:34 +0200 Subject: Re: [Standards] XEP-0292 vCard4 Reinventing the Wheel?

That link goes to something about xep178, not vcard4

This looks more relevant: https://mail.jabber.org/pipermail/standards/2011-April/024333.html

Hm, whatever happened to pubsub-since

312

Is there still consensus for having https://xmpp.org/extensions/xep-0292.html#self-iq ?

I personally don't see the point at this time, doing a PubSub get-item(s) query seems just as likely to work/not work as that, and doesn't require more code over what's already there for PEP/222/223

The argument that it's needed to work in MUC doesn't hold because it does not work in MUC without a special exception to re-route such IQ stanzas to the bare JID, like we happen to have for vcard-temp.

Extending that exception to arbitrary PubSub is just as easy as extending it to that single vcard4 iq query.

Hmmm

I wonder if only Prosody wouldn't go "WTF?!" at me.

I mean if people keept code for GTalk in place 🤣

Zash, I agree with your view

me: "Slack has Markdown, Riot has Markdown... I want Markdown my XMPP client, should be as simple as putting some mark to the message "markdown on". there has be a XEP for that already!" XMPP: uhm... XEP-0393? XEP-0394? or... https://xmpp.org/extensions/inbox/content-types.html? me: damn you xmpp

every single one of those is slightly not what I would like :/

What's missing? 0393 is what Slack and WhatsApp do I thought

First define markdown, which is hard enough

(and deliberately not 'markdown', which most messengers don't actually support)

On the one hand, yes it is, but on the other hand people mostly make do.

(hard to define markdown, that is)

dos: markdown is not a wire format, there has been a long flam^W debate about this on standard@, and the subject is not closed.

He's not looking for a wire format, he's looking to enter something in a text box and have it appear formatted. How that's transmitted on the wire doesn't matter, I suspect.

oh wait, I might have raged too quickly. 0393 might be fine, have to reread

SamWhited: he's talking about a "markdown on" message mark, so I take it as a wire format. Else it doesn't matter which flavour of markdown you are using as long as you can convert it to wire format (like the RIP XHTML-IM)

dos: let me know, feedback would be appreciated.

the examples in that xep are confusing. had to reread Example 1 a few times to actually get it

That's good feedback, thanks :) Driving now, ping anything you find to to sam@samwhited.com or standards at and I'll try to fix it.

dos, https://xmpp.org/extensions/inbox/bmh.html

flow: ah, much butter than the content type one. however, 0393 seems to be fine after all. it doesn't have any way to singalize its support though, so maybe 0393+bmh would be a good idea? :D

(well, probably not)

goffi: I don't think he's talking about wire format, but your comment still applies. In any case that only needs to be a client thing and not bloat^Wdirectly in body

actually it might not be so complicated to implement either 🤔

In fractal (matrix client) there's this thing where you can check "markdown" iirc, and then input stuff in markdown, that'll be translated into some kind of rich text, (and advertized as such). I assume they do that so you can _also_ use plain text, and not have it displayed funky, which makes sense

(à la xhtml-im, then)

But let's not revive the flamewar

riot has such switch as well. otoh, slack doesn't have iirc

anyway, for me looks like 0393 is fine after all, no need to flame ;D

dos, isn't the thing about markdown that you don't need to signal support for it?

but yeah, xep393 probably lacks an extension element indicating that its <body/> is xep393 formated

flow: yeah, I thought about it after sending. makes sense

it doesn’t really make sense

not everyone is going to emit markdown plaintext

or markdown-compatible plaintext

there's no reason to not format *stuff like that* just because the sender didn't

jonasw, are you talking about signaling support for receiving markdown, or signaling that the data is markdown formated?

dos, think about automated things

flow, the latter

jonasw, well, but does asked for the former

oh, I missed that then?

and yes, I aggree with you, that is why I wrote that xep393 is probably missing "an extension element indicating that its <body/> is xep393 formated"

Hello, I wrote a XEP about MUC avatars based on 0153, Ejabberd’s MUC avatar tutorial and disco#info, but now I’m having second-thoughts about it and might instead favour PubSub on MUC JID, so we can finally deprecate 0153.

The main benefit of the latter is that 0084 describes much better what the image data actually are.

But the former is already implemented in more places.

The upgrade path would be trivial though.

Thumb down, then already will not implement it

It’s being implemented as we talk.

I'm eager to see what kind of ugly hack will come out of it ☺️

Current version is at: https://linkmauve.fr/extensions/xep-muc-avatar.html

Link Mauve: I meant for the PEP version

Link Mauve: that one is perfectly fine

I’d really really like to deprecate 0153 someday though.

Maranda, shush you :)

pep.: 😜

I vetoed its deprecation back then because of MUC avatars, but I’m now convinced we can implement them using MEP.

Or something like that.

Link Mauve: probably by the time you deprecate 153, something to sub 84 will come out as well

If it didn't already

What do you think is missing from it?

It would also significantly lower the cost of upgrading to MIX. ✏

I'm not saying that something is missing from it, I'm strongly implying that publish subscribe isn't the holy grail that solves anything and is appropriate for everything

jonasw: https://xmpp.org/registrar/ is there but might be updated properly?

s/might/might not/