<div dir="ltr"><div>Heavy snipping. Not ignoring the other parts, just not answering them for now at least.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 6 Jan 2020 at 23:54, Marvin W <<a href="mailto:xmpp@larma.de">xmpp@larma.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 1/3/20 12:56 AM, Dave Cridland wrote:<br>> Sending 50+ likes for each message would be extraordinarily painful in<br>
> terms of bandwidth, and it's not unreasonable to assume that might<br>
> happen quite often.<br>
<br>
I agree that we want to have summarized reactions for chatrooms, but I<br>
am not that set on extending summarizing to all fastenings with the same<br>
concept. IMO, if we can't come up with an example where this counting is<br>
actually a good idea other than reactions, it shouldn't be part of<br>
fastening (the generic concept) but part of reactions (the only<br>
realization needing that kind of summary).<br>
<br></blockquote><div><br></div><div>It's not entirely clear to me that summarizing to a count (or multiple counts) actively does harm, though. Yes, the count (or one of them) is directly useful for Reactions and any similar lightweight interactions. But for cases where we need to (eventually) fetch everything, we have that covered as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> This is massively amplified by receipts - it's very useful to know if<br>
> anyone, or everyone, has seen a message, but in a large chatroom that's<br>
> a lot of receipts.<br>
> [...]<br>
> It may well be that Chat Markers don't make a suitable case for<br>
> fastening, and I'm fine with that.<br>
<br>
I don't think you can get the information that "everyone" in a larger<br>
group chat has seen a message, because you don't know what the<br>
recipient's clients actually do, they might just not support read<br>
receipts or have disabled them for privacy reasons. The only really<br>
sensible thing you can know, is if the group chat server received the<br>
message, and that's already given if you fetch it from MAM.<br>
<br></blockquote><div><br></div><div>There are cases where you know everyone has read the message, and there are cases where everyone has read the message but you don't know.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I haven't noticed that part, but it seems to be an issue in 422: if you<br>
want to have two fastenings of the same type at the same time, they<br>
can't have externals, because else you wouldn't know which external<br>
belongs to which fastening.<br></blockquote><div><br></div><div>This is an excellent point.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Shell fastenings are pretty useless, yes. But having them individually<br>
> listed would, i think, be worse - and we can already pull the complete<br>
> list of them if we need to. It's an additional round-trip, certainly,<br>
> but that's a penalty if you're encrypting everything.<br>
<br>
I was proposing to list the archive id of each fastening, not the<br>
content. The reason for this is that I don't want to be required to pull<br>
all fastenings every time there is a change for a message. If I have the<br>
archive id on all the fastenings, I can easily see which of those I<br>
already downloaded in the past/have in my local cache and only download<br>
the new ones.<br></blockquote><div><br></div><div>Ah, I think I understand your use-case, but I think it's also covered - especially with the additions we've already agreed.</div><div><br></div><div>You know the latest archive id for which you pulled the fastenings - that's in the (new to MAMFC) latest tag in the MAM <fin/>. You've asked for the archive id (and some other details, all of which I've agreed) to be included in the latest fastening information as well, which optimises this further.</div><div><br></div><div>You can ask for just fastenings for a message (MAMFC current), for a particular fastening type (agreed change earlier in this thread) and filter for messages after an archive id (RSM+MAM current).</div><div><br></div><div>So I think this accomplishes everything you're asking for, except that obtaining the full fastenings for a message always requires a round-trip (unless you're not trying to use MAMFC at all, in effect, and ask for everything).</div><div><br></div><div>Note however that including only the latest fastening in detail means it's also easy to look at the MAMFC summary and decide whether there could be new fastenings to fetch, as well (especially with the additions you've suggested).</div><div><br></div><div>So this *is* adding a RTT per message which has new fastenings *if* you care about that fastening summary, but including all the fastenings into each result is mere collation which the client can do itself just by asking for everything anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Yes, encryption makes some things harder. I'd still like to make things<br>
with encryption as good as possible and not improve the unencrypted case<br>
on cost of the encrypted case just because the encrypted case can never<br>
be perfect.<br></blockquote><div><br></div><div>That's not the intent. The intent is not to assume we always use whole stanza encryption, and sometimes use either content-only encryption or even no E2EE at all. Following from that (and I note the latter two cases are equivalent for MAMFC I think), we aim for graceful degradation as the server loses visibility on the data.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I'm not saying that having per-fastening code in every server is slow<br>
> just because there's a lag to them updating, I'm saying it'll be slow<br>
> because you'll have several round-trips between server developers and<br>
> client developers as the feature is developed and it'll take literal<br>
> years for each one to become stably deployed, as well as creating a vast<br>
> amount of workload for the XSF and its participants.<br>
<br>
How is this worse than having a "generic" feature that works good for<br>
reactions and edits, but doesn't work for future extensions and thus<br>
will need to be updated every now and then, having the same cycle you<br>
described but at the same time may break all the existing infrastructure<br>
for previous fastenings.<br>
<br></blockquote><div><br></div><div>If MAMFC ends up that way - and I don't think it will - then it's started with a reasonably solid solution for all the cases of fastenings we've identified and then needed additions subsequently, rather than started with a suboptimal solution from the outset. In the worst case, the long-term effort ends up equal.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Another issue that I noticed: you are relying on the thing you call<br>
'fastening summary'. What happens if we allow for more complex reactions<br>
that can't be put as an attribute, but are realized as an child element,<br>
like custom images. This was already expressed as a desired feature here<br>
on the list and is easy to realize from the reactions proposal in the<br>
inbox, but hard using the "hidden" reactions proposal in your (Proto)XEPs.<br>
<br></blockquote><div><br></div><div>Isn't this trivial? Just have an attribute in the fastening itself which is a hash (or unique, stable identifier) of the custom image, and it'll summarize neatly.</div><div><br></div><div>Perhaps this is where our mutual confusion lies? I see the combination of XEP-0422, this specification, and future fastening design as a largely green field thing, and we'd design fastenings such that the rules in MAMFC provide useful results for them, rather than designing anything we want without regard to the status quo and then having to adjust MAMFC to fit?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> You're expecting servers to track individual authorisation of likes<br>
> within chatrooms?<br>
<br>
I'd expect clients to track reactions in group chats by occupant id<br>
(XEP-0421) instead of senders nickname. This was already teased in the<br>
reactions proto xep<br>
<<a href="https://xmpp.org/extensions/inbox/reactions.html#acceptable-reactions" rel="noreferrer" target="_blank">https://xmpp.org/extensions/inbox/reactions.html#acceptable-reactions</a>>,<br>
although occupant ids weren't a thing back then.<br>
Thus I'd expect servers to do the very same. For edits, that's even a<br>
stronger case and I would hope for a server at some point to just filter<br>
out invalid edits. Even if you don't make that part of the XEP it would<br>
be a sensible idea for servers to do that to reduce load for both server<br>
and clients at no practical cost (as clients would have to filter them<br>
out anyway).<br>
<br></blockquote><div><br></div><div>Well, if the chatroom does this then fine, but I think as long as we handle XEP-0421 and include a count per-user as well as total we're covered here in terms of the UX.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> OK, so you're saying that the client sees there are claps, and can<br>
> retrieve all the clap fastenings and process them locally.<br>
<br>
I wasn't talking about the client retrieving all fastenings, in this<br>
example the <applied> elements are directly in the <result>, the same as<br>
in your ProtoXEP. It doesn't need another round trip to request anything.<br>
<br></blockquote><div><br></div><div>Right, but this represents no difference to doing no collation at all, and just including these directly in MAM. Which we don't want to do because it becomes painful.</div><div><br></div><div>Or, we end up with unbounded length stanzas, which is also painful.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Although MAMFC will work, it just may require an additional round-trip<br>
> for this contrived case.<br>
<br>
As mentioned above, I see the risk of the summarizing - if done wrong -<br>
to cause the client to be unable to see that they need to fetch<br>
something from the server. And we want clients to only load the minimum<br>
necessary.<br>
<br></blockquote><div><br></div><div>No, I don't think we're ever in that position.</div><div><br></div><div>I think we're in a position whereby should a client want to obtain a list of fastenings for a given message, it always knows if it has the full list already, or if it needs to fetch them, but to fetch will be (at least) 1*RTT (interleavable). This means that to display a screenful of messages and have the client obtain all fastenings for all messages displayed will be 2*RTT - but a client can elide that if it has the fastenings already. We also have simple mechanisms to reduce the amount of data to (more or less) precisely what the client wants.</div><div><br></div><div>The only way I see to reduce this to 1*RTT would mean having all fastenings in full in the result, which would make results huge, so seems unacceptable to me. It would also be a lot of data, which we could reduce by the client having detailed negotiation - but that seems to add a lot of complexity. The summary detail in each result would also vary depending on the extent of the RSM, which is also quite complex on the server.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I'm suggesting that MAMFC provides a compromise that works well enough<br>
> for most cases, and imposes an additional round-trip for some others.<br>
> <br>
> I don't doubt it can be improved, but I think the fundamental shape of<br>
> this works.<br>
<br>
I am certain it will work. The same applies to other possible ideas.<br></blockquote><div><br></div><div>The enemy of the good is the dream of the perfect. :-)</div><div><br></div><div>Dave. </div></div></div>