@Natureshadow@floss.social
It's tricky because ActivityPub made design choices that put instances, not users, at the center of its operation.
It's really hard to fit distributed identities into such a system.
@h@mymath.rocks @pinkyfloyd @smallcircles @lrhodes @bengo @liaizon
There are downsides to that, though, particularly when it comes to scalability, under the ActivityPub design.
Some aspects of AP scale by instance more than user, so going with one user per instance can really increase resource costs of operating the system.
@Natureshadow@floss.social @bengo @lrhodes @h@mymath.rocks @smallcircles @liaizon
No, it's not an implementation issue but the design of the protocol itself, the way ActivityPub has instances address each other and send out per-instance messages.
The protocol allows bundling of messages to multiple users on one instance, but with one user per instance the messages would need to be duplicated, scaling with instance count.
@Natureshadow@floss.social @bengo @lrhodes @h@mymath.rocks @smallcircles @liaizon
This isn't something that can be solved with a little tweaking, though.
As it is, we'd expect every post to be sent to every subscribed end user, by sending a copy to each relevant instance with a list of recipients. That's the core heart of the protocol, no matter what language software may be written in, how it organizes variables to save memory or whatever.
But that requires a load that increases as # of posts * instances.
It ends up looking awfully exponential, a graph that quickly explodes with increasing use.
It's no simple feat to tweak the system to arrest such a problem of exponential scaling, but switching to single user instances only drives the explosion faster.
@Natureshadow@floss.social @bengo @lrhodes @h@mymath.rocks @smallcircles @liaizon
exactly and i for one believe that the default case should be every user having their own instance.