Does mastodon (or any other common fedi backend) have a limit to the number of people you can mention in a post?
Just asking for science reasons
=> More informations about this toot | More toots from jenniferplusplus@hachyderm.io
leaving it unbounded seems like it's just an invitation for people to fuck up your database, so letterbook is definitely going to have a limit. But the actual value of any limit would be pretty arbitrary. So my choice is to just make it up, or align with some other project. Between those two options, I prefer alignment.
=> More informations about this toot | More toots from jenniferplusplus@hachyderm.io
@jenniferplusplus how much does character count limit effect this?
=> More informations about this toot | More toots from stefan@gardenstate.social
@stefan In practice, that would very effectively prevent a destructively large number of mentions in a post from occurring on accident.
But it does nothing to stop it from happening on purpose.
=> More informations about this toot | More toots from jenniferplusplus@hachyderm.io
@jenniferplusplus@hachyderm.io aligning with other projects would be allowing users to specify their own preferences. Whether that’s *oma with mrf anti hell thread policies or misskey (and derivatives) with a simple maximum for local users both of them seem to expect the instance administrator to come up with a number.
=> More informations about this toot | More toots from puppygirlhornypost2@transfem.social
@jenniferplusplus@hachyderm.io mrf is a lot more flexible because I know people who make logic out of it.
if post has more than 10 mentions
reject
else if post has more than 5 mentions
set visibility to unlisted
which is a lot better than a strict limit
=> More informations about this toot | More toots from puppygirlhornypost2@transfem.social
@puppygirlhornypost2 Even with that strategy, I would need to define a default.
=> More informations about this toot | More toots from jenniferplusplus@hachyderm.io
@jenniferplusplus@hachyderm.io 10-15 is my vote
=> More informations about this toot | More toots from puppygirlhornypost2@transfem.social
@puppygirlhornypost2
I had a number like 50 mind. My concern at this level is DoS prevention, more than spam. This happens on the request/response thread. Spam etc would come later, in a less time sensitive part of the process.
notifications also come later, and can wait for spam scoring or w/e.
=> More informations about this toot | More toots from jenniferplusplus@hachyderm.io
@jenniferplusplus@hachyderm.io 50 is way too high. I have only hit the 20 limit once and that was a huge hellthread on fedi this circle made as a joke.
=> More informations about this toot | More toots from puppygirlhornypost2@transfem.social
@jenniferplusplus@hachyderm.io as for DoS preventions… are we talking someone makes a bunch of posts mentioning remote users and the instance sends a bunch of activities to those remote users? Or are we talking DoS as in if it federates to the instance there’s a real concern about the instance fetching X amount of users. Recently someone made a bunch of snac2 instances on subdomains it was like 100+ and mentioned them all somewhere… and it took down smaller instances trying to fetch every one of those actors it had never seen before while resolving said mentions
=> More informations about this toot | More toots from puppygirlhornypost2@transfem.social
@puppygirlhornypost2 LB should be unbothered by that. We'll just get to a consistent-but-incomplete state relatively quickly, and then schedule fetches to backfill later.
My concern is more that someone maxes out an http post body with actor IDs and pushes what should be fast index filters into full table table scans.
=> More informations about this toot | More toots from jenniferplusplus@hachyderm.io
@jenniferplusplus@hachyderm.io Could you not do the same lazy load as before? Ie don’t make a bunch of queries and slowly backfill things like icons?
=> More informations about this toot | More toots from puppygirlhornypost2@transfem.social
@puppygirlhornypost2 No, at this point it doesn't actually matter if we already know this actor exists or not.
Basically, there's a lot of SELECT x FROM profiles WHERE profiles.id in (a, b, ..., n). Which is great if n is a tiny fraction of the size of the profiles table. But it can get pushed into not-fine if n is large. So my concern isn't that I might have to do 10,000 AP fetches. That would be annoying, but I don't expect it would affect stability*. It's that I might have to do a half dozen WHERE IN queries where the IN collection is 10,000 url strings
edit:
=> More informations about this toot | More toots from jenniferplusplus@hachyderm.io
@jenniferplusplus@hachyderm.io Honestly I don’t think very many implementations actually take this possibility into account. I’m not sure an arbitrary mention count will solve this, perhaps it will take out one vector but what about something like the alsoKnownAs field
=> More informations about this toot | More toots from puppygirlhornypost2@transfem.social
@jenniferplusplus@hachyderm.io I think the only answer to this is to test it in production because there’s no real fedi traffic simulator (I want one).
=> More informations about this toot | More toots from puppygirlhornypost2@transfem.social
@puppygirlhornypost2 All the presumed actors get bundled up and queried in a single batch. So basically I just need to add a length limit to these two methods:
https://github.com/Letterbook/Letterbook/blob/a4373748f0dabf9223c9a6cd57165c299cd30a04/Letterbook.Adapter.Db/DataAdapter.cs#L180-L192
And similar limits to the corresponding methods on other objects.
=> More informations about this toot | More toots from jenniferplusplus@hachyderm.io
@puppygirlhornypost2 And for that matter, I also need to decide whether to reject a post or truncate it, if it exceeds the limit. I'm leaning toward reject, with a limit as high as 50
=> More informations about this toot | More toots from jenniferplusplus@hachyderm.io
@jenniferplusplus@hachyderm.io Reject unless you have a warning for "This post’s mentions were truncated because it exceed’s the instance mention limit". I dislike software that rewrites posts without notifying the end user that they have been modified. It can lead to a lot of confusion
=> More informations about this toot | More toots from puppygirlhornypost2@transfem.social
@jenniferplusplus set it to 0.
can't use mentions without opting-in.
=> More informations about this toot | More toots from SoniEx2@chaos.social
@jenniferplusplus My limit is 50
=> More informations about this toot | More toots from silverpill@mitra.social
@silverpill that feels like the right number to me, too. Definitely low enough to protect the database, and definitely high enough to permit just about any desirable use.
=> More informations about this toot | More toots from jenniferplusplus@hachyderm.io
@jenniferplusplus In my experience the main problem is the need to fetch so many actors. That may take a lot of time, and might even be a DoS attack vector.
=> More informations about this toot | More toots from silverpill@mitra.social
@silverpill I would only need to fetch them if they're not already cached. But yes, not becoming a DoS vector is on my radar.
=> More informations about this toot | More toots from jenniferplusplus@hachyderm.io This content has been proxied by September (3851b).Proxy Information
text/gemini