pep.: what's the rationale for https://github.com/xsf/xeps/pull/805
adityaborikarhas left
adityaborikarhas joined
Danielhas left
Danielhas joined
Zashhas left
karoshihas left
karoshihas joined
murabitohas joined
Zashhas joined
pdurbinhas joined
Nekithas left
ralphm
Ge0rG: the idea was as follows:
pdurbinhas left
ralphm
The way you discover support for RSM now, you can't tell if it is the pubsub service that supports RSM or Disco Items requests.
Ge0rG
Yes.
Ge0rG
Ah, and `pubsub#rsm` is to tell that this is RSM on top of pubsub.
jonas’
exactly
Syndacehas left
Ge0rG
so the other one will be `http://jabber.org/protocol/disco#items#rsm`
Ge0rG
and then `http://jabber.org/protocol/disco#items#rsm#order_by`?
ralphm
XEP-0059 explicitly writes:
“Note: Even if a responding entity understands the result set management protocol, its support for result set management in the context of any given "using protocol" is OPTIONAL (e.g., an implementation could support it in the context of the 'jabber:iq:search' namespace but not in the context of the 'http://jabber.org/protocol/disco#items' namespace). Currently the only way for a requesting entity to determine if a responding entity supports result set management in the context of a given "using protocol" is to include result set management extensions in its request. If the responding entity does not include result set management extensions in its response, then the requesting entity SHOULD NOT include such extensions in future requests wrapped by the "using protocol" namespace.”
Ge0rG
So that section should be rewritten in terms of adding a `${otherprotocol}#rsm` feature.
ralphm
So there was a bit of discussion on how to attempt to fix this, and providing an explicit disco feature for RSM-within-pubsub was the easiest I could come up with.
ralphm
Other suggestions included subfeatures.
Ge0rG
ralphm: Yes, I was aware of that one, at least ;)
Syndacehas joined
ralphm
I think that'd be overengineering.
ralphm
I am also not sure if the current suboptimal way of discovering support by a "using protocol" is much of an issue in practice.
Nekithas joined
Ge0rG
Technically, the proposed syntax is also a kind of sub-feature, but without an explicit structure.
Ge0rG
I have no idea of that.
ralphm
Ge0rG: indeed, less invasive.
Ge0rG
There is probably a break-even point on the required bytes somewhere.
Ge0rG
But the overhead of introducing actual sub-features in the XML schema dwarfs it all
ralphm
Well, I'd be more concerned in complexity.
madhur.garghas left
Ge0rG
complexity is part of that overhead.
ralphm
yes
ralphm
I meant compared to byte-count.
ralphm
The PR mentions MAM vs. PubSub. That might be a better contrast.
Zash
MAM requires RSM tho, so RSM support would be implied
ralphm
Especially for MIX. Although MAM requires RSM.
Ge0rG
with MIX you end up having disco#items again.
ralphm
Right, so having http://jabber.org/protocol/disco#rsm and http://jabber.org/protocol/pubsub#rsm might be good enough here.
Ge0rG
http://jabber.org/protocol/disco#items#rsm
ralphm
Well, I'd do my suggestion.
j.rhas left
j.rhas joined
ralphm
It doesn't make any sense for info anyway.
ralphm
Also, having # show up twice is not great, IMO.
Zash
#items+rsm ? 🙂
ralphm
In any case it is a bit of an optimization. I think collection nodes are rare in practice, so retrieving items from the root node is as well.
ralphm
And if you retrieve a node's info you could still see the rsm feature on it, maybe.
ralphm
Also, if you just try it, then you can cache that support.
Nekithas left
Nekithas joined
ralphm
(hence my original question of it actually being needed)
Zash
Hmmmm, I think someone mentioned having the server send caps hash of known local services, components etc at some early point. Did something come of that?
Ge0rG
I'd also prefer a "+" over a "#"
Ge0rG
but if this isn't bikeshedding, then nothing is.
Kev
➕ maybe?
Kev
:p
Ge0rG
Kev: there are very very many Emoji where you are coming from.
madhur.garghas joined
Zash
It hints more at the combination than #, but yeah, the bike shed should be painted $(shuf -n 1 < colors.txt)
Guus
et tu brute
Kevreacts to Ge0rG's message
> Kev: there are very very many Emoji where you are coming from.
with a 😮
j.rhas left
Ge0rG
Kev: I'm not sure why you think you are funny.
Kev
It's not meant to be funny.
ralphm
I'm sticking with my suggestions for consistency with existing features for the respective protocols.
Kev
I'm hoping over time it'll piss everyone off enough that they decide fallback is a bad idea.
ralphm
Kev: can you send another one?
Ge0rG
Kev: in that case you should use a realistic fallback
valohas left
Ge0rG
Kev: but I suppose you aren't because then people, including you, might realize that it's useful after all.
Zash
Wait, fallback? What context did I miss?
ralphm
Fallback for reactions.
Ge0rG
Kev: I've also had a nice chat with the authors of Reactions last weekend, and they were very sad because of the unclear perspectives for "a way to reference messages". As they understood Sam, he disagrees with attach-to being usable for reactions, because reactions are combining multiple reactions from different people, which attach-to isn't meant to do. References obviously isn't fit for the use case and it will take an unknown time to make it fit, and even if they use attach-to now, having to migrate from attach-to to some other official message-referencing scheme in a timeframe of the next five years doesn't look very attractive compared to implementing the custom reactions reference scheme now and to migrate from it to whatever Council will make The Right Thing Some Day In The Future.
Ge0rG
I hope that this was an accurate summary.
Kev
Well, I did offer to write some prose, back when I had a few more cycles, but the offer was ignored AFAICR.
Ge0rG
Kev: this is a very generic statement. Are you speaking of your message in the Message Reactions thread on standards?
ralphm
I still have to read the whole thread (vacation), but had assumed it would be related to References.
Ge0rG
ralphm: it is.
valohas joined
ralphm
Ge0rG: but doesn't use the References protocol, right?
Ge0rG
I think that semantically, Reactions are very much attach-to, and Receipts are more-or-less attach-to, and LMC are not attach-to at all.
Ge0rG
ralphm: because there is no References protocol to... you know... reference messages.
ralphm
If you say that XEP-0372 needs work, then I agree.
Ge0rG
ralphm: I think that it's too ambitious to ever become useful.
ralphm
Other issues are handling these various things in archives and summary counts, as also discussed at the summit.
adityaborikarhas left
adityaborikarhas joined
ralphm
Ge0rG: if we want to figure out how to do Slack-style reactions, people references, URL references (including retreive and display a card?), edits, as well as receipts, then it makes sense to compare all of them.
Ge0rG
it would be awesome if the XSF had some kind of "General Direction of the Protocol Development" whitepaper
wurstsalathas left
wurstsalathas joined
Ge0rG
ralphm: but does it make sense to use the same mechanism for all of them?
Ge0rG
and if it does, who is going to define that mechanism, and when?
Ge0rG
and what do we do with proto-XEPs that need some kind of referencing mechanism until we got that sorted out?
ralphm
Well, I am offering to help make a consistent proposal. It would be good to have one or two people join me, similar to how, e.g., pubsub was hashed out eventually.
Zash
Ge0rG, like a vision statement?
Ge0rG
Zash: yes!
ralphm
Ge0rG: to me, you should accept proto XEPs in the usual sense of 'yeah, we need something like this'.
Ge0rG
Zash: a very high-level one, with things like "Thin clients, smart servers", and a low-level one, with things like "use 0372 if you want to reference one message from another"
ralphm
There's been some discussion on having an XSF Roadmap. Having this on it would make sense, but I think defining a Roadmap should be a concerted effort between Board and Council.
Zash
Ge0rG, a high level vision statement and a low level compliance suite?
Ge0rG
Zash: the compliance suite is for those who implement, not for those who write XEPs
Ge0rG
a low-level technical design vision for XEP authors
Ge0rG
ralphm: yes.
ralphm
Other approaches previously have been setting up SIGs, where the goal was something like "figure out Jingle".
Zash
https://xmpp.org/extensions/xep-0134.html and https://xmpp.org/extensions/xep-0143.html exist
rionhas left
Ge0rG
ralphm: I fully agree that we need a concerted effort from Board and Council.
Ge0rG
Zash: 0134 is kind of the high-level vision statement.
ralphm
I think those XEPs are great, but they don't give direction on what kind of features we'd like to see developed.
ralphm
Just when you are, how to go about it.
ralphm
And has been a bit of a rough spot forever. We've usually acted on stuff being submitted. Council generally doesn't *drive* protocol development.
Zash
Yeah, a coherent vision for the future would be nice
Nekithas left
Zash
Tricky to do in a understaffed volonteer organization tho
ralphm
Indeed.
Nekithas joined
ralphm
And this is not unique to the XSF.
Zash
Maybe not quite the thing a standards org does
ralphm
This is why the IETF has WGs, W3C caused WHATWG, etc.
j.rhas joined
ralphm
I see many areas that would need benefit from a concerted effort, probably initially by a small set of people: richer messaging (as above), voice/video calling in dynamic multi-client situations (read mobile clients going to sleep), MIX.
ralphm
-need
Kev
re: references, there's two types of references, both of which were meant to be in the References XEP. There's where you make a message reference a thing, and where you reference a message to add additional data. It still kinda makes sense to me to have them together, but it is not a hill for me to die on at all to split the two things out.
Kev
Other than that the name is misleading, I don't see why 367 couldn't solve the second case generically - reactions, corrections, etc.
Kev
And one of the things that 367 might do is to attach a Reference, so e.g. a server could annotate a message to say "This message is about This Thing (e.g. a server prefetching image URLs for previewing)"
ralphm
Nod
ralphm
That also helps with the goal of composition
Kev
And archive cleverness.
ralphm
Yes
j.rhas left
ralphm
Then we should also have mims depend on that instead of references, maybe.
Kev
mims?
ralphm
Sims
ralphm
XEP-0385
Ge0rG
Kev: one issue with 0367 is that conceptually, we'd have to stuff the payload inside of the attach-to element, not side by side with it. Otherwise, you can't distinguish which reference is which in a corrected reaction
ralphm
Huh?
Kev
Ge0rG: I would expect that the thing that's being attached/updated with would be inside the attach-to (although possibly updating 367 to not call it attach-to would make sense).
Kev
Although for un-reacting, I think pushing an unattach type thing makes much more sense than correcting.
ralphm
Slightly relatedly, I eventually want more broad edits, not just last message
Kev
ralphm: Indeed.
Ge0rG
Kev: if you unattach a message, it becomes stand alone? That doesn't make much sense
Ge0rG
At least not for reactions
Kev
No, it negates the reaction.
ralphm
I think you'd want some generic retraction indicator
Ge0rG
ralphm: I've always wondered who added that pointless restriction to the XEP 😉
So a message that has unattach is treated as no longer valid at all?
Ge0rG
Wait, that would be a delta protocol on a sub message base. Can we please avoid that?
Kev
Ge0rG: We'll have that anyway.
Kev
ralphm: The message containing <unnattach>'s only purpose would be to undo a previous attach.
Ge0rG
Kev: but you don't want to undo the attaching, you want to remove the payload.
j.rhas joined
Kev
s/unattach/remove-attachment/, then. The stanza name isn't particularly important to me.
Ge0rG
Which is much like replacing the old payload with a new, empty, one.
Ge0rG
You could technically use LMC to remove a message by updating it with an empty one.
Kev
Well, this is attaching things to a stanza, it's not updating the stanza per say. So I think unattaching makes sense, but I don't think arguing semantics of the English is particularly useful.
Ge0rG
Kev: stanza names end up defining the semantics of the protocol.
Kev
Ge0rG: Yes, that's what I'd like to avoid.
Kev
(Using LMC for references)
adityaborikarhas left
Ge0rG
For reactions?
Ge0rG
Kev [17:33]:
> Ge0rG: Yes, that's what I'd like to avoid.
The question is, why?
Kev
Because it requires tracking not just the data, but also the transport of the data, which is just another layer of indirection we're not going to want in the archive.
Kev
And similarly, it means that on the sender side we have to track how we sent out each datum, rather than just the data that were sent.
Kev
(And track that across clients)
wurstsalathas left
Ge0rG
Kev: so you are saying, we should be able to change a reaction to a message without knowing the ID of the previous reaction, if any?
wurstsalathas joined
Kev
Yes.
Ge0rG
our archive and everything around our transport is designed around individual messages. I'm not sure we want to change _that_
Ge0rG
Kev: this is what the current reactions XEP already covers.
Ge0rG
proto-XEP, of course.
Kev
It's 367 (or whatever we use as the wrapper) that needs it.
Ge0rG
But how are you going to resolve that with non-attached messages?
wurstsalathas left
wurstsalathas joined
Ge0rG
It's obvious for "This is a change of the reaction to message X" vs. "This is a correction of reaction Y (which was attached to X, but I don't need to say)"
Ge0rG
What if you want to attach multiple different things to X?
adityaborikarhas joined
Ge0rG
How do I know which one you unattach. Are you saying that I need to compare all the payloads and remove the closest match?
pdurbinhas joined
Kev
Well, compare the exact match, yes.
Ge0rG
How is that a better design than comparing the UUID of the last attachment?
Ge0rG
What if your unattach removes a payload that I haven't yet seen being added, and the add comes later from MAM?
sezuanhas left
Kev
You'd be able to ignore the unattach for anything you're not rendering, and when you get the message from the archive you'd also get the attachment summary.
Ge0rG
so you are speaking about a forklift protocol upgrade
Ge0rG
(I'm just trying to understand the rationale here)
Ge0rG
I mean, our messages and their related things become more and more of an implicit DAG with different kinds of edges.
Ge0rG
But I can't see how referencing earlier content by its content is going to help.
Ge0rG
I'm all in for making the DAG relationships all explicit and based on the same foundation.
Ge0rG
And then we have message threads, which are also a DAG, which is maybe strictly orthogonal ;)
Lancehas joined
Ge0rG
Is there even such a thing like orthogonality between DAGs?
Kev
I'm not sure threads are orthogonal.
Kev
I was thinking about this yesterday(?), and maybe they're just references.
Ge0rG
Maybe.
Kev
Or attachments :)
lovetoxhas joined
Ge0rG
Ever used Microsoft Teams?
Kev
I think they're definitely not <thread/>, at least.
Kev
I haven't, similar to Slack/Discord?
Ge0rG
Kind of, but it's very slow, and it has explicit thread rendering, and the UX for threads isn't actually too bad, because there is an input box under _each_ message, and then what you type is rendered in that place of the thread
Ge0rG
no idea if threads are also reordered by recentness.
Nekithas left
Nekithas joined
Ge0rG
Because the other parts of it were so unbearable that I dropped it almost immediately.
Kev
Different from Slack then, with Slack (last I tried), you kinda promote a message into a thread.
Ge0rG
The thread UX of Slack is just horrible.
Ge0rG
Nobody I've met was actually using it.
Ge0rG
Anyway, back to our DAGs.
Kev
It's still useful, but you have to suffer through it rather than it supporting you.
MattJ
Let me introduce you to places that not only use it, but enforce it
MattJ
(or try to)
Kev
Please don't.
Ge0rG
If a thread is a DAG, and all the non-text things that belong to a message (receipts, reactions, etc) are a DAG, does it really make sense to merge those DAGs?
Ge0rG
in other words: if you fetch a message from MAM, do you want the whole thread, with all reactions? only the parent branch? nothing?
Kev
I'm not sure that I necessarily buy that threads are necessarily a(n unspecialised) DAG.
Kev
But that aside, the fetching from MAM+ does make using the same mechanism for threads and other attachments potentially sticky.
Ge0rG
Kev: how would you model threads?
pdurbinhas left
Ge0rG
(this whole discussion is probably moot anyway, because nobody wants threads)
Ge0rG
Kev: "potentially sticky"?
Kev
Probably a bad idea.
ralphm
One might want to do a MAM query on a specific thread. Otherwise I'd just threat it as just another attribute.
Ge0rG
so now we need a new edge attribute "should be included in MAM+ responses"
Ge0rG
or maybe two: "parent should be included in MAM+ responses" and "child should be included in MAM+ responses"
Zash
This hurts my brain.
Ge0rG
because an emoji reaction should obviously be returned when you query for the parent message.
ralphm
Zash: this stuff is not easy
Ge0rG
"sacrifice a child to proceed fetching MAM"
Zash
Infinite whiteboard required
Ge0rG
Zash: the infinite whiteboard is a DAG
Ge0rG
unless you draw circles.
Kev
The reactions aren't really a DAG, though.
ralphm
Ge0rG: well, at FOSDEM we discussed having summaries (counts) and having reactions as a dimension
Zash
11-dimentional whiteboard for drawing DAGs
Kev
As ralphm says.
Zash
Array of map of array of maps in seven dimentions?
Ge0rG
ralphm: I vaguely remember that, yeah.
Ge0rG
Kev: if you allow changing reactions, they become a DAG
Ge0rG
Kev: you might remember my fierce argumentation for allowing LMC to work on a DAG and not as a star.
ralphm
Why not have edits as a dimension, too?
wojtekhas joined
Kev
Sadly, I need to concentrate on work for a bit.
Ge0rG
ralphm: ideally, edits should be a one-dimensional linked list.
wojtekhas left
ralphm
I think a MAM archive will eventually need a few dimensions: edits, reactions, other attachments. And then there are summaries. And something we haven't really touched upon yet today: read/received per group participant.
ralphm
I.e. if you want to have a feature set that is similar to Slack and Whatsapp.
ralphm
Kev: maybe we should schedule a time to pick this up?
Kev
Happy to, but I don't have cycles at this minute.
Kev
I spent more than I probably should have, already.
ralphm
Zash: dizzy yet?
Yagizahas left
Zashwandered away to make food
Lancehas left
j.rhas left
rionhas joined
j.rhas joined
Nekithas left
Nekithas joined
Wojtekhas joined
Wojtekhas left
alameyohas left
j.rhas left
Nekithas left
Chobbeshas joined
pdurbinhas joined
Chobbeshas left
sezuanhas joined
pdurbinhas left
j.rhas joined
UsLhas left
Mikaelahas left
Mikaelahas joined
Mikaelahas left
Mikaelahas joined
Mikaelahas left
Mikaelahas joined
valohas left
UsLhas joined
Mikaelahas left
Mikaelahas joined
Mikaelahas left
Mikaelahas joined
Mikaelahas left
valohas joined
Mikaelahas joined
Mikaelahas left
Mikaelahas joined
j.rhas left
Mikaelahas left
evehas left
Mikaelahas joined
Mikaelahas left
Mikaelahas joined
Mikaelahas left
Mikaelahas joined
Mikaelahas left
Mikaelahas joined
wurstsalathas left
Allohas left
Allohas joined
xalekhas left
xalekhas joined
evehas joined
Wojtekhas joined
wurstsalathas joined
adityaborikarhas left
adityaborikarhas joined
evehas left
evehas joined
j.rhas joined
Wojtekhas left
davidhas left
valohas left
sezuanhas left
wojtekhas joined
Danielhas left
Danielhas joined
Nekithas joined
valohas joined
Danielhas left
Danielhas joined
LNJhas left
LNJhas joined
pdurbinhas joined
Tobiashas left
davidhas joined
pdurbinhas left
j.rhas left
j.rhas joined
j.rhas left
j.rhas joined
Nekithas left
Nekithas joined
andyhas left
remkohas left
pep.
> ralphm> In any case it is a bit of an optimization. I think collection nodes are rare in practice, so retrieving items from the root node is as well.
Apparently you're not doing pubsub enough
pep.
Hah, I read "collecting"
pep.
> Ge0rG> a very high-level one, with things like "Thin clients, smart servers", and a low-level one, with things like "use 0372 if you want to reference one message from another"
Careful about the e2ee triad
wojtekhas left
ralphm
pep.: so I can ignore your remark?
pep.
Kev: the thing with 367 is that what council is trying to turn it into is not what the author intended for it, as I understand it. It'd be great to have a statement from him + change in the XEP, or council saying "fk it, we're taking over" or sth
alameyohas joined
pep.
ralphm: depends, do you think you're doing enough pubsub already? :p
ralphm
Apart from being one of the authors of the spec and having things like ikDisplay? Probably not.
ralphm
pep.: And as for XEP-0367, I understand that issue, but this can go two ways: the consensus is to change the spec to address various concerns as raised today, or someone introduces another, similar spec that comes closer. The problem is that there are so many things coming together here that something has to give.
ralphm
Maybe I should write an email with the various topics we touched upon today.
pep.
Do we not already have 32 avatar xeps and 42 bookmark xeps?
pep.
With conversion xeps
pep.
I'm sure one more reference xep wouldn't harm
ralphm
We also had 3 or 4 pubsub specs, 3 service discovery specs, various session initiation approaches.
pep.
Sure, we can get rid of those that are no use later on
ralphm
Eventually rough consensus and running code prevails.
ralphm
And this particular problem domain is hard.
ralphm
The individual parts might look easy, and hopefully the protocols are going to be simple and composable.
pep.
In the meantime I think we should give some slack to the reaction protoXEP
pep.
That's something that they need and they're not gonna wait that we grow rainbows and references XEPs
ralphm
As I said, I need to read the entire thread still, but the concept of reactions was discussed at the Summit and if I was on council I'd vote for accepting.
ralphm
And then mold things properly.
pep.
Yeah
ralphm
I'm not sure who 'they' are and how their needs need to be addressed, but yeah, standards bodies are not necessarily fast.
valohas left
ralphm
Most importantly because this is volunteer work and/or work priorities might not align.
j.rhas left
pep.
It very much aligns when somebody has an agenda. We should just try to nerdsnipe the right people
ralphm
I haven't even heard of the authors and the domain of their collective contact addresses (which is a concern the editors should look into), doesn't yield a website.
pep.
Haven't heard of the authors?
pep.
Have you used dino?
ralphm
No
pep.
Here you go
ralphm
It is entirely possible I missed something.
ralphm
But how should I know that these people are associated with that project?
ralphm
What is larma.de, for example? I did try to find out, you know?
pep.
Dunno, I meet them on a regular basis (conferences)
Guushas left
ralphm
I should attend one, indeed, and meet them.
larma
Next years summit?
Nekithas left
ralphm
At least. Did you sign up already?
j.rhas joined
larma
Not yet, but plan to (have to check with work stuff first)
ralphm
But maybe earlier. .nl isn't that far from .de.
LNJhas left
larma
I still have CCCamp, Stockholm Sprint and C3 on my list of conferences for this year 🙂
ralphm
Gotta sleep now, but will attempt to catch up tomorrow.
Daniel
i can imagine us doing another sprint in between sweden and ccc though
Daniel
maybe around november like last year
ralphm
Maybe Guus, intosi, and I should set something up in the Eindhoven region.