alex @alex

I'm really excited about all the activity in the federated, self-hosted space. However, I feel like there's still a missing piece around identity. I don't want to have to create a new user every time I want to use someone elses shiny new federated event sharing application or what have you.

There don't seem to be any great self hosted OpenID providers out there and OpenID only solves the authentication part anyway. Maybe I've missed some obvious solutions?

· Web · 6 · 7

@ckeen @alex Hubzilla supports cross-instance auth just because it's an all-in-one social network. To apply this to platforms with different purposes like Mastodon and PeerTube you need to define a protocol and AP's client-server API seems to be that protocol, but nobody is going to adopt it...

@alex a part of this might be solved through Decentralized Identifiers (DIDs) that @cwebber seems to be quite hyped on. But there's no deployable solutions yet AFAIK.

@zatnosk @cwebber Yeah the decentralised identifiers stuff looks perfect, I've only skimmed the spec at the moment but am planning to have a proper read through it over the weekend.

Lack of implementations might be something I consider a plus point as I'm looking for something to hack on 😂.

@alex @zatnosk @cwebber federated identity server when

a server that handles *only* identity, like a federated keybase maybe

and you can authenticate with other services/apps using that identity

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.

Also does hubzilla offer an infrastructure to deploy apps/plugins.
@alex @zatnosk @cwebber

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.

@alex @zatnosk

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:

@cwebber @macgirvin @alex @zatnosk

@paulfree14 @zatnosk @alex @macgirvin @cwebber @trwnh

This sounds great. I particularly like the Denim idea. Hubzilla is one of the best systems around but it's a gigantic dreadnought of features. Doing something which is the opposite and has a few simple features might be more successful.

@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.

@alex @bob @paulfree14 @zatnosk @macgirvin @cwebber yeah idk this is all too far beyond what i was originally suggesting

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 @bob @paulfree14 @zatnosk @macgirvin @cwebber which is to say: i think tying ID up within a publication spec is kind of an issue, if you don't want to publish anything. decouple ID from publishing.

>, if you don't want to publish anything. decouple ID from publishing.

I believe this is the case. @macgirvin might tells you more about
@alex @bob @zatnosk @cwebber

@paulfree14 @trwnh @macgirvin @bob @zatnosk @cwebber

When you say publishing what exactly do you mean? DID as far as I can tell doesn't have anything to say about publishing.

@alex @paulfree14 @macgirvin @bob @zatnosk @cwebber literally all i'm looking for is, say, hosting my public key at 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

@alex @paulfree14 @macgirvin @bob @zatnosk @cwebber of course the other half of that is... actually having adoption of this method across services?

@paulfree14 @trwnh @zatnosk @cwebber @alex I don't have any complaints about a nomadic identity based on DIDs - other than the fact that I know of no working implementations. Once they exist I'd be happy to try and federate with them. I'm slightly concerned that they are linked with LD-Signatures which have a number of practical problems, but there is no perfect technology.  Meanwhile zot nomadic identity has been in production since 2012. Whether or not somebody agrees with the conceptual basis isn't relevant and usually signals a devolution of the conversation into ad hominem behaviour. It works as described for the use case it was intended to serve. 

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...

@zatnosk @alex @cwebber

@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 ( 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

@alex absolutely 100% agree. decentralised-nomadic identity is the foundational piece of federation that is missing for the fediverse. Hubzilla has their Zot protocol that solves this (apparently, i have yet to try it) but they're also the only software that implements it.

i really really want something capable of solving this problem fediverse wide, but that is a massive undertaking

@alex We're currently using OpenWebAuth for cross-domain access control. It's basically just http-signatures and webfinger.
For site authentication (as opposed to cross-domain authorisation) there's IndieAuth and OpenIdConnect and we're currently investigating how we might be able to work with webauthn. 
I personally would prefer having integrated services rather than requiring accounts on 20-30 different services and trying to synchronise my connections across them. That's a lot of duplication of effort. But many people don't like integrated services because of the perceived added complexity. So it will be interesting to see how this current evolution of micro-services unfolds. 

@macgirvin The stuff you've done with Hubzilla in general and the OpenWebAuth stuff specifically looks really impressive. I'm planning on spending a bit of time this weekend reading through things in detail and trying to get my head around the different tradeoffs and approaches. Thanks for explaining a bit about OpenWebAuth.