"as:VisibilityHint": "as:UnboostableByGargronSpecifically",

@gargron no offense you just have a LOT of followers and also secondarily I'm too lazy to set up caching

@nightpool @Gargron still not sure how you're supposed to handle caps on a chain of replies sanely

@Thib @gargron I can probably solve this one but I have no idea how to handle capabilities for just like, viewing an object

@nightpool @Gargron I mean, if we want capabilities for replies, you can't just accept a toot which is supposed to be a reply, you have to check its ancestor. And check that its ancestor is itself allowed to exist, and so on. Since it's unbounded it's an issue.
Also, what if one of the ancestors isn't available to you? (Widening of audience, block, or temporary failure)

@Thib @gargron you only need to check the toots you don't already know about though, and that can be done asynchronously. it's orthogonal to checking the actual capability for the reply, it's more like ThreadResolveWorker

@nightpool @Gargron you don't have a bound on the number of toots you don't know (e.g. a long thread not involving you, and at some point you're mentioned).

I fail to see how it's like ResolveThreadWorker: you have to know every ancestor is valid before validating the toot you intended to process. Otherwise, you might accept a reply without proper capability to a toot you don't know yet if there's a malicious actor.

@Thib @gargron I'm not sure I follow. why would accepting that toot be bad? it's only inReplyTo one toot, and if that toot is invalid, then it will be completely disconnected from the upthread chain

@nightpool @Gargron hm, yeah, I'm just not sure about having a valid thread based on an invalid toot… but I guess it's a possible tradeoff?

@Thib @gargron sure, then just defer it until you've processed the other toot. that's not something mastodon's job system can really currently do but plenty of other job systems can

@Thib @gargron I really don't think that makes any sense though. right now if I reply to a toot that doesn't exist, mastodon just drops the inReplyTo. I don't see why we would have a different behavior here. (but I can imagine different AP systems wanting to implement a different behavior)

@nightpool @Gargron I imagine you'd require reply caps to avoid getting your mentions flooded by unwanted replies. With your suggestion, it takes only one instance not implementing ocaps to start a “valid” thread mentioning you (I mean, one user could still mention you in relation to your toot without it being a reply, but still)

Sign in to participate in the conversation

Cybrespace is an instance of Mastodon, a social network based on open web protocols and free, open-source software. It is decentralized like e-mail.