jdev - 2020-04-01

Is XEP-0333: Chat Markers the XEP currently used when you want to sync the state of your read position between devices?

yes Martin

thanks

flow: I've just encountered an issue on smack 4.3.4 that looks like an exact reappearance of https://discourse.igniterealtime.org/t/issue-reporting-concerning-smack-312-and-rosterentry-setname/71838 and https://discourse.igniterealtime.org/t/smack-4-1-0-rosterentry-setname-doesnt-change-the-name/73006 - do you know anything about that?

I suppose it's related to 86548b87bb

Martin: see also 0430-Inbox

(which is probably gonna use 333 to some extent)

Ge0rG, its not easy to comment on "an issue" without a clear issue description. I guess you probably talking about RosterEntry.setName() not changing the name? And why do you suppose that it is related to 86548? That information would be helpful. I am not aware of issues with that part of the API. But if a previously closed issues reappears that this should probably lead to an integreation test to avoid regressions in this area. A minimal reproducer would be nice, to debug the issue and to act as base for a potential integration test.

flow: RosterEntry.setName() does change the name but it doesn't fire the RosterListener.entriesUpdated() callback. In 86548 the code was changed from changing an internal shadow copy of the name in RosterEntry to silently changing the "master" value in the RosterItem. So there is no entriesUpdated() from setName(), and then the incoming roster push is processed, but the RosterItem already has the new name so no entriesUpdated() is fired either

flow: do you have integration tests for handling multiple IQs in sequence?

the issue description in https://discourse.igniterealtime.org/t/issue-reporting-concerning-smack-312-and-rosterentry-setname/71838 is very accurate

Ge0rG, I am sorry, but I do not understand the "multiple IQs in sequence" part of the question

flow: setName() issues a roster update IQ and waits for the result, which is allowed to be empty. The actual roster change then would come as a roster push from the server

thus one outgoing roster change IQ plus response, one incoming roster push IQ

so? As far as I understand the issue, an integration test would invoke setName() and check that the exepcted callback is invoked

flow: yes, but that integration test would require a mock server to send a push after the roster change

Ge0rG, integration tests run against real servers

flow: I haven't checked for the presence of either kind of tests for this specific issue

unrelated: this probably can be also done as unit test as smack has test fixtures to simulate the responses from a server ✏

testChangeNameToUnfiledEntry() looks like it *might* be doing this kind of test

but maybe roster.reload() in the middle actually breaks it?

potentially. I had a quick look at the code, could be that simply removing item.setName(name) in RsoterEntry.setName() does the trick

flow: I'm pretty sure it will, except that you won't get an update on the incoming IQ result ack but only after the push

I suppose the cleaner solution would be to have a different method than setName() that would also trigger the callback

yeah, i somehow feel that's the reason the item.setName() is there in the first place

pep.: > Martin: see also 0430-Inbox Thanks 😃

ahh hmm, right, RosterEntry.setName() could invoke the callback itself

flow: looks like it is only ever called from RosterItem.setName() so that sounds valid

Ge0rG, i dont get your reply on list regarding muc versioning

why would you need to query the member list?

ah because of offline members

but the XEP says you get a presence for those aswell

exacttly

so why?

lovetox: it doesn't say that.

hm

lovetox: it suggests that as an optional optimization

but would that not be preferable instead of redesigning member querying

this would make impl much more easy for clients

and not try to mach infos from different querys into one

lovetox: yes, it would be great.

the problem is it breaks clients

does it?

because the server cannot know if a client supports the XEP, so it cant just send unavailable presences on join

MattJ said it shouldn't, as it is also used to inform clients about live membership changes

which is not in the spec

ah ok

if thats so, then im in favor of just adding this to that xep

and GC1 clients already were exposed to presence-unavailable for occupants they didn't ever see

this is definitly strong contender for XEP of the year

this is an insane performance boost when joining mucs

i want to implement it right now

:)

lovetox: maybe you should wait for the Council to accept it ;)

Oh, one thing I missed mentioning: > The value MUST be generated only by the server and MUST be treated by the client as opaque.

what im missing in the XEP is, does the server summary of presence stanzas?

like if since my last join a user 200times changed his nickname

do i get all those changes?

You don't

MattJ: that should be mentioned more explicitly

+1

On the other hand...

MattJ: also the note regarding @ver being opaque

It don't make much difference to the client, does it? (apart from performance)

MattJ: in theory, you should send all changes to occupation and messages interleaved.

yeah with nickchanges it gets tricky

Presence in MAM?

hmm

no really the nick changes are a problem or not?

Oh, regarding the opaque thing I assumed you were quoting from the XEP... I had agreed with JC that it would be opaque to the client (because this leaves a lot of doors open for the server implementation, which is important)

MattJ: I was quoting from XEP-0237

lovetox, at a minimum you would see the old nick leave and the new one join

MattJ the problem is if that nick sent messages in between

I guess the nick change status code /should/ be included, but if we can avoid mandating that I'd like to...

what if somebody else joined under that nick inbetween?

Yeah, though this problem exists without presence versioning

and wrote nasty messages.

Leave room, nick change, message, nick change, rejoin the room

Tie it into Occupant ID?

yeah true, if i get this message via MAM i cant say who wrote it

So I don't see that this spec makes the situation any worse than today, nor is it this spec's duty to solve that problem

i guess this is the point of an anonymous muc anyway

but yeah occupant id would solve that

although no idea how i should display such thing UI wise to the user :D

probably add the occupant-id into the color hash

lovetox: maybe you should only care about this problem in private closed-group MUCs

and in non-anon MUCs MAM will append the real-jid, or something?

hm yeah

though UI wise i could simply display real jids in a tooltip

so at least there is a way for the user to discover that

and no in non-anon room the color hash is of the real jid anyway

so in theory the user is more than equiped to notice that

color hash ❤

or whatever it is called

the thing that generates the user color

I just love the feature

its great though i get sometimes very similiar colors

but added with avatars it should be ok

Is anybody actually having perf issues with current MUC btw? And from what amount of users?

That is noticeable to other users*

joining the Matrix HQ takes a minute or two. Some client implementations will use that to time-out the join

The conversation that sparked this XEP involved a MUC with 5-10k users

Right, so not a typical XMPP channel

Are there actual MUCs with this many people?

(it's not clear that this spec alone is going to suffice for solving that)

Ge0rG, yes, though obviously in custom deployments

Might wanna limit presence to those recetly active?

Also... if most of these users are joining and leaving at typical rates, the delta will be longer than the absolute list ;)

Things like "dump all employees into a single MUC" (if you've used Slack, something like their default #general channel)

Ge0rG, yes, as in roster versioning the server should be free to just send the current list

MattJ: see my marker token response on the ML

flow: do you have the setName() thing on your agenda or are you anticipating a PR?

Ge0rG, I would anticipate something that reminds me that it is an open issue. Either a forum post, PR or an new Smack issue (IIRC your JIRA account can create smack issues?).

flow: it looks like RosterEntry.setName() is the only relevant place to change, as there are no other methods for manipulating individual entries, and the RosterGroup modifer functions all rely on the reflected roster push

hm so i get the ver attribute only on my self presence

it needs to be on every presence

this means i receive X presences and dont know if this is a catchup or not

and yes, the reset token must come first, before any presence

was there ever an update to Serverless Messaging

maybe some xep that defines some transport encryption

Even most E2E is hard, because we have no PEP to share keys and stuff

OTR would work just fine

:>

legacy PGP works also

see, all the good stuff is just fine

Link Mauve, tells me often he like that feature on conferences

but not so sure if people really like it to send messages plain over open wlan networks

I am not sure if transport encryption is feasible with serverless messaging

it is, anonymous TLS is (was?) a thing

it’s only useful against passive attackers though

jonas’: Is it still?

if it isn’t, you can still generate a self-signed certificate for your hostname

could even do TOFU key pinning

Tie it into the E2EE thing of your choice

or into a overlay network like Tor

There's an RFC about using OpenPGP keys in TLS

ahh right, that would be worth an experiment

Anon TLS and then use some E2EE or similar magic to authenticate the connection, like how SCRAM-PLUS works

is there any client other than gajim that does serveless messaging though?

Pidgin

There's a thing in the Swift tree too

and Telepathy I think?

> thing in Swift thing that works like a server and translates to serverless, so should work with any client

mathieui, I hope to continue working on smack's support for serverless

"Slimber"

serverless messaging could very well use XTLS and even if XTLS itself still allows MITM, that could be initiated via a secure channel (normal XMPP connections)

Or E2EE indeed

Like why hasn't anyone just taken Tor and hooked it into a serverless-messaging thing?

who knows

Extra secure E2EE!!! P2P! All the buzzwords!

Maybe it's just another case of bad marketting

But no, everyone's just reinventing the full stack from scratch.