Is XEP-0333: Chat Markers the XEP currently used when you want to sync the state of your read position between devices?
asterixhas joined
pulkomandyhas left
pulkomandyhas joined
dendanghas joined
dendanghas left
pulkomandyhas left
pulkomandyhas joined
dendanghas joined
asterixhas left
asterixhas joined
goffihas joined
pulkomandyhas left
pulkomandyhas joined
wurstsalathas left
MattJhas left
jonas’has left
flowhas left
paulhas left
larmahas left
flowhas joined
asterixhas left
asterixhas joined
jonas’has joined
lovetoxhas left
pulkomandyhas left
pulkomandyhas joined
MattJhas joined
larmahas joined
goffihas left
goffihas joined
lovetoxhas joined
asterixhas left
asterixhas joined
pulkomandyhas left
pulkomandyhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
goffihas left
goffihas joined
kikuchiyohas left
kikuchiyohas joined
pulkomandyhas left
pulkomandyhas joined
lovetox
yes Martin
Martin
thanks
pulkomandyhas left
pulkomandyhas joined
wurstsalathas joined
dendanghas left
dendanghas joined
Ge0rG
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?
adrienhas left
adrienhas joined
Ge0rG
I suppose it's related to 86548b87bb
pep.
Martin: see also 0430-Inbox
pep.
(which is probably gonna use 333 to some extent)
flow
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.
Ge0rG
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
Ge0rG
flow: do you have integration tests for handling multiple IQs in sequence?
asterixhas left
asterixhas joined
Ge0rG
the issue description in https://discourse.igniterealtime.org/t/issue-reporting-concerning-smack-312-and-rosterentry-setname/71838 is very accurate
flow
Ge0rG, I am sorry, but I do not understand the "multiple IQs in sequence" part of the question
Ge0rG
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
Ge0rG
thus one outgoing roster change IQ plus response, one incoming roster push IQ
flow
so? As far as I understand the issue, an integration test would invoke setName() and check that the exepcted callback is invoked
Ge0rG
flow: yes, but that integration test would require a mock server to send a push after the roster change
flow
Ge0rG, integration tests run against real servers
flow
but unrelated, this probably can be also done as unit test as smack has test fixtures to simulte the responses from a server✎
Ge0rG
flow: I haven't checked for the presence of either kind of tests for this specific issue
strarhas left
flow
unrelated: this probably can be also done as unit test as smack has test fixtures to simulate the responses from a server ✏
strarhas joined
pulkomandyhas left
pulkomandyhas joined
Ge0rG
testChangeNameToUnfiledEntry() looks like it *might* be doing this kind of test
Ge0rG
but maybe roster.reload() in the middle actually breaks it?
rionhas left
rionhas joined
flow
potentially. I had a quick look at the code, could be that simply removing item.setName(name) in RsoterEntry.setName() does the trick
Ge0rG
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
Ge0rG
I suppose the cleaner solution would be to have a different method than setName() that would also trigger the callback
flow
yeah, i somehow feel that's the reason the item.setName() is there in the first place
Martin
pep.:
> Martin: see also 0430-Inbox
Thanks 😃
flow
ahh hmm, right, RosterEntry.setName() could invoke the callback itself
Ge0rG
flow: looks like it is only ever called from RosterItem.setName() so that sounds valid
asterixhas left
asterixhas joined
pulkomandyhas left
pulkomandyhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
moparisthebesthas joined
Sam Whitedhas left
asterixhas left
asterixhas joined
pulkomandyhas left
pulkomandyhas joined
DebXWoodyhas left
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
tskhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
DebXWoodyhas joined
pulkomandyhas left
pulkomandyhas joined
asterixhas left
asterixhas joined
tskhas left
asterixhas left
asterixhas joined
pulkomandyhas left
pulkomandyhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
Wojtekhas joined
lovetox
Ge0rG, i dont get your reply on list regarding muc versioning
lovetox
why would you need to query the member list?
lovetox
ah because of offline members
lovetox
but the XEP says you get a presence for those aswell
Ge0rG
exacttly
lovetox
so why?
Ge0rG
lovetox: it doesn't say that.
lovetox
hm
Ge0rG
lovetox: it suggests that as an optional optimization
lovetox
but would that not be preferable instead of redesigning member querying
lovetox
this would make impl much more easy for clients
lovetox
and not try to mach infos from different querys into one
Ge0rG
lovetox: yes, it would be great.
lovetox
the problem is it breaks clients
Ge0rG
does it?
lovetox
because the server cannot know if a client supports the XEP, so it cant just send unavailable presences on join
Ge0rG
MattJ said it shouldn't, as it is also used to inform clients about live membership changes
lovetox
which is not in the spec
lovetox
ah ok
lovetox
if thats so, then im in favor of just adding this to that xep
Ge0rG
and GC1 clients already were exposed to presence-unavailable for occupants they didn't ever see
asterixhas left
asterixhas joined
lovetox
this is definitly strong contender for XEP of the year
asterixhas left
asterixhas joined
lovetox
this is an insane performance boost when joining mucs
lovetox
i want to implement it right now
MattJ
:)
Ge0rG
lovetox: maybe you should wait for the Council to accept it ;)
pulkomandyhas left
Ge0rG
Oh, one thing I missed mentioning:
> The value MUST be generated only by the server and MUST be treated by the client as opaque.
serge90has left
serge90has joined
lovetox
what im missing in the XEP is, does the server summary of presence stanzas?
lovetox
like if since my last join a user 200times changed his nickname
lovetox
do i get all those changes?
MattJ
You don't
Ge0rG
MattJ: that should be mentioned more explicitly
MattJ
+1
MattJ
On the other hand...
Ge0rG
MattJ: also the note regarding @ver being opaque
MattJ
It don't make much difference to the client, does it? (apart from performance)
asterixhas left
asterixhas joined
Ge0rG
MattJ: in theory, you should send all changes to occupation and messages interleaved.
lovetox
yeah with nickchanges it gets tricky
Zash
Presence in MAM?
lovetox
hmm
lovetox
no really the nick changes are a problem or not?
MattJ
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)
Ge0rG
MattJ: I was quoting from XEP-0237
MattJ
lovetox, at a minimum you would see the old nick leave and the new one join
lovetox
MattJ the problem is if that nick sent messages in between
MattJ
I guess the nick change status code /should/ be included, but if we can avoid mandating that I'd like to...
Ge0rG
what if somebody else joined under that nick inbetween?
MattJ
Yeah, though this problem exists without presence versioning
Ge0rG
and wrote nasty messages.
MattJ
Leave room, nick change, message, nick change, rejoin the room
Zash
Tie it into Occupant ID?
lovetox
yeah true, if i get this message via MAM i cant say who wrote it
MattJ
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
lovetox
i guess this is the point of an anonymous muc anyway
lovetox
but yeah occupant id would solve that
lovetox
although no idea how i should display such thing UI wise to the user :D
lovetox
probably add the occupant-id into the color hash
Ge0rG
lovetox: maybe you should only care about this problem in private closed-group MUCs
Ge0rG
and in non-anon MUCs MAM will append the real-jid, or something?
lovetox
hm yeah
lovetox
though UI wise i could simply display real jids in a tooltip
lovetox
so at least there is a way for the user to discover that
lovetox
and no in non-anon room the color hash is of the real jid anyway
lovetox
so in theory the user is more than equiped to notice that
Ge0rG
color hash ❤
lovetox
or whatever it is called
lovetox
the thing that generates the user color
Ge0rG
I just love the feature
pulkomandyhas joined
lovetox
its great though i get sometimes very similiar colors
lovetox
but added with avatars it should be ok
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
pep.
Is anybody actually having perf issues with current MUC btw? And from what amount of users?
pep.
That is noticeable to other users*
Ge0rG
joining the Matrix HQ takes a minute or two. Some client implementations will use that to time-out the join
MattJ
The conversation that sparked this XEP involved a MUC with 5-10k users
pep.
Right, so not a typical XMPP channel
Ge0rG
Are there actual MUCs with this many people?
MattJ
(it's not clear that this spec alone is going to suffice for solving that)
MattJ
Ge0rG, yes, though obviously in custom deployments
asterixhas left
asterixhas joined
Zash
Might wanna limit presence to those recetly active?
asterixhas left
asterixhas joined
Ge0rG
Also... if most of these users are joining and leaving at typical rates, the delta will be longer than the absolute list ;)
MattJ
Things like "dump all employees into a single MUC" (if you've used Slack, something like their default #general channel)
MattJ
Ge0rG, yes, as in roster versioning the server should be free to just send the current list
pulkomandyhas left
pulkomandyhas joined
lovetoxhas left
asterixhas left
asterixhas joined
Ge0rG
MattJ: see my marker token response on the ML
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
pulkomandyhas left
paulhas joined
pulkomandyhas joined
asterixhas left
asterixhas joined
pulkomandyhas left
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
pulkomandyhas joined
Ge0rG
flow: do you have the setName() thing on your agenda or are you anticipating a PR?
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
lovetoxhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
serge90has left
serge90has joined
pulkomandyhas left
pulkomandyhas joined
serge90has left
serge90has joined
flow
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?).
serge90has left
serge90has joined
sonnyhas left
serge90has left
pulkomandyhas left
serge90has joined
serge90has left
pulkomandyhas joined
serge90has joined
serge90has left
serge90has joined
serge90has left
serge90has joined
serge90has left
serge90has joined
pulkomandyhas left
serge90has left
serge90has joined
Ge0rG
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
sonnyhas joined
pulkomandyhas joined
serge90has left
serge90has joined
serge90has left
serge90has joined
serge90has left
serge90has joined
lovetox
hm so i get the ver attribute only on my self presence
Ge0rG
it needs to be on every presence
lovetox
this means i receive X presences and dont know if this is a catchup or not
Ge0rG
and yes, the reset token must come first, before any presence
alexishas left
serge90has left
serge90has joined
serge90has left
serge90has joined
pulkomandyhas left
adrienhas left
serge90has left
serge90has joined
adrienhas joined
serge90has left
serge90has joined
pulkomandyhas joined
pulkomandyhas left
serge90has left
serge90has joined
pulkomandyhas joined
lovetox
was there ever an update to Serverless Messaging
lovetox
maybe some xep that defines some transport encryption
lovetox
Even most E2E is hard, because we have no PEP to share keys and stuff
jonas’
OTR would work just fine
jonas’
:>
lovetox
legacy PGP works also
jonas’
see, all the good stuff is just fine
lovetox
Link Mauve, tells me often he like that feature on conferences
serge90has left
lovetox
but not so sure if people really like it to send messages plain over open wlan networks
serge90has joined
Martinhas left
Martinhas joined
serge90has left
serge90has joined
flow
I am not sure if transport encryption is feasible with serverless messaging
jonas’
it is, anonymous TLS is (was?) a thing
jonas’
it’s only useful against passive attackers though
Zash
jonas’: Is it still?
jonas’
if it isn’t, you can still generate a self-signed certificate for your hostname
jonas’
could even do TOFU key pinning
Zash
Tie it into the E2EE thing of your choice
Zash
or into a overlay network like Tor
Zash
There's an RFC about using OpenPGP keys in TLS
serge90has left
serge90has joined
flow
ahh right, that would be worth an experiment
Zash
Anon TLS and then use some E2EE or similar magic to authenticate the connection, like how SCRAM-PLUS works
mathieui
is there any client other than gajim that does serveless messaging though?
Zash
Pidgin
Zash
There's a thing in the Swift tree too
Zash
and Telepathy I think?
Zash
> thing in Swift
thing that works like a server and translates to serverless, so should work with any client
flow
mathieui, I hope to continue working on smack's support for serverless
Kev
"Slimber"
asterixhas left
SouLhas left
asterixhas joined
pulkomandyhas left
SouLhas joined
serge90has left
serge90has joined
pep.
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)
pep.
Or E2EE indeed
Zash
Like why hasn't anyone just taken Tor and hooked it into a serverless-messaging thing?
pep.
who knows
Zash
Extra secure E2EE!!! P2P! All the buzzwords!
pep.
Maybe it's just another case of bad marketting
Zash
But no, everyone's just reinventing the full stack from scratch.