I think what you're describing is different. It lists only the communities the current instance knows about, it does not list all communities on all instances, and it doesn't even list the subset of all communities on known instances.
funkyb
joined 1 year ago
Nah, the file would be small and only instances would need to keep a record of it. It's no different from the community list already maintained by instances, just would be extended to cover all participating instances. even if there were 1 million rows to the table, that's a very tiny dataset.
I’d think the cost to storage and performance would be trivially small, not even a rounding error relative to the over server/host loads associated with an instance.
I posted this in Ask Lemmy but since it didn't get traction I'm gonna piggyback on the visibility of this thread:
As i learn my way around ActivityPub based services, what stands out to me the most is federation is very much exposed to the users. (That, or I still just haven’t wrapped my head around the architecture details and how they manifest in terms of user experience.)
Am I just misunderstanding this, or would the end-user experience be more fluid and functional if the federation mechanics were mostly ‘under the hood’. What I mean by that is - right now if there’s a community I would enjoy participating in that is located on a different instance, in order to do that I need to (a) know it exists in the first place, (b) know what instance it is on, and (c) explicitly tell my instance about its address in order to join.
Would it be possible to have some form of master index (replicated across instances - not a centralized service) along with a public standard for registering an instance/community on the index? And if something like that existed, couldn’t that push what is an inherently more technical detail to lower levels of the implementation, and make for a simpler UX by allowing every instance to expose a more complete list of communities to users from directly within whatever instance they choose to use?
And what is it with the narrow aspects? I totally get the need for mobile support, but the default desktop view looks like it's trying to play nice with old 4:3 aspects. If that's the root design goal, I sure hope we can let that design goal die. In a 16:9 maximized window there is so much wasted real estate it pains me.
i've been tempted to get back into MC, but lordy if I go down that rabbit hole again, it's gonna be on something running a modpack!
18pp isn't a small margin. 49 vs 51 is a small margin. 41 vs 59 is no contest.
The difference is you cited software projects, not hosted infrastructure. A person can contribute to a FOSS dev project and not incur expenses dependent on end-users activity. Hosting a fediverse application isn't like that, somebody has to pay for the hosting and the hosting expenses will scale with user activity.
"Created for Lemmy" isn't really a thing, all you need is to implement the ActivityPub protocol. Whether or not it has any relationship to Lemmy has no bearing on if it can talk to instances using Lemmy's implementation.
Sure but anyone can implement something using the activityPub spec and federate with other instances regardless of what flavor they're using.
The button looks like a copy icon. Just mouseover the buttons to the right of the comment count.