jdev - 2023-06-11

https://xmpp.org/extensions/xep-0447.html#attach-source

sounds like bittorrent

Yeah that looks like a cool feature :)

Maybe it could be made even cooler by being able to share chunks

just use bittorrent directly, then include a web seed pointing at the http uploaded file!

:(

http-upload the .torrent

loop!

> The Sender MUST NOT send a retraction request for a message with non-messaging payloads

i read this now in 2 XEPs

what is a non-messaging payload

seems like open for interpretation

that interpretation should then be written down in https://xmpp.org/extensions/xep-0226.html

is a XEP-0447 Payload, a messaging payload?

Does it end up as something in the message view in a client?

i rather not interpret XEPs depending on GUI implementations

i think this is a recipe for failure

Isn't that what it comes down to?

Is this some kind of message for meant for a user?

i hope not, i didnt write these XEPs, no idea what they meant

Or, like, some system stuff

the example for a non-messaging payload is a roster item exchange

though its very thinkable, that a client shows a shared contact in the message view

and gives the user a option to add this to his roster or not ✏

if we interpret "messaging payload" as a message with a body intended to be read by the user (so not somekind of fallback body)

this would exclude 0447, meaning you cant retract that, which seems also wrong, because if i share a photo, why should i not be able to retract that

lovetox, I did not mean you should read what xep-0226 says now, I mean that if we come up with a proper definition of "messaging payload" it should be written down. Either in '226 or in a new XEP that replaces it. ✏

and the correction XEP

> Correction MUST only be used to change the logical content details of a stanza (e.g. the message body) and not to change the nature of the stanza or its metadata

is a oob url and oob description, metadata? ✏

Yeah. "not change the nature of the stanza" makes sense "or it's metadata" is super meh imo

Is thread data or no? What about subject? What about oob or sims?

I allowed correcting thread for now

thread seems more metadata than data

and thus began the great XMPP meta vs data war!

hey i am writing my doap file and saw that in the xep the example has also releases. But its used only by xmpp.rs currently it seems. Is the releases planned to be used to give download links from the xmpp website?

I would prefer linking to the projects own download page

Tho with the data there, nothing stops you from building such a thing yourself :)

hmm. yeah makes sense. i will add it then. my main thinking was that the file may become to large

but then again i dont support that many xeps ^^'

DOAP isn't specific to XMPP after all

talking about DOAP... https://xmpp.org/extensions/xep-0453.html has a dead link in section 5, the README was converted from .rst to .md it seems?

ah yeah. also the link in the first section is dead

> The information listed SHOULD include, but isn’t limited to, the project name, homepage, description, logo, screenshots if relevant, specifications supported (RFCs and XEPs). A full list of supported properties is described in RDF format at http://usefulinc.com/ns/doap#.

or its supposed to be and i am missing something

but from the wording it should work it seems

Turns out namespaces that resolve to their own schemas might not be the most reliable idea.

i wonder why the replies XEP says one must add the jid of the one you reply to

seems like added complexity, now i need to check if the jid matches the one who sent the replied to message

ah, is this maybe for the case where you cant find the replied to message locally

so then you can atleast attach a name to the reply when you use the fallback body?

with all these new XEPs referencing messages, i think something like loading MAM messages backwards becomes very hard

when you receive corrections / retractions / replies to messages you didnt see yet

Usually I load into the db and then UI sees it all forwards

it actually doesnt matter how you request MAM, with these XEPs we need to be prepared to receive such messages, and the reference does not exist locally

how do you deal with that?

Insert to the db with the reference ID, then do the join starting from messages so that stuff referencing messages that are not there doesn't get loaded for ui

how do you insert a retraction? a retraction means you should delete a existing message or annote it with a flag that it is retracted

Yup, that's a good point, so probably should store it at an annotation same as a reaction or reply

or simply dont allow requesting history backwards in MUCs, like Gajim does currently

then you dont need to think about these problems

i mean of course i can think about ways to make this work, but all mean multiple db queries per received message, instead of simply one insert

i swear writing a XMPP client is a major software architecture project

> simply one insert this simplicity currently lives at the server. there's that whole thing about fastening that I imagine boils down to moving it to the client, so the server gets the complex end

complexity remains constant of course

Should still be one insert. then a join at load time

Sure, you can move the complexity from receiving to display :)

I wouldn't call a join complexity, but sure

singpolyma, if it would be that easy, like recieve all data -> then display

but the reality is, you receive data and need to display immediately

lovetox, if the join is easy, then the complex part was probably in designing the database schema? :)

yes, i currently write a new database schema for gajim

thats why i think about all that

and i wonder which xmpp developer really thinks about all that at the start, probably none

> but the reality is, you receive data and need to display immediately I usually don't do that currently. Always goes into db, UI always loads from db ↺

hm interesting idea

yeah i dont do this

i insert into db, then pass data on to events to display it

so no db load occurs anymore

of course i could insert it, then load, this would have the added benefit that i dont have 2 data structures, one object loaded from db, and a second that represents some Message "Event"

and then all the joins work nicely

Yeah, that's why we do it that way

re message replies, if the message being replied to isn't already in the db, you could use the fallback message (used for clients not yet supporting replies) to display the reply properly. And if the user clicks on the message being replied to, that should trigger fetching mam history from the server until the message is found

I guess in a big MUC you might not want to always load it all

yeah reply does probably not break, also message corrections have a nice fallback

retractions you need to save in a different table, and check at display time

Correction and retraction are semantically the same. Just a retraction you're always replacing with "nothing"

is it? maybe if you dont store old corrected texts

if i receive a correction without having the original, i can simply show the correction, its a normal message

i guess its similiar, but in gajim we show the correct message history

Sure, you can show it, but it would be out of order time wise and also probably don't want to show the dupe after fetching the original later

So need to keep that association somehow

currently when i store a message

if i receive a correction, i dont store the message, i simply replace on the original message row, the text

at the end i have only one database row, even if there were 20 corrections

( lets not think about storing correction history for now )

now how would you do this when you receive the whole history the other way around

you receive the last correction, do you store it into the db?

but it is not the original message, and the next correction will not even reference this correction anymore

or do you store all corrections in a different table, and dont dsiplay until you receive the original

sounds more sane

Yeah, that's the easiest choice I expect

hmmm

When getting correction with no original could insert a "fake original" to be replaced later when getting real original, but that's definitely not a clean one insert to do it that way

hm im not really getting it, handling corrections backwards seems like a non trvial thing

hm but this should work, if i put the corrections in a different table, and wait for the original ..

i think i will try that, lets see