Seems like a typo here that affects the meaning:
> Even though Ben is trusting that caller ID is correct, he can't imagine any reason why someone would be trying to phish him to authorize a topping change
Petnames: A humane approach to secure, decentralized naming
21–30 of 50 posts
Re: Petnames: A humane approach to secure, decentralized naming
#22There are some niceties here, but I think this is a little thin on the security aspects of the scheme: it's not clear how users establish the authenticity of transitively received petnames, for example. More fundamentally, there's a factor outside of Zooko's triangle: trust isn't really transitive[1]. I trust my doctor and my doctor trusts their sibling, but I don't necessarily trust their sibling. With that being sa…
> I trust my doctor and my doctor trusts their sibling, but I don't necessarily trust their sibling.
Isn’t that because that’s a different type of trust? For example, you trust your doctor to give you decent medical advice, and they trust their sibling for emotional support. That doesn’t mean their sibling will be supportive of you, or give you good medical advice.
Re: Petnames: A humane approach to secure, decentralized naming
#23I think perhaps the PoW/PoS solution to byzantine generals (as used by Ethereum, for example) can and does solve the Zooko's triangle problem via things like ENS. I don't anticipate that end users will be able to ingest or cope with the mental model involved with the correct usage of the system described in TFA.
Funnily enough Nikolai (original creator of ENS, now passed) worked on this idea https://github.com/nmushegian/namepet
ENS is still used for personal identities, and afaik still doesn't care about immutable paths. A wasted opportunity.
Re: Petnames: A humane approach to secure, decentralized naming
#24Earlier quoted context omitted.
> trust isn’t really transitive Not sure I agree with this. Sure, trust might drop off pretty quickly (like an inverse square law), but I would still trust a friend of a friend over a complete stranger.
I'd argue "friend of a friend" is strong transitivly because it's explicitly chosen by all parties involved. Trust in a professional relation - a doctor, especially - is actually very strong, because of the professional requirements to be trustworthy, and the protections built into that (being held accountable by an organization and/or lawsuits). "Family of friend" or "family of professional" isn't necessarily a stro…
There’s also a compounding effect. If multiple friends vouch for the same stranger that means something too.
Re: Petnames: A humane approach to secure, decentralized naming
#25Earlier quoted context omitted.
> trust isn’t really transitive Not sure I agree with this. Sure, trust might drop off pretty quickly (like an inverse square law), but I would still trust a friend of a friend over a complete stranger.
I would also trust a mutual friend over a complete stranger. But that's not the point of the observation: the observation is that "trust" isn't a boolean, but an umbrella term for a wide range of policies that we apply to different principals. Or in other words: transitive trust is a thing, but it's of a different color than "trust." Attempts to gloss over this in web-of-trust designs have historically not gone well.
So you can trust friend of a friend only after awaiting him (with apologies to https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...)?
Re: Petnames: A humane approach to secure, decentralized naming
#26Spritely is doing some interesting research and I appreciate the focus on fundamentals rather than shipping features immediately.
What always stands out to me with any project attempting decentralized social media, though, is how complex it becomes compared to RSS feeds.
The one requirement of content being push based rather than pull based has so many downstream effects, and its often goes overlooked or unspoken.
Re: Petnames: A humane approach to secure, decentralized naming
#27There are some niceties here, but I think this is a little thin on the security aspects of the scheme: it's not clear how users establish the authenticity of transitively received petnames, for example. More fundamentally, there's a factor outside of Zooko's triangle: trust isn't really transitive[1]. I trust my doctor and my doctor trusts their sibling, but I don't necessarily trust their sibling. With that being sa…
> I trust my doctor and my doctor trusts their sibling, but I don't necessarily trust their sibling. Isn’t that because that’s a different type of trust? For example, you trust your doctor to give you decent medical advice, and they trust their sibling for emotional support. That doesn’t mean their sibling will be supportive of you, or give you good medical advice.
Yeah, this is one of the big issues with digital peer trust networks. Trust in human interactions is fuzzy and very conditional, which is hard to collect, represent, and update in a user friendly and low effort way. Hence we tend to collapse it to a single, often-binary, trust score.
Re: Petnames: A humane approach to secure, decentralized naming
#28I have crazy idea to produce mnemonic rules for every DID, maybe fancy-AI tech would help
Too much entropy. Any 128bit+ thingy with global uniqueness, whether it’s a hash or guid or public key, doesn’t matter. It’s not ever going to be memorizable for mortals.
You can generate novelty nonces for the first X chars, but you will eventually get mumbo jumbo, at which point it’s never gonna be a “good name”.
Re: Petnames: A humane approach to secure, decentralized naming
#29Contact lists do work and are okay for friends, but businesses also need to publish contact information. What do you put on a sign, on a business card, or in an advertisement? You'd need to print the underlying id number, which makes it part of the UI. Inevitably, people are going to want something like a 1-800 number, perhaps with a mapping to letters that are easy to remember. Either you can pick the number you wan…
QR codes for canonical addressing could solve the publishing problem, with customization of how the QR code appears being a feature for advertising and marketing. Once the canonical address has been accessed once, it could be pet named by the accessing user.
Re: Petnames: A humane approach to secure, decentralized naming
#30Contacts are just a toy example, aren't they?
Else this is a privacy nightmare waiting to happen: It's easy to accidentially share numbers. Also it might turn out your new friend J. is superficially pleasant, but actually a horrible human being once you get to know them - congratulations, J. has access to all your shared contacts. If I was friends with Alice, I'd be very annoyed that J. is now harassing me.
Or suppose you created a list of all doctor's phone numbers in your area. You can then look up if any of your contacts (friends, family, loose aquintance) share any of them (e.g. because they recommended a specialist to a friend).
This needs a tremendous work to setup access rights, and it's easy for an individual to screw this up and put themselves in a bad spot.
Sharing contacts on a need-to-know basis (using e.g. Threema or WhatsApp) is the established standard in my peer group; be it the number of a Pizza place or my SO's new number, so a common friend can invite her to a party. And while it's less cool and adds some effort, it requires an explicit action to share a contact. This is more safe.
In my humble opinion, and I might have a bad hunch there: The overall mistake with that example is lies in how it associates identities with phone numbers. In reality, it's the other way around. We want to share identities (be it the Pizza Place, Mum, or a doctor), and should have control who can access the information (not just phone numbers) associated with them. But that's essentially re-inventing social networks with a narrow focus.
From a academical perspective the technical issue can be interesting of course, and valuable insights might be gained from this research. There might be use cases beyond the basic contacts example; in fact, I think in a company phone directory this can be incredibly useful as part of the CRM.