jdev - 2023-01-01

roberty0979, checking back in before i do some new years activity; however, rust is probably the least 'functional' of the bunch. xmpp (and most other things really) is very pleasant to implement with pattern matching and functional languages tend to be extremely easy to reason about. i used to write a lot of java and currently write a lot of ruby at work but would very seriously like it if the rest of the engineering staff weren't so enamored with go as the 'next step' in scaling. i've become rather sick of having to spend time figuring out just what the hell people were trying to accomplish with some of the wild stuff you see in 'OOP' or procedural/imperative languages. functional programming doesn't stop people from doing it, but it's like giving children the "big legos" so that they can't swallow them or stab each other.

:)

what is it that means read state doesnt sync between conv, dino, and gajim? it's chat markers that would do it right, and they all implement that?

or is it that it does, but only at reconnect

qy: there's no protocol for this. Clients generally use a mix of chat markets, chatstates and maybe read receipts to work around this but that's not what they're for

wow a feature that doesn't have an XEP

that's a first

but i feel like chat markers are right to use for this

chat markers yeah, not markets :D (autocorrection..)

qy, chat markers are destined to all recipients (your other devices included). I'd rather have something that is explicitely for your clients only.

Typically chat markers is a feature I disable for privacy reasons. I do want read state sync though

(Yes I could also hack around it with mod_firewall but not everybody has their own prosody and is knowledgeable enough to do this.)

pep.; well ok, chat markers is still experimental, perhaps we can amend it and allow for configurable visibility?

if done at server level, wouldn't require mass updating of clients

just ejd and prosody (who even uses the rest :p)

I guess so

Zash; Holger; thoughts?

I think it would be important, that they don't spam the server and clients, because it would slow down bigger groups very much. I wonder if that change is to big a change.. A cleaner way would be to store it in an account ~client~ controlled pep node? And other clients of the same account can look it up there? ✏

and subscribe to it

sounds reasonable

Talking about slow transition to mix...

That's independent of mix anyway. As it should be usable in 1:1 too

Or of any groupchat component really

Yes, thats nice.

so, this needs an XEP?

or at least us to agree on how to do it