for something built around pubsub, we’re surprised lemmy floods mastodon instances with unsupported objects, as opposed to splitting mastodon-irrelevant objects into separate streams and letting instances opt-in to the appropriate streams as needed.
oh well. guess we’re just stuck with it now, since any change would break all old versions of lemmy.
Are mbin & PieFed et.al. demonstrating a better practice for what your describe?
haven’t looked into them. if they have fully-featured federation with lemmy, then they’re probably no better.
that’s part of the problem really, if you wanna be compatible with lemmy you have to do everything lemmy does, including broadcast everything that happens on a community, even if the instance you’re sending it to doesn’t actually support it.
Out of curiosity, could you expand on what these unsupported objects are and when/how they are sent? Could Mastodon support them but just doesn’t yet? Or are the objects not compliant to the standard?
Why should Mastodon get preferential treatment?
why shouldn’t it?
activitypub is a pubsub system. if you put everything in the same pubsub channel, it overloads the channel.
splitting it out enables instances (not just mastodon, but all other instances too) to control their server load better, by literally shedding load as needed.
Lemmy communities don’t flood, they send Announce activities only to actors that follow them. The follower may not support some of these activities, but how this is a Lemmy problem? Any unsupported activity can be easily dropped, that’s cheap. On the other hand, adapting your behaviour to quirks of other software is expensive and leads to ever-growing implementation complexity.
why not put the Announces in different streams so as to benefit everyone? if you don’t send stuff, the software need not process it.
having to actively drop it is a form of processing it. it takes more bandwidth, more server load, and potentially more cost (if you’re using e.g. a pay-per-incoming-request service).
what’s wrong with having more choice?
The problem with your proposal is additional work for all FEP-1b12 implementers, for little benefit. And it’s not a do-and-forget type of thing, developers would need to constantly monitor what other developers are doing and adjust their implementations accordingly (unless they start using some mechanism to signal supported activity types).
In today’s world, with just a single stream of outgoing activities, the total developer effort is (roughly) proportional to the total number of AP implementations that exist.
If every AP implementation were to emit a different stream of activities for every other AP implementation to consume, the total developer effort would be proportional to the square of the number of AP implementations.
they’re more like feature flags. you Follow the feature flags you support and don’t Follow the feature flags you don’t support.
they’d be attached to the Actor as additional inboxes/outboxes/whatever. the mechanism would be generic and the only purpose would be to split the streams.
alternatively, some way to send the feature flags in the Follow so the other instance does the filtering instead.
what you’re asking for is streams or something similar. you want to be able to follow Collections other than the implied outbox.
yes, probably, but how do you convince implementers to use them?
probably someone has to just do it. just like adoption of anything else