I think there’s a complex use case here which is a blend of the two (OP might not have been thinking about this, but I have) which I’ll call a “portable identity” but I mean portable more in the sense of high availability. From a problem statement point of view:
my workplace uses a network level filtering service which blocks things; for example, *.info is 100% blocked, newly registered domains less than 30 days old are blocked, sites which the filter has deemed unacceptable (firearms, nudity, etc.) are blocked and so forth. This block prevented me from reaching lemmy.world while on the work network, so I use(d) another instance while waiting on lemmy.world to registrar mature > 30 days - but what if this site had ended up being lemmy.info? I’d be SoL getting to it, ever, while at work
sites go down and struggle; lemmy.world went through a period there of intense growing pains and it ended up missing some federated content (posts and comments). This is not a dig against lemmy.world, it happens to any site - so “always have a backup plan” right now is having another login on another instance subscribed to the same content
while addressing (1) and (2) above, because my profile is “trapped” on a specific instance I lose access to saved items, comments and posts related to that account. So while site (a) is, say, down for maintenance or something and you roll over to site (b) you’ve lost your context. I do not expect lemmy/kbin instances to have any sort of complex or expensive HA in place to give me uptime, they are volunteers paying out of pocket and donations and doing us a service for free so my expectations are set accordingly to just have gratitude they even run
So I think there’s a problem here to solve which currently is partially solved by having multiple logins on different instances, but is better solved in some other fashion (a blend of federated identity and SSO). Of course “run your own instance” is one type of solution to this problem but is beyond the reach of every possible user (IMHO) so it’s not really the best solution. Something new we don’t have yet needs to be dreamed up…
edit: I forgot a 4th use case, what happens when two instances semi-defederate and you want to use both without losing content? the issue with beehaw and .world one-way-defederating means that if you wish to get the full experience of participating on news@beehaw.org and news@lemmy.world, you need to use a 3rd instance which federates with both (in both directions).
I think there’s a complex use case here which is a blend of the two (OP might not have been thinking about this, but I have) which I’ll call a “portable identity” but I mean portable more in the sense of high availability. From a problem statement point of view:
*.infois 100% blocked, newly registered domains less than 30 days old are blocked, sites which the filter has deemed unacceptable (firearms, nudity, etc.) are blocked and so forth. This block prevented me from reaching lemmy.world while on the work network, so I use(d) another instance while waiting on lemmy.world to registrar mature > 30 days - but what if this site had ended up beinglemmy.info? I’d be SoL getting to it, ever, while at workSo I think there’s a problem here to solve which currently is partially solved by having multiple logins on different instances, but is better solved in some other fashion (a blend of federated identity and SSO). Of course “run your own instance” is one type of solution to this problem but is beyond the reach of every possible user (IMHO) so it’s not really the best solution. Something new we don’t have yet needs to be dreamed up…
edit: I forgot a 4th use case, what happens when two instances semi-defederate and you want to use both without losing content? the issue with beehaw and .world one-way-defederating means that if you wish to get the full experience of participating on news@beehaw.org and news@lemmy.world, you need to use a 3rd instance which federates with both (in both directions).