6
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 18 Jul 2023
6 points (100.0% liked)
/kbin meta
2 readers
1 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
@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.
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
@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
WebauthN maybe? Pretty niche right now, but the threadiverse is quite a techy crowd..
@JonEFive
https://webauthn.guide/
https://webauthn.io/
@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.
@JonEFive I think the identity bit is the hard part, as you say most content will be federated/ cached in several locations for retrieval
Have you read https://nexus.blacksky.network/zine/00000001/confederal-protocols similar themes that we're talking about here.
@JonEFive