this is what zot, the protocol #hubzilla is running on does.
It stores contacts etc. as keypares.
You can move those keys to any server you want, and by that remain always connected. Incl. having the publishing setting etc. stored within a #nomadicidentity.
It is also supporting #OAuth to authenticate with other services/apps using that identity.
Decentralized Identifiers (DIDs) I'm curious about. Happy to see that evolve.
All I can say on the matter between #DIDs and how zot does it, that @cwebber and dev of zot @macgirvin have a different perspective on how to solve the mentioned isse.
I have way to little knowledge to make a judge about.
hubzilla was often said to be to complecated etc.
within the next weeks a new social plattform with a more simple codebase and functionality running on zot will be published.
for more about this see:
@bob @paulfree14 @zatnosk @macgirvin @cwebber @trwnh
As someone who's looking to hack on something in this space I'm a bit more interested in the DID stuff I think, but that's because I'm a sucker for a good spec doc. Having briefly scanned through the Zot documentation it occurs to me that it might be possible to register the zot protocol as a DID method. But I haven't actually thought about that in any detail, it's just a nice idea.
i meant something in the way that some people use facebook/google *only* to sign into things. no channels, no publishing, nothing else besides pure authentication/identification
similar to openID servers, but more elegant than the mess that is openID right now
or maybe there's a way to adapt openID / revive it / modernize it?
@alex @paulfree14 @macgirvin @bob @zatnosk @cwebber literally all i'm looking for is, say, hosting my public key at id.trwnh.com for example, and then being able to log into any app *only* by typing in that URL and some method of verification (user/pass?)
if this can be tied into a 2FA app somehow that'd also be cool
that's just my naive idea -- ideally people could also delegate by signing up at an open hub like keybase/google/github/etc, not just hosting their own domain
I still don't understand how authentication solves multiple accounts on multiple platforms problem: if I auth into PeerTube instance with my Mastodon account I expect my comment to be published as a reply by my Mastodon account, so PeerTube would just work as an UI for Mastodon but to do so both Mastodon and PeerTube need to support AP's client-server protocol internally between backend and frontend. I don't see another solution...
@alexl @zatnosk @cwebber As I understand that's exactly the problem that DID attempts to address. A DID document describes methods by which an entity can cryptographically prove that they are associated with a DID (https://w3c-ccg.github.io/did-spec/#authentication) so service providers like a Mastodon instance or a Peertube instance just have to ask the user to run through that authentication flow. Each instance can then use the DID document to lookup service endpoints like the users home mastodon instance. I think ...
@alex OK, and in my example how PeerTube instance can write in my Mastodon instance the reply without an API? If I need to log into Mastodon to check Mastodon notifications and in PeerTube to check PeerTube notifications I miss the point of cross-platform auth...
@alexl So there's every possibility I am being dumb here as I've only skimmed all the relevant specs but isn't that case already covered by the ActivityPub spec? Can the Peertube instance post to your Mastodon inbox to achieve what you want? Or something along those lines?
@alex Mastodon and PeerTube support only AP's server-server API
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!