jdev - 2026-01-13

What's the deal with Message Fastening? It seems useful but the XEPs that used to reference it don't anymore

So it's been unfastened?

Two? Summits ago we decided it wasn't worth it and every xep can just specify the parent id anyway

I'm asking specifically because of something like XEP-0427, I want to be able to fetch the latest "real" message

which seems to require either a generic solution like fastening, or that the server understands every relevant extension

Yeah, that's why some of us wanted fastening.

IIRC the argument was that we XEPs u would need to know about already "shipped" without fastening. Like corrections. It was awhile ago now I may be forgetting parts of the discussion

I think there were also arguments that the logic required for each one is subtly different

I think it's hard to tack something like that on now

I would imagine for this to work good , a server would need to be designed with that in mind

Or rather the db layout

seems we go a bug regport in Gajim, where a server sends a roster item with a attribute "ask=unsubscribe"

i dont see this as valid according to the rfc, in my reading the attribute allows only "subscribe" as value

is there anything im missing?

You're not missing anything. The schema in both RFC3921 and RFC6121 permits only the value 'subscribe'

what server

yeah i would also like to know that, but sadly our reporting goes not that far

thanks MattJ

i just discovered that we have suprisingly little validation for roster item processing

I've been thinking about xep-0490 and why it doesn't seem to work between conversations and gajim even though they both should work and I think I understand why

The xep says a client should check that node when it connects, but when it connects it hasn't received all messages yet so it will just ignore an id it hasn't seen yet

Maybe the check should happen a bit after, when it has received the backlog

I'll need to dive in the code to check/test that

Yes that's the problem in Gajim

You need to find a logic that does not depend on the time when messages or the pubsub request is received

I just tested and I have the same issue in Conversations

I'm thinking of something: when an id from mds is received, instead of discarding if it is not found, store it until that message is received at which point we know it must be marked as read. There will be at most one id per chat to remember so it shouldn't explode state

Yes

But it's not just mark that message as read, because mds has only the last read message

You need to set all before that to read

So you should hope to receive it soon enough, otherwise it's too far back to matter anyway

All IDs in mds matter, they are the last message the account read. They cannot be to far back

Either you receive the has-been-read message which carries that id soon enough, or that message was from too long ago and it's no longer in MAM

Shouldn't I receive the message anyway as part of the initial connection ?

No, messages are requested with a variety of logic

There are certainly cases where You will not receive all messages

worst case the last-read id is kept forever

Though that's mostly for groupchat

In single, you usually will receive all messages

rako: not forever, because you are going to Read the chat and the overwrite the last read id

oh, yeah

at least for Gajim the problem was not to find that logic, its more storage and gui related, because we dont keep properly track of which message we have read

this needs probably a bigger refactor and thinking it through

Lovely

but yeah thinking about it, to make the efficient we would need to start with storing the last read message somewhere for each chat, so we can make a diff once the pubsub query comes in

so we can filter out the chats where we need to do something

because MDS as designed grows infinite, i dont want to start searching in 100 chats when this comes in

or maybe someone has already implemented this and steps forward to tell us how they did it :) ✏

You could potentially remove 'old' chats if the last message was marked, and there are no new messages for $period (if new messages come later, you can start marking them again)

crazy idea: ask the server "I have those 2 stanza-id, which one is the latest"

some servers have sortable stanza ids :)

a feature to announce that would be nice

not really a solution since even if my server supports that, the MUCs I join might not

thought I guess it works as an optimization if there's another way