Guusall search terms are AND'ed, nor OR'ed, right?
Guusq, rolling version 2 ...
Dele (Mobile)has joined
GuusThis seems to work fine. If I put this on a publicly reachable server, is there a way for you to test this, jonas’ ?
Guus(or anyone else, for that matter?)
jonas’Guus, yes, I have a test client software
jonas’it’s even included in the public repo I think https://github.com/horazont/muchopper/blob/master/examples/request.py
Guusthat seems like something I can run myself
Ge0rGis running a mirror bot that forks the pubsub data. Sometimes.
Guusoh, but it doesnt create/populate mucs, I think?
jonas’Guus, no, it doesn’t
jonas’it only queries the search thing
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
pep.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?
pep.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.
Dele (Mobile)has left
lovetoxread this the first time
lovetoxwas that not changed a few weeks ago?
lovetoxLMC is about body for me
lovetoxand not all payloads
Ge0rGpep.: OOB is abused by Conversations and other clients for inline media, with the restriction that url must be equal to message body
Ge0rGnot sure if you can LMC a picture into a message, though, as changing the type of message is forbidden by LMC
lovetoxits not abused at all
lovetoxor your definition of abused is weird
lovetoxoob adds a url to a message, and thats what we do
lovetoxusing the xep like it was intended
lovetoxhow i display messages with a oob tag is up to the client
lovetoxand not a concern of the xep
Ge0rGlovetox: the abuse is because it's essentially used for inline images / media, and because of the undocumented body=url requirement
lovetoxhow is that an abuse, to display a url added via oob inline?!
lovetoxthe XEP makes zero statements as to how a client has to display a oob url
Ge0rGlovetox: yes, so I could use the same syntax to append my avatar to all my messages.
Ge0rGit would be an equally legal use of 0066
lovetoxpeople not going to chat with you long when you do that
lovetoxnot sure where the abuse is though
lovetoxprotocol wise, you abusing people with messages, yes thats clear
Ge0rGlovetox: only people using a client that's not adhering to XEPs will notice.
Ge0rGAll my messages are verbal abuse, nevermind the OOB
Ge0rGOOB 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.
Ge0rGIt's all wrong.
Ge0rGIt's only slightly less wrong than just HEADing every URL that's sent to you in a message body.
lovetoxyou follow the notion that you think you got to decide if my client displays something inline or not
lovetoxthere is no invisible specification
Ge0rGlovetox: no, only that I'm the one who has to decide _how_ I intended my message to be shown
lovetoxyou just found out implementation details of algorithm that decideds what to display inline
lovetoxand now you think its a invisible specification for you
lovetoxlike its your job that a picture displays inline in MY client
Ge0rGlovetox: 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.
Ge0rGlovetox: 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.
lovetoxThere can be an endless settings go into the decision of a client if something is displayed inline
lovetoxyou should not expect anything
lovetoxyou should provide all data necessary to display something inline
lovetoxbut thats about it
Ge0rGlovetox: 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.
Ge0rG> you should provide all data necessary to display something inline
Yes, this is exactly what the fuss is about
lovetoxThe problem is that you want to dictate UI and behaviour on another client, on such a complex topic as displaying weblinks inline
Ge0rGlovetox: see, we have a fundamental disagreement on the basic assumption.
Ge0rGlovetox: you speak about displaying weblinks, I speak about inline media.
lovetoxsame story sorry
Ge0rGno, those are completely different.
Ge0rGlovetox: given your premise, I agree with all you said.
lovetoxnot at all, its all some file on a webserver
Ge0rGOOB is okay'ish for letting another client know that you reference a website or page of some sorts.
Ge0rGbut it's not how it's used by at least Conversations.
lovetoxSo if i reference a website on facebook, the page shows inline
lovetoxthats my messenger, so i expect your client now to display it inline
lovetoxfollowing your logic
Ge0rGlovetox: please just stop.
Ge0rGlovetox: as I said, we are speaking about two fundamentally different things.
Ge0rGlovetox: please don't try to interpret what I said in the context of linking websites.
lovetoxI know you speak about pictures, but i already told you i dont accept your argument that this is not the same
lovetoxboth can be displayed inline, both are displayed inline in real world by clients
Ge0rGlovetox: yes, but the message is different.
Ge0rGinline 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"
lovetoxso your argument is SIMS does not support weblinks
lovetoxso there is no way to tell other clients to show it inline
lovetoxhence you cant expect it to do it
Ge0rGI have never said anything about website references. I've been exclusively talking about inline media
Ge0rGeven in my first message, I explicitly wrote that.
lovetoxyeah so if SIMS would support sharing a website reference, and SIMS = Inline Media, then you would expect to see the website displayed inline?
Ge0rGlovetox: sorry, I can't follow you.
lovetoxhow do you tell a client to show a media inline?
Ge0rGit looks a bit like you are trying to ask me trick questions to make me issue absurd statements.
lovetoxjust by using SIMS right?
lovetoxits not a trick question, i think i understand what you are trying to say
lovetoxSIMS is not for website references
lovetoxoob does not say in the xep anything about inline
Ge0rGSIMS is designed for inline media only
Ge0rGit's a bit overengineered, but nevertheless.
Ge0rGso for website references, you use something else than SIMS.
Ge0rGyou might use OOB, or just rely on the receiving client to parse the URL out of your body
lovetoxjust for the record, i dont think anybody is opposed to implement SIMS over oob
lovetox1. SIMS was not really a thing when this was implemented
lovetox2. OOB is alot less to implement for clients
lovetoxso thats why this was chosen
Ge0rGYes, but it's still abuse of OOB.
Ge0rGAlso 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
lovetoxi still dont see where the abuse is, the oob xep even shares a picture in its example
lovetoxso yes this XEP was clearly intended to share also links to media on the web
Ge0rGbut not for inline media in the client. ;)
lovetoxhow 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
Ge0rGno, it's an abuse for a sender to use OOB for inline media
Ge0rGand for the recipient to imply that body==url --> inline media
lovetoxif 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
Ge0rGlovetox: do you know which clients implement SIMS?
ZashCommunicating hashes for integrity checks, ability to use different transports, thumbnails, what else are benefits of SIMS?
pep."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
Holger> lovetox: do you know which clients implement SIMS?
lovetoxGe0rG, Movim, Psi
lovetoxmaybe converse, but not sure
Ge0rGZash: no need to do a HTTP HEAD
Holger> 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.
ZashYeah, size and file type
HolgerAnd OMEMO people don't want to reveal that data. So I guess chances for implementation might be better once there's full stanza encryption.
Ge0rGSpeaking of OMEMO, https://xmpp.org/extensions/inbox/omemo-media-sharing.html combines the worst of both worlds.
Ge0rG> 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.