Who should 'own' magazines? Federated infrastructure but user sovereignty: a “third way” between federated and P2P networks?

At the moment the server owner effectively 'owns' magazines & communities. Is that the right balance of power? What happens when servers go offline, or server admins go rogue?

In a world where both users and magazines had public and private keys and magazine moderators had the tools to do off-site backups.

Could the magazine moderator then do an unassisted migration to a new place?

They revoke the key that gives the original server the right to host the magazine. They use the key to re-create it on a new server.

Somehow notify all the members the magazine of the new location. The users use their public keys to reclaim their identities and content.

Would that give mods too much power?

It all gets complicated fairly quickly! I think the Bluesky AT protocol is somewhat close to this model for user content, but doesn't really extend to 'community' scale content.

It falls short of a full confederal protocol

poVoq,
@poVoq@slrpnk.net avatar

I think there should be an easy way for moderators to inform subscribers that they migrated to a new community, similar to how you can migrate a user account on Mastodon. The users can then decide if they want to change their subscription to the new place or not.

But this absolutely should not extend to previous user contributed posts. Community/Magazine moderators do not own these and thus can not just decide to migrate them to another place.

There is a certain trust relationship between the users and an instance operator that the posts they contribute are in good hands and are not data-mined etc. Allowing moderators to take all those posts and move them for example to a commercially run server in a low data-protection jurisdiction like the USA would be a huge violation of this trust.

Sam_uk,
Sam_uk avatar

@poVoq yes this sounds sensible. I think the key is the user themselves having more control over their identity.

JonEFive,

It's an interesting conundrum for sure, but I think a lot of people are looking at this the wrong way. People seem to want what they used to have on reddit: one massive community for each topic. In reality, federated services like Kbin and Lemmy are like lots of small reddits. Each instance has its own group of users and it's own magazines/communities.

This is a bit like how things used to be before gigantic sites like reddit were around. If there was a particular interest you wanted to follow or discuss, you would seek out a forum site that catered specifically to that interest. You might have a few different sites that you would log into to see new posts, add comments, etc. This fostered some pretty tight knit communities where you might actually get to know other users because they're might only be a couple hundred active users or even less.

And there might have been some overlap between those forums. If you're into cars, you might participate in one forum specifically for corvette owners and also a more general car enthusiast forum. Both of those sites might have boards dedicated to a particular model of corvette. The difference now is that you only need one account to participate in both forums.

And when a forum site would shut down, either the owners would give notice ahead of time so that users could relocate, or if the site disappeared, users were left to find new places to congregate on their own.

Kbin.social is a general forum whose purpose is to provide users with a centralized place to log in to to discuss a variety of topics. I think as the fediverse continues to spread, we'll see more specialized instances. Midwest.social is a good example of that that I am aware of.

So as it pertains to magazine ownership and faith in moderators and admins, is it really all that different from what we've been doing? If a magazine owner starts doing something that the community doesn't like, someone can create a new magazine and users can migrate if they choose. The same is true of an instance owner. In this case, I have faith that if Ernest decides to shut down the Kbin.social instance, they'll give us fair warning. And if the instance disappears overnight, I'll have to start over on another instance. The nice thing is that the communities that I participate in might be spread out. So just because this instance goes away, that doesn't mean that all my content and communities are gone with it. Merely those that were hosted on this particular instance.

I think the better approach would be something akin to multireddits where you could collect posts in similar communities from multiple instances into a single place. I believe magazines already have a feature sort of like that, but I'm not positive. That way, community posts would naturally be spread around to multiple instances and one instance going down wouldn't be the end of the world.

Sam_uk,
Sam_uk avatar

@JonEFive Multi-magazines are certainly desirable and would to some extent mitigate the data loss caused by an individual server going dark.

I guess the larger issue is if your 'home' instance is the one that goes dark, taking your personal account with it. Maybe it's in fact user account portability that's most important to work on. Assuming that multi-magazines happen fairly soon.

JonEFive,

While it isn't practical for most users, if you're really that concerned about maintaining control of your user account, you could create your own Kbin instance that's basically just for you. There are hosting services available where you could probably do it for a few bucks a month plus the cost of the domain name. I've considered setting something like this up myself.

Obviously this isn't a viable solution for most people, but it is an option.

Sam_uk,
Sam_uk avatar

@JonEFive I do run an instance that's just for me https://fledd.it (configured as a news aggregator) it was easy on elest.io. $10/ month is too much for most people though. I don't think this is the route to mass adoption.

JonEFive,

True. It makes me at least think about what other options there are in terms of resiliency for user accounts. Right now we're back to the wild west days of the internet where you might not be 100% sure that your provider is in it for the long haul. There were so many random email hosts in the 90s and early 2000s with vanity domains. Now, it's rare to see anything other than Gmail, outlook, iCloud, or hotmail for personal emails. People congregated around the big companies. That's what worries me about companies like Meta and Twitter getting into the fediverse

Sam_uk,
Sam_uk avatar

@JonEFive I've been wondering about separating the ID/auth from the app. Someone recently got Keycloak working and that has some possibilities for federation. Not sure if that really helps though. You still have to trust the keycloak admins

Sam_uk,
Sam_uk avatar

WebauthN maybe? Pretty niche right now, but the threadiverse is quite a techy crowd..

@JonEFive

Sam_uk,
Sam_uk avatar
JonEFive,

This got me thinking a bit, and I had this whole long post written out. Turns out someone else had a very similar idea to what I was about to discuss regarding public/private keys:

https://aumetra.xyz/posts/fediverse-nomadic-identities#introduction

This approach is interesting because I was thinking that you would need a trusted server to host the public certificate. But maybe that isn't the case so long as you keep a copy of your public key. As long as you have your private key, you would always have proof that a post made using your public key was from you. Even if someone tried to impersonate you, they wouldn't be able to sign a post with your private key, which means they wouldn't be able to link their profile to your account. Your public key certificate effectively becomes your identity and your private key signature is your "password" proof that you are the person associated with that public key.

If your main instance goes down, you could use your keys to create an account on another instance (assuming that's permitted). Or you can create other accounts like the article describes.

On its own, this keeps your identity intact, but not your post history. It could be designed that your account on one instance references your account on all the other instances it knows about where you have an account. Then a post history could display data from multiple servers, or at least link back to your profile on your other servers.

But if a server goes offline, your posts do too. I just don't think there's a great way to manage that.

Sam_uk,
Sam_uk avatar

@JonEFive I think the identity bit is the hard part, as you say most content will be federated/ cached in several locations for retrieval

Sam_uk,
Sam_uk avatar

Have you read https://nexus.blacksky.network/zine/00000001/confederal-protocols similar themes that we're talking about here.

@JonEFive

sbv,

It seems weird that communities are locked to a server and there’s no way to converse without that server in the loop. Or migrate a community.

HandsHurtLoL,

As the owner of a magazine, I do not want to do this. I don't want to be responsible for collecting data, storing it, and then shopping for a new place to set up homestead.

Sam_uk,
Sam_uk avatar

@HandsHurtLoL Arguably you're not the magazine owner. The server admin is. That's kind of my point.

HandsHurtLoL,

I understand your larger point that technically Ernest could pull the plug on kbin.social (the instance my magazine is on) and we lose it all. In that sense, he is sole proprietor and owner of all the magazines on this instance. I get that point.

But to your point about who is going to pick up and move the magazine to a different instance, that's me or one of my colleagues on my mod team. I'm listed as the owner of the magazine, and until the next core rollout, I technically have higher privileges than the rest of the mod team (which I didn't expect nor ask for).

I'm responding to your idea here, which is if our instance ever got the plug pulled on it, I personally will not take the time to uproot the data from the magazine and set up shop elsewhere.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • kbinMeta
  • rosin
  • DreamBathrooms
  • mdbf
  • magazineikmin
  • everett
  • Youngstown
  • slotface
  • thenastyranch
  • GTA5RPClips
  • Durango
  • modclub
  • kavyap
  • normalnudes
  • InstantRegret
  • bokunoheroacademia
  • tacticalgear
  • ethstaker
  • khanakhh
  • osvaldo12
  • cubers
  • anitta
  • lostlight
  • cisconetworking
  • tester
  • HellsKitchen
  • relationshipadvice
  • Leos
  • sketchdaily
  • All magazines