XMPP Council - 2023-02-22

moparisthebest has left 00:42:40
moparisthebest has joined 00:43:05
MSavoritias (fae,ve) has joined 01:29:25
gooya has left 01:51:22
MSavoritias (fae,ve) has left 01:57:12
Tobias has joined 02:36:50
Tobias has left 02:53:53
Ingolf has left 03:18:59
Ingolf has joined 03:19:02
pprrks has left 04:04:21
pprrks has joined 04:06:06
mdosch has joined 04:16:11
Tobias has joined 04:37:42
Tobias has left 04:54:33
Tobias has joined 05:04:42
marc0s has left 05:26:51
marc0s has joined 05:26:53
MSavoritias (fae,ve) has joined 05:37:40
emus has joined 06:11:22
pprrks has left 06:45:58
pprrks has joined 06:51:28
neox has joined 07:46:31
Kev has joined 07:57:14
pprrks has left 08:06:14
marc0s has left 08:08:19
marc0s has joined 08:08:22
pprrks has joined 08:10:41
marc0s has left 08:14:52
marc0s has joined 08:14:55
marc0s has left 08:15:23
marc0s has joined 08:15:25
marc0s has left 08:46:50
marc0s has joined 08:46:52
pprrks has left 08:58:00
pprrks has joined 09:00:16
marc0s has left 10:00:31
marc0s has joined 10:00:34
marc0s has left 10:01:16
marc0s has joined 10:01:20
marc0s has left 10:13:34
marc0s has joined 10:13:36
gooya has joined 10:34:41
marc0s has left 11:06:52
marc0s has joined 11:06:55
marc0s has left 12:29:28
marc0s has joined 12:29:31
marc0s has left 12:30:33
marc0s has joined 12:30:35
vaulor has left 12:43:53
vaulor has joined 12:47:48
pprrks has left 13:26:48
pprrks has joined 13:28:09
pprrks has left 13:48:14
marc0s has left 13:54:21
marc0s has joined 13:54:25
moparisthebest has left 14:16:02
marc0s has left 14:26:04
marc0s has joined 14:26:09
vaulor has left 14:46:12
vaulor has joined 14:52:31
pprrks has joined 14:54:06
pprrks has left 15:00:09
moparisthebest has joined 15:05:02
marc0s has left 15:13:53
marc0s has joined 15:13:55
pprrks has joined 15:14:45
pprrks has left 15:19:34
pprrks has joined 15:52:49
marc0s has left 16:00:06
marc0s has joined 16:00:10
larma 16:00:40
👋
Ge0rG 16:00:46
😜
marc0s has left 16:00:46
marc0s has joined 16:00:49
jonas’ 16:00:58
o/
daniel 16:01:00
Hi
daniel 16:01:04
1) Roll call
jonas’ 16:01:07
moparisthebest 16:01:54
Hello
daniel 16:02:01
I don’t think we have anything to talk about. the editor isn’t active currently
daniel 16:02:24
so instead of running through an empty agenda I’m just going to jump to AOB
daniel 16:03:01
does anyone have any AOB?
jonas’ 16:03:04
I do not
Ge0rG 16:03:08
none here
moparisthebest 16:03:16
Nope
larma 16:04:30
No
daniel 16:04:56
ok. that was uneventful again
daniel 16:05:04
see you all next week
moparisthebest 16:05:24
See you then, thanks
jonas’ 16:09:36
see ya
pprrks has left 16:48:27
Ingolf has left 16:59:51
Ingolf has joined 17:03:22
pprrks has joined 17:05:41
neox has left 17:07:37
neox has joined 17:08:57
neox has left 17:27:15
mdosch has left 17:32:33
mdosch has joined 17:34:19
marc0s has left 18:19:42
marc0s has joined 18:19:45
sonny has left 18:20:43
marc0s has left 18:21:57
marc0s has joined 18:22:01
marc0s has left 18:23:12
marc0s has joined 18:23:15
sonny has joined 18:24:25
Tobias has left 18:58:16
Tobias has joined 18:58:19
larma 19:01:17
Just noticed during the discussion about XEP-0359 (stanza-id): XEP-0313 (MAM) was advanced to stable but depends on XEP-0359 which is still experimental/deferred. This shouldn't be possible. Maybe we should soon issue a last call for XEP-0359 (even though there are discussions about it right now) to fix that situation?
Tobias has left 19:02:30
Tobias has joined 19:02:38
marc0s has left 19:02:44
marc0s has joined 19:02:47
marc0s has left 19:03:27
marc0s has joined 19:03:29
Ge0rG 19:03:57
Am I going to be hated by everyone if I veto until <origin-id/> is burned out with napalm?
larma 19:04:59
I'd be fine to get rid of origin-id, but it still has it's usecase (reflection detection in MUCs that don't do the non-RFC-compliant stable-id thing)
Zash 19:05:10
This is the XSF. You can do anything at the XSF! The the only limit is XEP-0001.
Ge0rG 19:05:58
larma: how many of those MUCs are still in place [and don't also strip any XML payload besides of <body>, I'm looking at you, biboumi]
larma 19:06:21
probably not a lot
Tobias has left 19:06:47
Tobias has joined 19:06:50
larma 19:07:25
that's why I say I'm fine with getting rid of it 😉
tmolitor 19:13:25
didn't we have some informal consensus / business rule that said that an origin-id and a is on the stanza having the same value (and proper by attribute) means that the client uses something sufficiently random like uuids to generate the id?
tmolitor 19:16:15
that said, a disco feature indicating that the ids are sufficiently random (128bit of entropy, uuid, whatever) would be a better solution, imho...
larma 19:18:40
tmolitor, not strictly "sufficiently random" (because that's only recommended by 0359), but it requires them to be a) unique at the sender and b) not predictable - which is hard to achieve without actually using sufficient randomness :)
marc0s has left 19:18:57
tmolitor 19:21:02
yeah...that one :)
tmolitor 19:21:12
was that written down anywhere?
Zash 19:22:17
disco is dead, MAM killed it :(
marc0s has joined 19:22:42
larma 19:23:08
technically a client could generate a salt at start and then for every outgoing stanza hash that salt together with the nanoseconds since start of the client. That wouldn't be a lot of entropy, but for all practical purposes, this would be as good as a random uuid.
Zash 19:23:47
There exists a perfect way to generate unique stanza ids
Zash 19:23:58
(stream-id, counter++)
Zash 19:24:09
(pass trough hash or HMAC or something)
Ingolf has left 19:24:52
larma 19:25:50
tmolitor, well origin-id as per 0359 requires: > the IDs defined in this extension MUST be unique and stable within the scope of the generating XMPP entity. > The values of the 'id' attribute SHOULD be unpredictable. Thus if a client generates an origin-id and puts the same id into the message's id-attribute, you know it's sufficiently random.
tmolitor 19:25:53
larma: depends on the entropy of the salt ;)
marc0s has left 19:28:16
marc0s has joined 19:28:18
Ge0rG 19:29:47
All the good clients already use that in stanza IDs, and if you rely on a third party client doing it for your database access or anything, you are in for a tough ride.
larma 19:30:48
We can also just define a new XEP to define the <good-id /> element that declares that the generation of the message's id-attribute followed certain rules.
Ge0rG 19:31:33
Which problem does that solve, again?
larma 19:32:31
~~some legacy clients generating id's be generating 16 bit of randomness at start and then counting up from that with every stanza and therefor likely running into collisions without bad intent~~ ✎
larma 19:32:48
some legacy clients generating ids by generating 16 bit of randomness at start and then counting up from that with every stanza and therefor likely running into collisions without bad intent ✏
Ge0rG 19:33:30
Collisions of what exactly?
daniel 19:33:51
Anything that references that id
daniel 19:33:56
Edits. Replies
daniel 19:34:00
Reactions
larma 19:34:06
In direct chats only, of course
daniel 19:34:11
Yes
daniel 19:34:19
And edits in muc
Tobias has left 19:34:19
Ge0rG 19:34:24
Which only affects the user of the broken client when also using a modern client
Tobias has joined 19:34:27
Ge0rG 19:34:44
But the broken client won't generate an adequate ID for referencing anyway
Tobias has left 19:35:06
Tobias has joined 19:35:09
larma 19:35:21
Yes, and thus the replying/reacting client should not allow the user to send replies/reactions to such message with broken id
Ge0rG 19:35:22
You need to send a message from pidgin, then edit it from a modern client
Ge0rG 19:36:14
Disabling a feature because of an opaque thing the user has no visibility of sounds like a bad idea
tmolitor 19:36:22
+1 for the <good-id/> element
daniel 19:36:30
> Yes, and thus the replying/reacting client should not allow the user to send replies/reactions to such message with broken id Yes and origin ID is an OK detection for whether or not the other client is same ✎
Tobias has left 19:36:31
daniel 19:36:37
> Yes, and thus the replying/reacting client should not allow the user to send replies/reactions to such message with broken id Yes and origin ID is an OK detection for whether or not the other client is sane ✏
Tobias has joined 19:36:43
daniel 19:36:50
Origin ID is essentially good-id
tmolitor 19:37:12
yes, but with an additional id value that we could get rid of...
daniel 19:37:16
Why come up with a new element that does the same thing minus muc reflection
daniel 19:37:35
Then mandate message id==origin id
daniel 19:37:37
For the sender
Ge0rG 19:37:53
Are you actually disabling sophisticated features on messages without origin-id?
Ge0rG 19:38:08
daniel [20:37]: > Then mandate message id==origin id I've been asking for that since day 1
daniel 19:38:17
Me too
Ingolf has joined 19:38:34
Tobias has left 19:38:59
tmolitor 19:38:59
> Then mandate message id==origin id that would be ideal, what is blocking that?
Tobias has joined 19:39:03
Ge0rG 19:39:08
yaxim will generate sufficiently random IDs but not set origin-id
Ge0rG 19:39:16
tmolitor: the author
Tobias has left 19:39:22
Tobias has joined 19:39:31
tmolitor 19:39:59
on what basis?
Ge0rG 19:40:10
It's not technically required
Tobias has left 19:41:09
Tobias has joined 19:41:12
larma 19:41:34
When I write that "best practices on using IDs" XEP (with how to reference messages depending on context), I'll definitely add that origin-id should be same as message id 🙂
larma 19:41:51
~~Not technically requires, but definitely a best practice.~~ ✎
larma 19:41:56
Not technically required, but definitely a best practice. ✏
larma 19:42:39
Ge0rG, well, clients already have to limit some features for some messages. Because there exist messages without any id, makign it very hard to reference them 😉
daniel 19:43:42
I'm gonna block stanza id unless this must is in stanza id
tmolitor 19:44:45
> I'm gonna block stanza id unless this must is in stanza id wait, what? what id are you referring to exactly?
marc0s has left 19:45:12
marc0s has joined 19:45:16
daniel 19:45:22
The xep
marc0s has left 19:46:01
marc0s has joined 19:46:05
daniel 19:47:19
I think the only reason it's not in the xep is that it's slightly complicated to do in smack
larma 19:48:41
you mean "If the <origin-id /> element is present, the origin sender MUST set the message's id-attribute to the same value as the id-attribute of the <origin-id /> element." should be in XEP-0359? Rather than kicking origin-id out entirely?
Ge0rG 19:50:32
Can't you just accept any ID with more than four characters and be done?
daniel 19:52:31
> you mean "If the <origin-id /> element is present, the origin sender MUST set the message's id-attribute to the same value as the id-attribute of the <origin-id /> element." should be in XEP-0359? Rather than kicking origin-id out entirely? If that wording is in 359 it becomes functionally equivalent to <good-id/>
daniel 19:53:55
We could just remove origin id entirely. But it seems fairly well established for a good-id replacement
Zash 19:53:58
<good-id/> meaning that <message id=good> ?
Ge0rG 19:54:00
And you have an excuse to block out perfectly working clients from modern features
daniel 19:55:38
> <good-id/> meaning that <message id=good> ? Yes
marc0s has left 19:56:06
marc0s has joined 19:56:09
Zash 19:56:25
Sure would help against my feeling that modern XMPP is full of redundant duplicated IDs and timestamps and also redundancy
Ge0rG 19:56:51
Zash: also duplicate information
marc0s has left 19:58:02
marc0s has joined 19:58:05
marc0s has left 19:59:50
marc0s has joined 19:59:53
marc0s has left 20:00:02
marc0s has joined 20:00:05
marc0s has left 20:10:29
marc0s has joined 20:10:32
marc0s has left 20:13:29
Tobias has left 20:13:29
marc0s has joined 20:13:32
Tobias has joined 20:13:39
Tobias has left 20:16:16
Tobias has joined 20:16:20
Tobias has left 20:16:28
Tobias has joined 20:16:34
Tobias has left 20:16:59
Tobias has joined 20:17:04
Tobias has left 20:17:08
Tobias has joined 20:17:39
Tobias has left 20:18:39
Tobias has joined 20:18:42
Tobias has left 20:18:49
Tobias has joined 20:18:59
Tobias has left 20:20:07
Tobias has joined 20:20:10
marc0s has left 20:21:07
marc0s has joined 20:21:09
Tobias has left 20:23:12
Tobias has joined 20:23:16
Tobias has left 20:23:20
Tobias has joined 20:23:41
marc0s has left 20:24:10
marc0s has joined 20:24:13
marc0s has left 20:26:56
marc0s has joined 20:27:00
pprrks has left 20:30:06
marc0s has left 20:34:21
marc0s has joined 20:34:24
pprrks has joined 20:35:15
tmolitor 20:37:50
> I'm gonna block stanza id unless this must is in stanza id +1 for this MUST
marc0s has left 20:41:02
marc0s has joined 20:41:05
marc0s has left 20:55:18
marc0s has joined 20:55:21
marc0s has left 20:58:28
marc0s has joined 20:58:31
marc0s has left 20:58:57
marc0s has joined 20:59:00
marc0s has left 21:00:32
marc0s has joined 21:00:35
marc0s has left 21:01:02
marc0s has joined 21:01:05
marc0s has left 21:02:59
marc0s has joined 21:03:02
marc0s has left 21:04:07
marc0s has joined 21:04:11
marc0s has left 21:13:33
marc0s has joined 21:13:37
marc0s has left 21:14:57
marc0s has joined 21:14:59
marc0s has left 21:15:43
marc0s has joined 21:15:46
MSavoritias (fae,ve) has left 21:25:41
marc0s has left 21:29:16
marc0s has joined 21:29:18
paul has left 21:37:01
marc0s has left 21:42:07
marc0s has joined 21:44:02
paul has joined 21:58:23
Tobias has left 22:08:23
Kev has left 22:13:28
pprrks has left 22:26:11
marc0s has left 22:29:55
marc0s has joined 22:31:31
neox has joined 23:03:14
Tobias has joined 23:10:58
pprrks has joined 23:12:04
Tobias has left 23:27:59