/kbin meta

3 readers

3 users here now

Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign

founded 1 year ago

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

submitted 1 year ago by [email protected] to c/[email protected]

19 comments fedilink hide all child comments

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

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 1 year ago (1 children)

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.

[–] [email protected] 2 points 1 year ago (1 children)

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

[–] [email protected] 1 points 1 year ago

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

@JonEFive