5 ms·

> For me the main barrier is that I want to have portable/roaming control over my IDENTITY, even if the content hosting is (for now) entirely through a system a

by ryan29 3y ago

> For me the main barrier is that I want to have portable/roaming control over my IDENTITY, even if the content hosting is (for now) entirely through a system administered by someone else. If I control the identity, I can at least keep local copies and rehost/repost content later. This is why I want domains as identities to succeed. I want to own my handle on every platform, but I don’t want to self host.

agentgumshoe 3y ago
So where is it kept then?
- arbol 3y ago
  Sounds they want self custody of their keys. This isn't what the general public want. Decoupling identity from social is a good idea but you can't just migrate the key storage to a single custodian entity. There'd need to be a multiple custodians to ensure the same power imbalances didn't reappear in a different form (e.g. Google owning everyone's logins).
  - agentgumshoe 3y ago
    Exactly. There is no magic trustable non-local/distributed system that replaces 'self-hosted' for this purpose. All that is needed is a to create your local identity (e.g. like storing fingerprint biometrics on your laptop) and a clever way to sync between physical devices (e.g. through bluetooth). We're in this weird situation where people don't want to be responsible for managing their own data/id, but can't trust others to do so for them.
tlonny 3y ago
Do you know of any existing projects in this space? I was toying with an idea/protocol where: 1. You add a TXT/CNAME that points to a trusted "authentication provider". 2. When you try and login to a website that supports the protocol, it checks the DNS record and redirects you to your provider. 3. You then "prove" that you own the domain to the provider - how this is done would be specific to each provider, but one possible method could be by providing a signed message that can be verified vs. a public key stored in a DNS record. 4. The provider redirects you back to the original website with a token. 5. Finally the original website consumes this token by sending it in a request to the provider. The response contains the domain as confirmation of the user's identity. This approach removes the need for self-hosting as users can point and setup their names with third party providers. Users can also trivially switch to a different/self-hosted provider by changing the CNAME. Communities could also allow direct registration by hosting their own provider instance and pointing a wildcard subdomain at it: (i.e. *.users.ycombinator.com). Users could then sign up to said provider using traditional email/password and claim a single subdomain: (i.e. tlonny.users.ycombinator.com) Thoughts?
- justsomehnguy 3y ago
  GP wants not to self host yet wants to have the control. Though what you described is just a regular federated identity workflow, except autodiscovery through DNS (though that is already a thing for some)

by ryan29 3y ago

agentgumshoe 3y ago

So where is it kept then?

arbol 3y ago
Sounds they want self custody of their keys. This isn't what the general public want. Decoupling identity from social is a good idea but you can't just migrate the key storage to a single custodian entity. There'd need to be a multiple custodians to ensure the same power imbalances didn't reappear in a different form (e.g. Google owning everyone's logins).
- agentgumshoe 3y ago
  Exactly. There is no magic trustable non-local/distributed system that replaces 'self-hosted' for this purpose. All that is needed is a to create your local identity (e.g. like storing fingerprint biometrics on your laptop) and a clever way to sync between physical devices (e.g. through bluetooth). We're in this weird situation where people don't want to be responsible for managing their own data/id, but can't trust others to do so for them.

tlonny 3y ago

Do you know of any existing projects in this space? I was toying with an idea/protocol where: 1. You add a TXT/CNAME that points to a trusted "authentication provider". 2. When you try and login to a website that supports the protocol, it checks the DNS record and redirects you to your provider. 3. You then "prove" that you own the domain to the provider - how this is done would be specific to each provider, but one possible method could be by providing a signed message that can be verified vs. a public key stored in a DNS record. 4. The provider redirects you back to the original website with a token. 5. Finally the original website consumes this token by sending it in a request to the provider. The response contains the domain as confirmation of the user's identity. This approach removes the need for self-hosting as users can point and setup their names with third party providers. Users can also trivially switch to a different/self-hosted provider by changing the CNAME. Communities could also allow direct registration by hosting their own provider instance and pointing a wildcard subdomain at it: (i.e. *.users.ycombinator.com). Users could then sign up to said provider using traditional email/password and claim a single subdomain: (i.e. tlonny.users.ycombinator.com) Thoughts?

justsomehnguy 3y ago
GP wants not to self host yet wants to have the control. Though what you described is just a regular federated identity workflow, except autodiscovery through DNS (though that is already a thing for some)