Conversation
Notices
-
@clacke I don't understand what you're saying. "parent retrieval" is nothing but retrieving a …
- Claes Wallin (韋嘉誠) repeated this.
-
@mk @clacke What about “conversation retrieval”? Find parents back to the original post that s…
-
@lnxw48 @mk Yeah, that would be great, but that would require some server to be responsible for the whole conversation.
-
@lnxw48 @mk This has actually been suggested for the W3 Social protocol, at least it was in one independent proposal, don't remember whose.
-
@mk We're probably talking past each other just by meaning different things by "focus on contacts". Today, server receives from my contacts.
-
@mk So when a person who is not my contact contributes to a convo, I miss it. If all participants are my contacts, I get the whole convo.
-
@mk A technical, protocol-level focus on convos would mean I subscribe to the convo at the responsible server and my server gets all dents.
-
@mk Parent retrieval would be a unilateral patch to the existing protocol, a patch that would at least partially remedy the situation.
-
@mk Parent retrieval would still miss unsubscribed conversation leaves, but at least it would give context to the notes you do receive.
-
@mk My manual fix to the problem is to redent posts I reply to, but apparently redents don't federate well either, and I often forget.
-
@lnxw48 as it is now (if I understand correctly) dents from non-local people are part of a convo only if those people are already "known" on the node. What I prosed is this (quote): "it would be nice if contacts were pulled in not only for subscriptions but also for replies
-
@mk @lnxw48 ...and mentions. If you just do that, I think the whole converssation would be shown automatically because all those people would be pulled in - just by pulling in ALL contacts, not just subscribed.
-
@mk /s/prosed/proposed/
-
@lnxw48 I'm mostly curious about the exploitability of this. Can I tell a remote server to start fetchibg a bajillion fake notices and effectively DDoS a third party? And how do we minimize this risk _in_ the protocol/best practices?
-
@mmn Don't retrieve the entire conversation tree unless the user chooses to. And rather than retrieving parent messages back to the original and then retrieving the entire tree below, retrieve only the first [three|four|five|x] parent levels, and then [x] levels of children below. In most cases the context of a conversation needs only one or two levels. The UI could implement this as collapsible list items, click on the twirly <li> icon to retrieve the previous/next level. Of course, that makes it client dependent rather than baking it into the protocol, and so there's no protection from malclients retrieving everything, all the time.
-
@bobjonkman you could bake a maximum number of levels that can be retrieved in a single API call into the API, so a client cannot overload x server.
-
It was really cool to see !andstatus retreive 18 post from this conversation little by little. Still not grasping how this conversation thing works but it seems to mostly work for me.
Temporary Marjolein
lnxw48 (Linux Walt)
Claes Wallin (韋嘉誠)
MMN-o ✅⃠
Former Bob Jonkman -- Please use the new server at https://gs.jonkman.ca
andresinmp
All Chirp! content and data are available under the