Email or username:

Password:

Forgot your password?
Top-level
Christine Lemmer-Webber

my precise opinion on this matter is *blood begins pouring from every pore of my body and begins filling the room*

23 comments
Christine Lemmer-Webber

Regarding "AT was written because ActivityPub can't handle portable content and identity", I wrote up stuff about this *in 2017* github.com/WebOfTrustInfo/rwot and wrote a demo on how to do the portable content part gitlab.com/spritely/golem/blob

Good luck to the Bluesky / AT folks, truly. The main thing that frustrates me is this claim that AP can't do this though. (The Bluesky folks are aware of this, we both wrote some documents about it together, so they *should* know, that's my main irritation with the FAQ item that says ActivityPub can't do it.)

But also:

- I am not currently focused on ActivityPub so maybe it's not the best question to direct at me anymore
- I am focused on Spritely, which will eventually loop back to AP stuff, but that's not its current focus (it's a bit more general and dare I say a bit more revolutionary to how applications are written than that)
- I have never been interested in making a Twitter replacement because I am not convinced a global content space is necessarily a good idea
- It's good that almost everyone agrees that decentralized networks are fundamentally necessary now though
- I am glad that AT/Bluesky is using DIDs and some other components that really might be truly useful
- I am not the best person to ask this question, but I guess I am one of the most obvious people to ask this question

Regarding "AT was written because ActivityPub can't handle portable content and identity", I wrote up stuff about this *in 2017* github.com/WebOfTrustInfo/rwot and wrote a demo on how to do the portable content part gitlab.com/spritely/golem/blob

Григорий Клюшников

The portable identity people always, inevitably forget one simple truth: the identity and the means of accessing it should be separable. I've explained them way too many times that a public key is not a viable form of identity. They still keep insisting on using public keys as identifiers.

The fatal flaw of the use of cryptographic keys for identity is that
- Once leaked, it can't be revoked to prevent further unauthorized access and impersonation
- Once lost, it can't be recovered and a new key pair, thus a new identity, is required

This stuff is non-negotiable really. I worked at VK, they have an entire department dedicated to restoring people's access to their accounts. People are terrible with passwords and they will be even more terrible with private keys.

The portable identity people always, inevitably forget one simple truth: the identity and the means of accessing it should be separable. I've explained them way too many times that a public key is not a viable form of identity. They still keep insisting on using public keys as identifiers.

The fatal flaw of the use of cryptographic keys for identity is that
- Once leaked, it can't be revoked to prevent further unauthorized access and impersonation
- Once lost, it can't be recovered and a new key pair,...

Olivier Forget

@grishka @cwebber The thing about private keys is that you have to tell people:

- don't lose it ever so make backups
- make sure nobody ever gets to see it

These two things are hard to do together, particularly for non-tech people.

Chris Messina

@teleclimber @grishka @cwebber Like most technical decisions, it requires a set of tradeoffs that exist in the context of a broader society, much of which is not technically literate, and which does not [currently] have the time, attention, motivation, or interest to care about these subtleties.

Only once they've fucked themselves by losing their keys do they suddenly care, when it is too late.

And we just have to assume this is our social operating environment, forevermore.

Eunakria

@teleclimber @grishka @cwebber it's hard to do even for tech people! I'll be the first to admit that my SSH key backup solution is a fucking disaster

Jeff Martin

@grishka yeah! I'm trying to design a decentralized identity system and I keep struggling with this problem too. If the using the pubkey as the identity is the problem, then what's the solution? And solutions that appeal to some centralized authority to resolve the issue aren't allowed, because, well ... decentralized. How can we do better?

Григорий Клюшников

Jeff, as far as I'm concerned, it's a fundamentally unsolvable problem. The best mostly-decentralized identity systems we have (email, ActivityPub) ultimately rely on DNS.

Jeff Martin

@grishka That's what I was afraid of. It does seem unsolvable. :blobcatverysad:

DID at least comes close to a reasonable solution here, because people get to choose which centralized authority they want to use (ie the resolvers), but most of those resolvers are blockchains. Ugh. There has to be a better way.

Océane 🏳️‍⚧️

@grishka @cuchaz @cwebber I think that this problem is currently bound to the State anyway so I'd argue for hardware tokens issued and replaced by the State, similarly to ID cards. We have until the revolution to figure something out

Mark W. Alexander

@grishka @cuchaz @cwebber
Step 1: Put whatever org coordinates international zip codes in charge of DNS.

Oh, and eliminate profit off DNS and domains.

Step 2: ???

Григорий Клюшников

Mark W. Alexander, as far as I'm aware, there's no such organization. Each country's postal service has its own zip code system without regard for international uniformity. For example, Russian zip codes map one to one to post offices. I was surprised to find out that it's not like that in other parts of the world. In some countries (UK and iirc Canada) zip codes even contain letters.

If you eliminate profit off of DNS and domains, how do you keep a scarce resource available to everyone? How do you prevent squatters from registering an entire dictionary worth of domains in every TLD and then extorting people? Current implementation at least tries to be fair.

Mark W. Alexander, as far as I'm aware, there's no such organization. Each country's postal service has its own zip code system without regard for international uniformity. For example, Russian zip codes map one to one to post offices. I was surprised to find out that it's not like that in other parts of the world. In some countries (UK and iirc Canada) zip codes even contain letters.

Mark W. Alexander

@grishka @cwebber
You can charge for services and still be not for profit. #ICANN did it for decades.

Which, also, managed domains pretty well for most of the growth of the Internet. It wasn't broke until capitalism shot it in the ass.

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

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.

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.

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.

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.

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.

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.

Jeff Martin

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

Dmitri | 🇺🇦

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

[DATA EXPUNGED]
Lucid00

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

Go Up