I don’t think the general architecture scales that well (think of all the duplicate storage …
That’s my hunch too, although haven’t studied in detail - so I wonder how we can fix it ?
Is there an forum that discusses this scaling issue (in general, across fediverse) ?
Storage Duplication is I think not necessarily an issue of ActivityPub, it’s an issue of implementation of it. Because all posts can technically live on their respective servers. And rendered directly or almost directly. Like it can be copied over for the time it is relevant, and then discarded to be available only from the original server.
That makes sense, to store only popular stuff, or temporarily - especially for ‘heavier’ images (although as we see with lemm.ee, that leads to issues when an instance dies). Yet I also wonder about the scalability of just the minimum meta-info, whose size does depend on the protocol design.
For example with Lemmy every upvote click propagates across the network (if i understand correctly, mastodon doesn’t propagate ‘likes’ so consistently, presumably for efficiency, but this can make it seem ‘empty’). Maybe such meta-info could be batched, or gathered by a smaller set of ‘node’ instances, from which others pick up periodically - some tree to disperse information rather than directly each instance to each other instance ?
As the fediverse grows, gathering past meta-info might also become a barrier to new entrant instances ?
I suppose this community is as good as any. But it’s difficult to talk in general about this as each fediverse app has different performance needs/characteristics, so I’m not sure if you can extrapolate anything in general. But perhaps?
That’s my hunch too, although haven’t studied in detail - so I wonder how we can fix it ?
Is there an forum that discusses this scaling issue (in general, across fediverse) ?
Storage Duplication is I think not necessarily an issue of ActivityPub, it’s an issue of implementation of it. Because all posts can technically live on their respective servers. And rendered directly or almost directly. Like it can be copied over for the time it is relevant, and then discarded to be available only from the original server.
That makes sense, to store only popular stuff, or temporarily - especially for ‘heavier’ images (although as we see with lemm.ee, that leads to issues when an instance dies). Yet I also wonder about the scalability of just the minimum meta-info, whose size does depend on the protocol design.
For example with Lemmy every upvote click propagates across the network (if i understand correctly, mastodon doesn’t propagate ‘likes’ so consistently, presumably for efficiency, but this can make it seem ‘empty’). Maybe such meta-info could be batched, or gathered by a smaller set of ‘node’ instances, from which others pick up periodically - some tree to disperse information rather than directly each instance to each other instance ?
As the fediverse grows, gathering past meta-info might also become a barrier to new entrant instances ?
I suppose this community is as good as any. But it’s difficult to talk in general about this as each fediverse app has different performance needs/characteristics, so I’m not sure if you can extrapolate anything in general. But perhaps?