Email or username:

Password:

Forgot your password?
All posts Christine's posts Post Back to profile
Top-level
Dmitri | πŸ‡ΊπŸ‡¦

@cuchaz @grishka ok, but also, use DIDs (Decentralized Identifiers). Like, start with did:web (which is just a well-formatted JSON object that lives on a domain).

3 May 2023 at 19:45 | Wall-to-wall | Open on social.coop
9 comments
Jeff Martin

@dmitri @grishka DNS is technically disqualified here because it's a centralized authority. But despite that, it may be the best option we have. The trouble is, the DNS system isn't really accessible to most people, so the UX isn't great there.

Most of the other DID resolvers are blockchains (ugh), so I'm trying to find something better. It may not exist though. If we're not going to use pubkeys as ids directly, then something like `user@domain` may be the best we can do.

3 May 2023 at 20:03 | Open on gladtech.social
silverpill

@cuchaz @grishka @dmitri did:onion is like did:web but without external authority. If you want to support key rotation and avoid single point of failure, blockchain is probably the only way.

3 May 2023 at 20:19 | Open on mitra.social
Dmitri | πŸ‡ΊπŸ‡¦

@cuchaz @grishka I know, I don't think did:web is an ideal choice (even though I helped create it). But, I DO think a better DID method will be created in the next year or three. And the reason I recommend to use did:web now is -- you get used to the general mechanism and data model, and the moment a better method arrives on the scene, it is trivial to switch.

3 May 2023 at 21:26 | Open on social.coop
Lucid00

@dmitri @cuchaz @grishka

I imagine the solution will just be multiple keys that point to each other and domains that list them.

It's messy but it makes the most sense IMO.

4 May 2023 at 14:03 | Open on social.vivaldi.net
Jeff Martin

@lucid00 @dmitri @grishka Crazy thought I just had: What if we just play games with terminology to try to make things easier to understand?

The cryptographic keys can technically be an "identity" because that's the source of authority in the system that is in control of the person. And the name@domain can be an "address" because that's the source of authority that's under control of some external organization rather than the person.

The address isn't the person, it's merely where they're staying at the moment. It's how you can find them, but it can be changed. An identity can move to a new address and still be the same identity. Or in reverse, the organization might be convinced to accept a new identity as the resident of an address, if, say, the person loses access to their identity somehow. But if you move somewhere else, you can only take your identity with you, not the address. The address isn't yours.

@lucid00 @dmitri @grishka Crazy thought I just had: What if we just play games with terminology to try to make things easier to understand?

The cryptographic keys can technically be an "identity" because that's the source of authority in the system that is in control of the person. And the name@domain can be an "address" because that's the source of authority that's under control of some external organization rather than the person.

4 May 2023 at 14:25 | Open on gladtech.social
Dmitri | πŸ‡ΊπŸ‡¦

@cuchaz @lucid00 @grishka So, I definitely think you're on the right track. The thing about key being an identity, is that you can't rotate or revoke it! That's why it's so useful to add one more level of indirection. an identity points to one or more keys (which can be rotated / revoked without changing the identity). Which is exactly what a DID is -- just a string that points to a JSON object that has a bag of keys.

4 May 2023 at 14:39 | Open on social.coop
Jeff Martin replied to Dmitri | πŸ‡ΊπŸ‡¦

@dmitri @lucid00 @grishka It sounds like to me you just explained the same thing, but with different nouns in each place?

ie, the DID would be the "address". The bag of keys is the "identity". The DID method/resolver would essentially act as the domain.

Putting a name@domain on top of that is just involving a second layer of indirection and a second authority you must appease. Having two different layers of indirection and external authorities that must be appeased seems unnecessary.

Also, if organization can be convinced to accept a new identity for an address, that is the method of key rotation or revocation.

@dmitri @lucid00 @grishka It sounds like to me you just explained the same thing, but with different nouns in each place?

ie, the DID would be the "address". The bag of keys is the "identity". The DID method/resolver would essentially act as the domain.

Putting a name@domain on top of that is just involving a second layer of indirection and a second authority you must appease. Having two different layers of indirection and external authorities that must be appeased seems unnecessary.

4 May 2023 at 14:47 | Open on gladtech.social
Dmitri | πŸ‡ΊπŸ‡¦ replied to Jeff

@cuchaz @lucid00 @grishka So, yes and no. The DID is the identity. The keys are emphatically /not/ the identity. They are interchangeable methods for cryptographically confirming the identity. DNS / URLs are just one method of implementing DIDs, and there are many others.

4 May 2023 at 18:28 | Open on social.coop
[DATA EXPUNGED]
Lucid00 replied to DELETED

@Paulie @cuchaz @grishka @dmitri

"they have to keep that separate thing up to date just to login to see cat pics"

They don't, they could just login to see cat pics like most users are doing.

Also I'm not sure PGP failed, it's still in use.

Off topic:
We've really got to sort out the use of the word "failed" in tech.

"Failed" implies that PGP had some kind of success target to hit that it didn't beyond just providing the ability to encrypt stuff.

6 May 2023 at 3:41 | Open on social.vivaldi.net
Go Up