XSF Discussion - 2019-08-13

pep.: what's the rationale for https://github.com/xsf/xeps/pull/805

Ge0rG: the idea was as follows:

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.

Yes.

Ah, and `pubsub#rsm` is to tell that this is RSM on top of pubsub.

exactly

so the other one will be `http://jabber.org/protocol/disco#items#rsm`

and then `http://jabber.org/protocol/disco#items#rsm#order_by`?

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.”

So that section should be rewritten in terms of adding a `${otherprotocol}#rsm` feature.

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.

Other suggestions included subfeatures.

ralphm: Yes, I was aware of that one, at least ;)

I think that'd be overengineering.

I am also not sure if the current suboptimal way of discovering support by a "using protocol" is much of an issue in practice.

Technically, the proposed syntax is also a kind of sub-feature, but without an explicit structure.

I have no idea of that.

Ge0rG: indeed, less invasive.

There is probably a break-even point on the required bytes somewhere.

But the overhead of introducing actual sub-features in the XML schema dwarfs it all

Well, I'd be more concerned in complexity.

complexity is part of that overhead.

yes

I meant compared to byte-count.

The PR mentions MAM vs. PubSub. That might be a better contrast.

MAM requires RSM tho, so RSM support would be implied

Especially for MIX. Although MAM requires RSM.

with MIX you end up having disco#items again.

Right, so having http://jabber.org/protocol/disco#rsm and http://jabber.org/protocol/pubsub#rsm might be good enough here.

http://jabber.org/protocol/disco#items#rsm

Well, I'd do my suggestion.

It doesn't make any sense for info anyway.

Also, having # show up twice is not great, IMO.

#items+rsm ? 🙂

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.

And if you retrieve a node's info you could still see the rsm feature on it, maybe.

Also, if you just try it, then you can cache that support.

(hence my original question of it actually being needed)

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?

I'd also prefer a "+" over a "#"

but if this isn't bikeshedding, then nothing is.

➕ maybe?

:p

Kev: there are very very many Emoji where you are coming from.

It hints more at the combination than #, but yeah, the bike shed should be painted $(shuf -n 1 < colors.txt)

et tu brute

Kev: I'm not sure why you think you are funny.

It's not meant to be funny.

I'm sticking with my suggestions for consistency with existing features for the respective protocols.

I'm hoping over time it'll piss everyone off enough that they decide fallback is a bad idea.

Kev: can you send another one?

Kev: in that case you should use a realistic fallback

Kev: but I suppose you aren't because then people, including you, might realize that it's useful after all.

Wait, fallback? What context did I miss?

Fallback for reactions.

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.

I hope that this was an accurate summary.

Well, I did offer to write some prose, back when I had a few more cycles, but the offer was ignored AFAICR.

Kev: this is a very generic statement. Are you speaking of your message in the Message Reactions thread on standards?

I still have to read the whole thread (vacation), but had assumed it would be related to References.

ralphm: it is.

Ge0rG: but doesn't use the References protocol, right?

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.

ralphm: because there is no References protocol to... you know... reference messages.

If you say that XEP-0372 needs work, then I agree.

ralphm: I think that it's too ambitious to ever become useful.

Other issues are handling these various things in archives and summary counts, as also discussed at the summit.

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.

it would be awesome if the XSF had some kind of "General Direction of the Protocol Development" whitepaper

ralphm: but does it make sense to use the same mechanism for all of them?

and if it does, who is going to define that mechanism, and when?

and what do we do with proto-XEPs that need some kind of referencing mechanism until we got that sorted out?

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.

Ge0rG, like a vision statement?

Zash: yes!

Ge0rG: to me, you should accept proto XEPs in the usual sense of 'yeah, we need something like this'.

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"

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.

Ge0rG, a high level vision statement and a low level compliance suite?

Zash: the compliance suite is for those who implement, not for those who write XEPs

a low-level technical design vision for XEP authors

ralphm: yes.

Other approaches previously have been setting up SIGs, where the goal was something like "figure out Jingle".

https://xmpp.org/extensions/xep-0134.html and https://xmpp.org/extensions/xep-0143.html exist

ralphm: I fully agree that we need a concerted effort from Board and Council.

Zash: 0134 is kind of the high-level vision statement.

I think those XEPs are great, but they don't give direction on what kind of features we'd like to see developed.

Just when you are, how to go about it.

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.

Yeah, a coherent vision for the future would be nice

Tricky to do in a understaffed volonteer organization tho

Indeed.

And this is not unique to the XSF.

Maybe not quite the thing a standards org does

This is why the IETF has WGs, W3C caused WHATWG, etc.

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.

-need

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.

Other than that the name is misleading, I don't see why 367 couldn't solve the second case generically - reactions, corrections, etc.

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)"

Nod

That also helps with the goal of composition

And archive cleverness.

Yes

Then we should also have mims depend on that instead of references, maybe.

mims?

Sims

XEP-0385

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

Huh?

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).

Although for un-reacting, I think pushing an unattach type thing makes much more sense than correcting.

Slightly relatedly, I eventually want more broad edits, not just last message

ralphm: Indeed.

Kev: if you unattach a message, it becomes stand alone? That doesn't make much sense

At least not for reactions

No, it negates the reaction.

I think you'd want some generic retraction indicator

ralphm: I've always wondered who added that pointless restriction to the XEP 😉

<attach-to id><reaction>💯</></> <unattach id><reaction>💯</></>

So a message that has unattach is treated as no longer valid at all?

Wait, that would be a delta protocol on a sub message base. Can we please avoid that?

Ge0rG: We'll have that anyway.

ralphm: The message containing <unnattach>'s only purpose would be to undo a previous attach.

Kev: but you don't want to undo the attaching, you want to remove the payload.

s/unattach/remove-attachment/, then. The stanza name isn't particularly important to me.

Which is much like replacing the old payload with a new, empty, one.

You could technically use LMC to remove a message by updating it with an empty one.

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.

Kev: stanza names end up defining the semantics of the protocol.

Ge0rG: Yes, that's what I'd like to avoid.

(Using LMC for references)

For reactions?

Kev [17:33]: > Ge0rG: Yes, that's what I'd like to avoid. The question is, why?

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.

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.

(And track that across clients)

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?

Yes.

our archive and everything around our transport is designed around individual messages. I'm not sure we want to change _that_

Kev: this is what the current reactions XEP already covers.

proto-XEP, of course.

It's 367 (or whatever we use as the wrapper) that needs it.

But how are you going to resolve that with non-attached messages?

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)"

What if you want to attach multiple different things to X?

How do I know which one you unattach. Are you saying that I need to compare all the payloads and remove the closest match?

Well, compare the exact match, yes.

How is that a better design than comparing the UUID of the last attachment?

What if your unattach removes a payload that I haven't yet seen being added, and the add comes later from MAM?

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.

so you are speaking about a forklift protocol upgrade

(I'm just trying to understand the rationale here)

I mean, our messages and their related things become more and more of an implicit DAG with different kinds of edges.

But I can't see how referencing earlier content by its content is going to help.

I'm all in for making the DAG relationships all explicit and based on the same foundation.

And then we have message threads, which are also a DAG, which is maybe strictly orthogonal ;)

Is there even such a thing like orthogonality between DAGs?

I'm not sure threads are orthogonal.

I was thinking about this yesterday(?), and maybe they're just references.

Maybe.

Or attachments :)

Ever used Microsoft Teams?

I think they're definitely not <thread/>, at least.

I haven't, similar to Slack/Discord?

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

no idea if threads are also reordered by recentness.

Because the other parts of it were so unbearable that I dropped it almost immediately.

Different from Slack then, with Slack (last I tried), you kinda promote a message into a thread.

The thread UX of Slack is just horrible.

Nobody I've met was actually using it.

Anyway, back to our DAGs.

It's still useful, but you have to suffer through it rather than it supporting you.

Let me introduce you to places that not only use it, but enforce it

(or try to)

Please don't.

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?

in other words: if you fetch a message from MAM, do you want the whole thread, with all reactions? only the parent branch? nothing?

I'm not sure that I necessarily buy that threads are necessarily a(n unspecialised) DAG.

But that aside, the fetching from MAM+ does make using the same mechanism for threads and other attachments potentially sticky.

Kev: how would you model threads?

(this whole discussion is probably moot anyway, because nobody wants threads)

Kev: "potentially sticky"?

Probably a bad idea.

One might want to do a MAM query on a specific thread. Otherwise I'd just threat it as just another attribute.

so now we need a new edge attribute "should be included in MAM+ responses"

or maybe two: "parent should be included in MAM+ responses" and "child should be included in MAM+ responses"

This hurts my brain.

because an emoji reaction should obviously be returned when you query for the parent message.

Zash: this stuff is not easy

"sacrifice a child to proceed fetching MAM"

Infinite whiteboard required

Zash: the infinite whiteboard is a DAG

unless you draw circles.

The reactions aren't really a DAG, though.

Ge0rG: well, at FOSDEM we discussed having summaries (counts) and having reactions as a dimension

11-dimentional whiteboard for drawing DAGs

As ralphm says.

Array of map of array of maps in seven dimentions?

ralphm: I vaguely remember that, yeah.

Kev: if you allow changing reactions, they become a DAG

Kev: you might remember my fierce argumentation for allowing LMC to work on a DAG and not as a star.

Why not have edits as a dimension, too?

Sadly, I need to concentrate on work for a bit.

ralphm: ideally, edits should be a one-dimensional linked list.

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.

I.e. if you want to have a feature set that is similar to Slack and Whatsapp.

Kev: maybe we should schedule a time to pick this up?

Happy to, but I don't have cycles at this minute.

I spent more than I probably should have, already.

Zash: dizzy yet?

> 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

Hah, I read "collecting"

> 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

pep.: so I can ignore your remark?

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

ralphm: depends, do you think you're doing enough pubsub already? :p

Apart from being one of the authors of the spec and having things like ikDisplay? Probably not.

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.

Maybe I should write an email with the various topics we touched upon today.

Do we not already have 32 avatar xeps and 42 bookmark xeps?

With conversion xeps

I'm sure one more reference xep wouldn't harm

We also had 3 or 4 pubsub specs, 3 service discovery specs, various session initiation approaches.

Sure, we can get rid of those that are no use later on

Eventually rough consensus and running code prevails.

And this particular problem domain is hard.

The individual parts might look easy, and hopefully the protocols are going to be simple and composable.

In the meantime I think we should give some slack to the reaction protoXEP

That's something that they need and they're not gonna wait that we grow rainbows and references XEPs

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.

And then mold things properly.

Yeah

I'm not sure who 'they' are and how their needs need to be addressed, but yeah, standards bodies are not necessarily fast.

Most importantly because this is volunteer work and/or work priorities might not align.

It very much aligns when somebody has an agenda. We should just try to nerdsnipe the right people

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.

Haven't heard of the authors?

Have you used dino?

No

Here you go

It is entirely possible I missed something.

But how should I know that these people are associated with that project?

What is larma.de, for example? I did try to find out, you know?

Dunno, I meet them on a regular basis (conferences)

I should attend one, indeed, and meet them.

Next years summit?

At least. Did you sign up already?

Not yet, but plan to (have to check with work stuff first)

But maybe earlier. .nl isn't that far from .de.

I still have CCCamp, Stockholm Sprint and C3 on my list of conferences for this year 🙂

Gotta sleep now, but will attempt to catch up tomorrow.

i can imagine us doing another sprint in between sweden and ccc though

maybe around november like last year

Maybe Guus, intosi, and I should set something up in the Eindhoven region.