XSF Discussion - 2019-07-24

jonas’ - are you available?

depends on your definition of "available", Guus

jonas’: I've got quick questions about muclumbus, but I'm feeding the offspring now

Did my one-on-one message arrive? If so, I'll follow up on that after lunch

Guus, no it did not, but that’s probably because you sent it to an account on which I’m currently not available

an account which I generally prefer for 1:1 messages

is there a reason we cannot discuss this in a more public venue, like here or operators@? (I still can’t join jdev@)

Didn't want to bother others. Will do here

Simple question really

Is-open, does that include public rooms that at the time of query cannot be joined because of a server policy (eg: amount of occupants is at a configured max)?

Guus, no, because muclumbus does not attempt to join rooms

it only works with the info available from disco#info

so yes, it does include those rooms

oh, yeah

I got that inverted

s/\bno\b/yes/

Right. 🙂

Tx

Rx

jonas’ follow-up question. The description of the 'q' form field is: "Optional string. Operates like the search box on the website."

... how does the website behave?

I've now got: split value on whitespace, and split the to-be evaluated value the same way - then check if the evaluated value split contains all of the q split.

Guus, it’s not properly documented, as you’ve found

it is I think a shlex.split in python, which means that you can search for stuff including spaces by writing `"foo bar"` into the search box

website doesn't appear to do partial text search, so the 'split on whitespace' thing made most sense.

but might be incomplete, or plain wrong.

the resulting keywords are fed into SQL surrounded by `%`

https://search.jabbercat.org/search?q=gefl%C3%BC this shows a partial match ✏

oh, shoot, I missed the 3-character minimum thingy

that’s a deployment-specific option

yeah, but it's why I though it was not doing partial matches

I searched for 'te', didn't get 'test' results.

(and didn't read the bright red warning message)

heh

pff warning messages, nobody reads those, c.f. compiler warnings

all search terms are AND'ed, nor OR'ed, right?

Guus, yes

q, rolling version 2 ...

This seems to work fine. If I put this on a publicly reachable server, is there a way for you to test this, jonas’ ?

(or anyone else, for that matter?)

Guus, yes, I have a test client software

it’s even included in the public repo I think https://github.com/horazont/muchopper/blob/master/examples/request.py

that seems like something I can run myself

oh, but it doesnt create/populate mucs, I think?

Guus, no, it doesn’t

it only queries the search thing

I sent a link with poezio, and then I realized it was actually an image and some clients would display it a bit more user-friendly if I included the right tags. I sent an LMC with an OOB tag, but Conversations and dino don't display the picture anyway. Is that a bug? feature?

The XEP says: To deal with multiple payloads, the sender MUST re-send the entire stanza, only altering id and the payloads being corrected and adding the 'replace' payload. It is expected that the receiver SHOULD then treat the new stanza as complete replacement for all the payloads received in the original stanza.

read this the first time

was that not changed a few weeks ago?

LMC is about body for me

and not all payloads

pep.: OOB is abused by Conversations and other clients for inline media, with the restriction that url must be equal to message body

not sure if you can LMC a picture into a message, though, as changing the type of message is forbidden by LMC

its not abused at all

or your definition of abused is weird

oob adds a url to a message, and thats what we do

using the xep like it was intended

how i display messages with a oob tag is up to the client

and not a concern of the xep

lovetox: the abuse is because it's essentially used for inline images / media, and because of the undocumented body=url requirement

how is that an abuse, to display a url added via oob inline?!

the XEP makes zero statements as to how a client has to display a oob url

lovetox: yes, so I could use the same syntax to append my avatar to all my messages.

yeah and?

it would be an equally legal use of 0066

people not going to chat with you long when you do that

not sure where the abuse is though

protocol wise, you abusing people with messages, yes thats clear

lovetox: only people using a client that's not adhering to XEPs will notice.

All my messages are verbal abuse, nevermind the OOB

OOB is not the right XEP for inline media, because it doesn't define how to display the URI, and because there is SIMS. Furthermore, clients only showing OOB media if url==body are enforcing an invisible specification.

It's all wrong.

It's only slightly less wrong than just HEADing every URL that's sent to you in a message body.

you follow the notion that you think you got to decide if my client displays something inline or not

there is no invisible specification

lovetox: no, only that I'm the one who has to decide _how_ I intended my message to be shown

you just found out implementation details of algorithm that decideds what to display inline

and now you think its a invisible specification for you

like its your job that a picture displays inline in MY client

lovetox: XEPs are about interoperability between systems. If I see an image that I send inline, I expect your client to also display it inline, maybe with the exception that you explicitly disabled inline media.

lovetox: as a client author, if I want to tell other clients to display a certain file inline, I now need to know that OOB has to be used (despite OOB not being made for inline media), and that I need to set the body to the URL, leave empty the description and send whatever text I want to accompany that image as a separate message. None of that is written down anywhere.

There can be an endless settings go into the decision of a client if something is displayed inline

you should not expect anything

you should provide all data necessary to display something inline

but thats about it

lovetox: but you can keep pretending that there is no "inline media" and that all your client does is to use some creative rules to magically embed linked image files.

> you should provide all data necessary to display something inline Yes, this is exactly what the fuss is about

The problem is that you want to dictate UI and behaviour on another client, on such a complex topic as displaying weblinks inline

lovetox: see, we have a fundamental disagreement on the basic assumption.

lovetox: you speak about displaying weblinks, I speak about inline media.

same story sorry

no, those are completely different.

lovetox: given your premise, I agree with all you said.

not at all, its all some file on a webserver

OOB is okay'ish for letting another client know that you reference a website or page of some sorts.

but it's not how it's used by at least Conversations.

So if i reference a website on facebook, the page shows inline

thats my messenger, so i expect your client now to display it inline

following your logic

lovetox: please just stop.

lovetox: as I said, we are speaking about two fundamentally different things.

lovetox: please don't try to interpret what I said in the context of linking websites.

I know you speak about pictures, but i already told you i dont accept your argument that this is not the same

both can be displayed inline, both are displayed inline in real world by clients

lovetox: yes, but the message is different.

inline media: "here is a picture that I attach to my message" website reference: "here is a random weblink with which your client may do whatever it wants"

so your argument is SIMS does not support weblinks

so there is no way to tell other clients to show it inline

hence you cant expect it to do it

lovetox: what?

I have never said anything about website references. I've been exclusively talking about inline media

even in my first message, I explicitly wrote that.

yeah so if SIMS would support sharing a website reference, and SIMS = Inline Media, then you would expect to see the website displayed inline?

lovetox: sorry, I can't follow you.

how do you tell a client to show a media inline?

it looks a bit like you are trying to ask me trick questions to make me issue absurd statements.

just by using SIMS right?

its not a trick question, i think i understand what you are trying to say

SIMS is not for website references

exactly!

oob does not say in the xep anything about inline

yes!

SIMS is designed for inline media only

it's a bit overengineered, but nevertheless.

so for website references, you use something else than SIMS.

you might use OOB, or just rely on the receiving client to parse the URL out of your body

just for the record, i dont think anybody is opposed to implement SIMS over oob

1. SIMS was not really a thing when this was implemented

2. OOB is alot less to implement for clients

so thats why this was chosen

Yes, but it's still abuse of OOB.

Also with OOB for inline media, you need to HEAD the URL to fetch the file type and size, before you can make any reasonable action with it or display an icon to the user

i still dont see where the abuse is, the oob xep even shares a picture in its example

so yes this XEP was clearly intended to share also links to media on the web

but not for inline media in the client. ;)

how you come to that conclusion is not clear to me, there is no way to indicate a inline display hint in oob, and your conclusion is : Its an abuse to show it inline

no, it's an abuse for a sender to use OOB for inline media

and for the recipient to imply that body==url --> inline media

if your goal is to get more clients to use SIMS, i think you will be more successuful if you hint at the benefits that SIMS has over oob, like communicating the inline wish. Instead of shouting Abuse

lovetox: do you know which clients implement SIMS?

Communicating hashes for integrity checks, ability to use different transports, thumbnails, what else are benefits of SIMS?

"Ge0rG> lovetox: no, only that I'm the one who has to decide _how_ I intended my message to be shown" something something 393 /me hides

> lovetox: do you know which clients implement SIMS? Movim IIRC?

Ge0rG, Movim, Psi

maybe converse, but not sure

Zash: no need to do a HTTP HEAD

> Communicating hashes for integrity checks, ability to use different transports, thumbnails, what else are benefits of SIMS? I think edhelas was interested in metadata such as the size to avoid HEAD requests.

Right.

Yeah, size and file type

And OMEMO people don't want to reveal that data. So I guess chances for implementation might be better once there's full stanza encryption.

Speaking of OMEMO, https://xmpp.org/extensions/inbox/omemo-media-sharing.html combines the worst of both worlds.

> The sending entity MAY also generate a thumbnail as a JPEG data uri and include that in the same message. The aesgcm:// and the data:image/jpep, are seperated by a new line character.

Nuff' said.