I don’t think we have anything to talk about. the editor isn’t active currently
daniel
so instead of running through an empty agenda I’m just going to jump to AOB
daniel
does anyone have any AOB?
jonas’
I do not
Ge0rG
none here
moparisthebest
Nope
larma
No
daniel
ok. that was uneventful again
daniel
see you all next week
moparisthebest
See you then, thanks
jonas’
see ya
pprrkshas left
Ingolfhas left
Ingolfhas joined
pprrkshas joined
neoxhas left
neoxhas joined
neoxhas left
mdoschhas left
mdoschhas joined
marc0shas left
marc0shas joined
sonnyhas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
sonnyhas joined
Tobiashas left
Tobiashas joined
larma
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?
Tobiashas left
Tobiashas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
Ge0rG
Am I going to be hated by everyone if I veto until <origin-id/> is burned out with napalm?
larma
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
This is the XSF. You can do anything at the XSF! The the only limit is XEP-0001.
Ge0rG
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
probably not a lot
Tobiashas left
Tobiashas joined
larma
that's why I say I'm fine with getting rid of it 😉
tmolitor
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
that said, a disco feature indicating that the ids are sufficiently random (128bit of entropy, uuid, whatever) would be a better solution, imho...
larma
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 :)
marc0shas left
tmolitor
yeah...that one :)
tmolitor
was that written down anywhere?
Zash
disco is dead, MAM killed it :(
marc0shas joined
larma
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
There exists a perfect way to generate unique stanza ids
Zash
(stream-id, counter++)
Zash
(pass trough hash or HMAC or something)
Ingolfhas left
larma
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
larma: depends on the entropy of the salt ;)
marc0shas left
marc0shas joined
Ge0rG
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
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
Which problem does that solve, again?
larma
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
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
Collisions of what exactly?
daniel
Anything that references that id
daniel
Edits. Replies
daniel
Reactions
larma
In direct chats only, of course
daniel
Yes
daniel
And edits in muc
Tobiashas left
Ge0rG
Which only affects the user of the broken client when also using a modern client
Tobiashas joined
Ge0rG
But the broken client won't generate an adequate ID for referencing anyway
Tobiashas left
Tobiashas joined
larma
Yes, and thus the replying/reacting client should not allow the user to send replies/reactions to such message with broken id
Ge0rG
You need to send a message from pidgin, then edit it from a modern client
Ge0rG
Disabling a feature because of an opaque thing the user has no visibility of sounds like a bad idea
tmolitor
+1 for the <good-id/> element
daniel
> 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 ✎
Tobiashas left
daniel
> 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 ✏
Tobiashas joined
daniel
Origin ID is essentially good-id
tmolitor
yes, but with an additional id value that we could get rid of...
daniel
Why come up with a new element that does the same thing minus muc reflection
daniel
Then mandate message id==origin id
daniel
For the sender
Ge0rG
Are you actually disabling sophisticated features on messages without origin-id?
Ge0rG
daniel [20:37]:
> Then mandate message id==origin id
I've been asking for that since day 1
daniel
Me too
Ingolfhas joined
Tobiashas left
tmolitor
> Then mandate message id==origin id
that would be ideal, what is blocking that?
Tobiashas joined
Ge0rG
yaxim will generate sufficiently random IDs but not set origin-id
Ge0rG
tmolitor: the author
Tobiashas left
Tobiashas joined
tmolitor
on what basis?
Ge0rG
It's not technically required
Tobiashas left
Tobiashas joined
larma
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
Not technically requires, but definitely a best practice.✎
larma
Not technically required, but definitely a best practice. ✏
larma
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
I'm gonna block stanza id unless this must is in stanza id
tmolitor
> I'm gonna block stanza id unless this must is in stanza id
wait, what? what id are you referring to exactly?
marc0shas left
marc0shas joined
daniel
The xep
marc0shas left
marc0shas joined
daniel
I think the only reason it's not in the xep is that it's slightly complicated to do in smack
larma
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
Can't you just accept any ID with more than four characters and be done?
daniel
> 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
We could just remove origin id entirely. But it seems fairly well established for a good-id replacement
Zash
<good-id/> meaning that <message id=good> ?
Ge0rG
And you have an excuse to block out perfectly working clients from modern features
daniel
> <good-id/> meaning that <message id=good> ?
Yes
marc0shas left
marc0shas joined
Zash
Sure would help against my feeling that modern XMPP is full of redundant duplicated IDs and timestamps and also redundancy
Ge0rG
Zash: also duplicate information
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
marc0shas left
Tobiashas left
marc0shas joined
Tobiashas joined
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
marc0shas left
marc0shas joined
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
pprrkshas left
marc0shas left
marc0shas joined
pprrkshas joined
tmolitor
> I'm gonna block stanza id unless this must is in stanza id
+1 for this MUST