XSF Discussion - 2023-07-05

For example if you're in a public muc

“12:22:03 lovetox> as people dont have thousands of bookmarks”, citation needed. :p

Although I only have 245 of them true, not thousands.

And the hard limit is 256, and nobody can ever have more. QED

I thought it was max. :o

Re read state sync, yeah chat markers, receipts and chatstates aren't good solutions because they're meant for other accounts in the chat, not you. Using them for this is but a workaround and ignores all people who don't want to share this kind of info ✏

FWIW I'm planning to work on this stuff before the end of the year

Link Mauve: And I consider you a heavy user

you can always call your edge cases "Link Mauve" and not be wrong

^^'

FWIW, we're working on these things for Swift/M-Link at the moment.

Kev: based on existing XEPs, or...?

Right now we're just looking at putting last-read IDs into a PEPish node.

But for standardisation, I really want to tell the server what has been read, and for it to then do unread counts for the client. ✏

But the client would still be provided with an id right of the last read message right? ✏

Yes, you need that.

Server can read the pep node to provide such summaries for thin clients if desired

But the client can do that on its own without server cooperation (beyond supporting MAM). Getting unread counts though either means polling MAM for every contact or server cooperation.

Yeah ok. For my TUI use-case I don't really mind not having an unread count ✏

Even not a count, but a flag that there are unread messages, is hard to do without server co-operation (or fully polling all chats through MAM)

My client is almost always live :P

(even though it has MAM support)

pep., then this doesn’t apply to you, but many users of TUI clients do want to know when they have new messages and from whom.

Currently if I start poezio in local, it won’t open any chat if I have another client which received the offline messages, and that’s not good.

yeah unread markers is kind of a must have feature for multi clients usage

you mean read :)

the problem is not that clients dont show unread messages

they show potentially messages as unread which were already read on another client

Well, both. Currently clients show both too few and too many unread messages, within the same client :)

lovetox: as I understand it, Gajim doesn't do a full sync so it would benefit from this, no? Otherwise how do you currently determine which conversations have unread messages?

how can you show to few unread messages? this is not the protocols fault, its probably your decision as client to not use the tools available for whatever reason

MattJ, yes we do a full sync with the account archive

i dont really understand the reasoning behind not doing a full sync with an account archive

it cointains only messages you wrote and people sent to you

as long as you are not britney spears, i guess a full sync is a matter of seconds ✏

Don't forget the archives for every MUC you're in.

Those have unread messages too.

im not forgetting them i excluded them for the discussion as MUC is a special situation

of course nobody wants to do full syncs with MUC archives, not sure if good solutions exist

Still want to do full sync with MUC except the first time, usually

Unless it's a thin client

If you're a total knowledge client.

Right.

maybe occupant-id and replies can help the server to detect messages, but apart from that .. i see no real solution for this problem

on a new MUC Gajim syncs the last 24 hours

from that point on Gajim does a full sync, except the time offline goes over a user defined limit

for private MUCs (which are small normally) Gajim defaults to full sync

for public MUCs Gajim defaults to 1 day

but the user can change this with a per MUC setting

but it feels not like the same problem as read markers

this would basically be solved if i could do a IQ to the server that says, give me stanza-ids which someone mentioned me?

is that the definition of "unread" here?

because normally i define as unread, all messages while i was offline, not just one where i was mentioned

You want both really (are there unread messages? Are there mentions?) because they are both useful but will result in different UI and notification behaviour

but with mam there i a "count" query already

i can simply let it give me the count from now, back to the last stanza-id

and this gives me my unread messages

Not quite

if i can get a read marker from another client, i simply do a count to that one

why not? this should work

apart from the standard saying that no server needs to return correct results :D

First, that will count outgoing messages from your other clients as unread, it will also count typing notifications, read markers sent by the other party, etc.

true forget about that :/

and with omemo full stanza encryption the server could not even determine anymore what is a text messages or not

I planned to put some logic in the server to determine if a message should count as unread, but OMEMO also causes problems for that approach

Yep

Honestly I'm leaning towards just putting that info outside any encrypted layer. It leaks one bit of information that most people won't care about anyway (compared to being told they have unread messages when they don't - a situation that already happens on Siskin and Snikket iOS)

If we had a time machine it would have been wise to use the type attribute for this I think

Anyway, with that solved things like Inbox and Prosody's mod_map (https://modules.prosody.im/mod_map) become much more useful

but how would a read marker play into that with MUC archives

my read marker will problaby not be in the MUC archive

or the MUC Archive will not know about it

MUCs are of course special, but XEP-0437 already does something for this

possibly stupid question but: why cant we send a message id to the server of the last message that was read by the user? regardless of client and muc/mix/pms whatever

With the configuration I used in a production deployment of that, the MUC would receive read markers but not broadcast them, then use that info to determine which messages were unread

and that is stored until next time the person checks messages

of course the muc could store that info

MSavoritias fae.ve: that sounds like the earlier "store it in PEP" discussion

right.

its basically a JID -> stanza id key / value store

sorry still learning xmpp here ^^

The official tagline of the XSF

heh. so putting outside the encrypted layer you mean that marking if its a message or not?

Yeah, basically if it's a message that should be counted as 'unread'

yeah. thats a solution to the encryption problem not the unread though is it?

although it makes the logic easier

for the client

I think you're assuming the client has already done a full sync of archive. In that case, yes, throwing some IDs in PEP and syncing those would be enough

But there is also a desire to solve the problem for clients that don't do a full sync

Those clients ideally have a way to ask the server what unread messages there are

and get only the unread. yeah makes sense that way

Exactly

This is already a problem, for we send out push notifications to iOS clients for encrypted messages that may not contain any body (such messages are used in OMEMO for syncing session state), so having that information would solve that too

yep

but why cant we use the type attribute for it?

We can. But we don't ✏

Almost everything is type=chat now

I dare you 😉

xmpp: extensible but not really 😮‍💨

more like unchanging though here 🤔

Even if we standardized a new type that means "this is not a user message" it would be more than a decade before running clients stopped using it

(Stopped using type chat, I mean)

We still have clients on the network that don't send unique stanza ids

Still, it could be something worth considering for XMPP 2.0

agreed

im not saying we should do it tomorrow. but i would still like some long term proper solution to this.