<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 2 Jan 2020 at 20:42, 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/2/20 6:23 PM, Dave Cridland wrote:<br>
> It's not clear to me whether sending two poop emojis should count as two<br>
> reactions or just one. (Surevine once had an internal product that, by<br>
> accident, allowed "multilikes". We liked it. Often more than once)<br>
> <br>
> As things stand, we're effectively defining that people can like (or<br>
> poop emoji) other messages as many times as they like.<br>
As a reminder, <a href="https://xmpp.org/extensions/inbox/reactions.html" rel="noreferrer" target="_blank">https://xmpp.org/extensions/inbox/reactions.html</a><br>
specifically said that there can only be one of each reaction per user:<br>
"A <reactions> element MUST NOT contain the same reaction more than<br>
once. A receiving entity SHOULD ignore duplicate reactions inside a<br>
<reactions> element." This is a feature specifically wanted and desired<br>
by the authors, if MAM-FC is not supposed to be able to handle this<br>
feature, then Reactions can't make use fastening.<br>
<br></blockquote><div><br></div><div>Would this work if we just counted unique fastening summaries for each user, removing any duplicates?</div><div><br></div><div>It doesn't make much difference to me - it's just a unique constraint with different fields in.</div><div><br></div><div>Interestingly that would show edits via fastenings as only ever having one (which is probably OK), receipts etc would show a count per user but avoid duplicates, which seems sensible.</div><div><br></div><div>Also trivial to include two counts, one with and one without duplicates, which would satisfy either case.</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">
> In general, the "edit" case (as with any retraction case and others) is<br>
> a little shaky here because of authorisation. I'm very much open to<br>
> ideas here - it might be sensible to have a switch like the "external"<br>
> which pulled in the stanza from attribute, for example, or we might<br>
> simply choose to have servers "know" about edits (but see below).<br>
In the unfinished proposal I shared in the last mail, each <applied><br>
also had a from attribute which is the from of the message that included<br>
the fastening. This however does not work in your model due to multiple<br>
fastenings being collapsed if they have the same type.<br>
<br></blockquote><div><br></div><div>Yes, but that's needed if we want to support, for example, reactions (or even "likes") in a large chatroom.</div><div><br></div><div>Sending 50+ likes for each message would be extraordinarily painful in terms of bandwidth, and it's not unreasonable to assume that might happen quite often.</div><div><br></div><div>This is massively amplified by receipts - it's very useful to know if anyone, or everyone, has seen a message, but in a large chatroom that's a lot of receipts.</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">
> <br>
>     Also note that the edit proposed in this ProtoXEP is not really<br>
>     compatible with the edit proposed in the fastening XEP<br>
>     <<a href="https://xmpp.org/extensions/xep-0422.html#external-payloads" rel="noreferrer" target="_blank">https://xmpp.org/extensions/xep-0422.html#external-payloads</a>> as it is<br>
>     completely unclear what is supposed to happen with the <external<br>
>     name="body"/>.<br>
> <br>
> <br>
> Yes, quite, these need pulling into the fastening summary if they exist<br>
> (ie, they're not being pulled in from the encrypted blob). Totally happy<br>
> to make that clear.<br>
I think you missed the point that the <external /> is not a child of<br>
<edit /> but a sibbling. According to your proposal, only childs of<br>
<edit /> would be inside the <applied> element. So even pulling in the<br>
body doesn't describe how to handle this at all. This might as well be<br>
an issue in the XEP-0422 as it also says that an <apply-to> may contain<br>
several fastenings, but they must all be of the same type, and body<br>
doesn't seem to be the same type as <edit /><br>
<br></blockquote><div><br></div><div>See last para of XEP-0422 §3.2</div><div><br></div><div>But in any case, the external things direct the client to the external parts, which logically form part of the fastening.</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">
> FWIW, we use Chat Markers as super-receipts only, so I may have a blind<br>
> spot there.<br>
This pretty much confirms my feeling that this XEP is targeted for very<br>
few specific usecases which is exactly the opposite of generic. The<br>
whole purpose of fastening is to have something generic and that's the<br>
reason why we are delaying the proposed reactions XEP. If we now build<br>
something that is again not generic (and can't even handle the concept<br>
and ideas layed out in that proposed XEP) we won nothing and<br>
unnecessarily delayed a real feature that is often requested by end users.<br>
<br></blockquote><div><br></div><div>I don't see a concrete suggestion here.</div><div><br></div><div>It may well be that Chat Markers don't make a suitable case for fastening, and I'm fine with that.</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">
>  <br>
> <br>
>     I also don't like that if I have a shell fastening, I only get to know<br>
>     that there are fastened messages. If there is 20 edits and one reaction<br>
>     and I want to know who send this reaction, I shouldn't be requires to<br>
>     download the 20 edit fastenings (using your proposed "fastenings" MAM<br>
>     call). I think all <applied> elements should carry the id of the<br>
>     underlying message from the archive, so that I can specifically<br>
>     fetch those.<br>
> <br>
> <br>
> Shell fastenings are for encrypted cases, so the server simply cannot<br>
> tell what these are and has no way to tell, by design. This was<br>
> specifically to satisfy cases where "everything must be encrypted".<br>
What I was proposing is that instead of adding the shell="true", add an<br>
id="mam-archive-id-of-the-fastening-message", so that clients can<br>
specifically fetch those instead of having to fetch all others (which<br>
may have not been shell fastenings). As shell fastenings don't have a<br>
count (at least I presumed that, because you'd just be counting the<br>
number of shell fastenings which sounds pretty useless), one shell<br>
applied element always references exactly one message.<br></blockquote><div><br></div><div>Shell fastenings are pretty useless, yes. But having them individually listed would, i think, be worse - and we can already pull the complete list of them if we need to. It's an additional round-trip, certainly, but that's a penalty if you're encrypting everything.</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">
> But if each individual fastening type has to have code support in the<br>
> server, that really slows down the rate of innovation.<br>
I am aware this is an issue because servers update slow. But rather than<br>
putting arbitrary restrictions of what can be done with fastenings, I'd<br>
prefer to have two levels of fastening collation, one that only<br>
describes the existence of fastenings (pretty much like shell fastenings<br>
in your proposal) and one that does smart collation. That second level<br>
would then only work if server supported that specific fastening type,<br>
so it could sum the reactions for reactions (including the limit of one<br>
reaction per kind), directly apply edits or whatever else comes in your<br>
mind. Of course both clients and servers would need to announce which<br>
smart fastening collations they support and servers should only use<br>
those that the client announced to support.<br>
<br></blockquote><div><br></div><div>I don't think that's a sustainable path to take.</div><div><br></div><div>I'm not saying that having per-fastening code in every server is slow just because there's a lag to them updating, I'm saying it'll be slow because you'll have several round-trips between server developers and client developers as the feature is developed and it'll take literal years for each one to become stably deployed, as well as creating a vast amount of workload for the XSF and its participants.</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 absolutely not averse to having the client add in how a fastening<br>
> should be summarized - that was my original design actually - but we<br>
> decided that the count + latest was sufficient for all cases.<br>
I think this count thing is a bad idea. It is totally targeted towards<br>
reactions but even fails to provide the guarantees needed for proper<br>
usage of them. This is by the way getting way more complicated in<br>
semi-anon MUCs, because servers have to ensure that I cannot create an<br>
arbitrary number of likes by just changing the nick or changing the<br>
reactions someone else did by taking over their nick while they are<br>
offline, so we probably would need to incorporate occupant id somehow.<br>
<br></blockquote><div><br></div><div>You're expecting servers to track individual authorisation of likes within chatrooms?</div><div><br></div><div>if it does, then it can filter entirely, surely? If it does not, then the user's MAM archive cannot help anyway without an information leak from the chatroom, can it?</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">
The latest thing is at least not a bad thing in most cases, so I'd be<br>
fine with that, as long as it is filtered per sender (showing the<br>
content of the latest of that fastening type for each sender instead of<br>
latest in total).<br></blockquote><div><br></div><div>Again, if you have 50 likes in a chatroom that'd be a disaster. If your client needs the individual likes, it can ask for them easily enough (if you want only likes and not other fastenings that'd be trivial to add).</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">
> It *is* unfinished - of course. It doesn't even have a XEP number<br>
> (though it does have a schema etc already).<br>
This is perfectly fine of course. I was only mentioning this because we<br>
are already requiring everyone to use fastening even though we kind of<br>
agree that this isn't really a good idea at this stage because it is<br>
rather unfinished.<br>
<br></blockquote><div><br></div><div>You seem intent on twisting my words, so allow me to return the favour.</div><div><br></div><div>You're saying that the XSF should only accept completely finished proposals in this space?</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">
>     Just to come up with a new potential idea that would be hard to<br>
>     impossible to realize with your proposal: Clapping; on a popular blog<br>
>     platform you can clap for blog posts. Every user is entitled to up to 50<br>
>     claps on a blog post, but you can't undo claps. Usually only the total<br>
>     number of claps is displayed, but there is a detail view where you can<br>
>     see which persons clapped and how often.<br>
> <br>
> <br>
> Right, so, how would this work with MAMFC as written.<br>
> <br>
> So, users can clap on a message - OK, so we have a fastening type of<br>
> <clap/>. This summarizes to <clap/>, and has a full fastening of<br>
> <clap/>, so that's trivial for MAMFC so far.<br>
> <br>
> The total number of claps is shown, which again is fine for MAMFC.<br>
> <br>
> Our problem is that each user can only clap 50 times, so one assumes<br>
> that in a chatroom of 10 users, the maximum clappage can be 500? (or<br>
> 450, if one cannot clap oneself, which is at least gauche...). MAMFC<br>
> cannot currently enforce that, you'd have to enforce it client-side, or<br>
> by introducing a blog service which mediating clapping.<br>
> <br>
> But equally, it would have to be enforced somewhere, and to enforce it<br>
> inside MAM would mean it would have to be enforced in code on every<br>
> users' server who participated.<br>
> <br>
> If we ignore the limit, it becomes trivial - if we have "undo" claps,<br>
> then I think MAMFC should be able to handle that, though I've not<br>
> specified that yet because I was slightly ahead of Kev's XEP-0422<br>
> update. But I will do.<br>
> <br>
> So, summary: We cannot do your clap proposal with MAMFC, nor with any<br>
> similar system which doesn't involve either hardcoding the support in<br>
> every server or including an arbitrarily complex summarizer DSL code<br>
> fragment alongside every fastening.<br>
> <br>
> Is this a problem?<br>
If we picked a different MAM-FC the 50 per user (instead of an n*50 for<br>
n users) limit would entirely be possible: we don't have MAM-FC do any<br>
summing and we add the from to the <applied> and instead have each user<br>
always sends their total number of claps instead of just <clap /> for<br>
each single clap and replace the previous fastening. We then end up with<br>
a list of the latest number of claps of each user like this:<br>
<applied from="X"><clap count="20" /></applied><br>
<applied from="Y"><clap count="40" /></applied><br>
<applied from="Z"><clap count="60" /></applied><br>
The element from Z has a too high number, so we just cut it to 50, the<br>
total count thus would be 110.<br>
What is not possible using this "latest" approach is that we can't<br>
verify that users are not removing claps. If we get rid of the "latest"<br>
mentality completely, we might see that X had send more claps before:<br>
<applied from="X"><clap count="10" /></applied><br>
<applied from="Y"><clap count="20" /></applied><br>
<applied from="Z"><clap count="30" /></applied><br>
<applied from="X"><clap count="50" /></applied><br>
<applied from="X"><clap count="20" /></applied><br>
<applied from="Y"><clap count="40" /></applied><br>
<applied from="Z"><clap count="60" /></applied><br>
The client would then be able to calculate a sum of 140 for this which<br>
is the correct number under that desired specification. Of course this<br>
has a higher overhead. If the server has support for understanding<br>
clappings, they could just send<br>
<applied from="X"><clap count="50" /></applied><br>
<applied from="Y"><clap count="40" /></applied><br>
<applied from="Z"><clap count="50" /></applied><br>
<br></blockquote><div><br></div><div>OK, so you're saying that the client sees there are claps, and can retrieve all the clap fastenings and process them locally.</div><div><br></div><div>Which can be done with this ProtoXEP.</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">
if both server and client announce support for smart summarizing of<br>
clappings, it could even become<br>
<clappings count="140" /><br>
<br></blockquote><div><br></div><div>How does the server know what the legal limit is for claps, though? Have you declared that every server in existence should support your limit of 50 and no take-backs? Otherwise this cannot possibly work.</div><div><br></div><div>As entertaining as this is, therefore, it seems to be a specious argument.</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">
The point I want to make and the problem here is that your restrictions<br>
for MAM-FC will effectively make certain usecases impossible. The only<br>
way to prevent that is to not make restrictions of fastenings that you<br>
don't understand. If you don't want fastening to be generic enough to be<br>
used for most usecases, fastening itself becomes useless.<br>
<br></blockquote><div><br></div><div>Although MAMFC will work, it just may require an additional round-trip for this contrived case.</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, requiring server support is bad, but I think an approach is<br>
possible where the server doesn't need to support a fastening specific<br>
collation, it just can improve its bandwidth usage by doing so. Clients<br>
need to be able to support the non-summarized version anyway (because<br>
that's what they receive when not fetching from MAM) and they should<br>
also be interested in using smart summaries where possible to reduce<br>
bandwidth (thus downloading from MAM faster). Thus there is a natural<br>
wish of both clients and servers to implement the smart summaries when<br>
certain fastening types become popular whereas unpopular fastening types<br>
can still be used with no issues because you didn't put any unnecessary<br>
server side restrictions (and if they are unpopular anyways, the server<br>
doesn't need to fear bandwidth created by them not being summarized).</blockquote><div><br></div><div>So there's a balance and compromise to be made, indeed.</div><div><br></div><div>I'm suggesting that MAMFC provides a compromise that works well enough for most cases, and imposes an additional round-trip for some others.</div><div><br></div><div>I don't doubt it can be improved, but I think the fundamental shape of this works.</div><div><br></div><div>Dave. </div></div></div>