[HN Gopher] Petnames: A humane approach to secure, decentralized...
___________________________________________________________________
Petnames: A humane approach to secure, decentralized naming
Author : todsacerdoti
Score : 130 points
Date : 2024-11-24 14:38 UTC (1 days ago)
(HTM) web link (files.spritely.institute)
(TXT) w3m dump (files.spritely.institute)
| freeone3000 wrote:
| I propose an implementation of these petnames by sharing
| directory access through mutually trusted brokers, whose identity
| is proven by certificates and whose location is discovered
| through a standardized directory service protocol. I think we can
| make huge strides by working with the ITU here -- if we can
| convince them IP is the next big thing, then we might not end up
| being chained to the OSI netstack for the first release.
| lann wrote:
| Sarcastic replies can be fine. Sarcastic replies when you
| clearly didn't read the article are just annoying.
| freeone3000 wrote:
| It's proposing a decentralized naming scheme, with nearly
| zero implementation details, with the idea that it works like
| split-horizon dns plus some undefined form of list sharing.
| Adding a bunch of cryptographic stuff to it doesn't really
| change the hard bits of discovery.
| woodruffw wrote:
| There 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 said, I think there's a pretty rich research
| space here, and I think the edge/local aspects of this design are
| pretty interesting! I just hope we don't end up with a
| reinvention of historically insufficient web-of-trust
| architectures :-)
|
| [1]:
| https://uhra.herts.ac.uk/bitstream/handle/2299/4349/904849.p...
| davexunit wrote:
| There's an associated paper that goes through implementing a
| petname system in a simple chat application. Petnames compose
| well with object capability security.
|
| https://files.spritely.institute/papers/implementation-of-pe...
| woodruffw wrote:
| That's great, but I don't think it addresses the basic point:
| sharing edge names requires a _way_ to share those names, and
| that 's a trusted third party (one with a degree of
| centralization, to boot).
|
| There are ways to (dis)intermediate that trust (like a PKI),
| but the shape of that PKI or other technique is itself a
| question of decentralization, security, etc. I think that's a
| _very hard_ underlying problem that the petname design needs
| to at least offer some opinions on in order to make claims
| about security.
| paroneayea wrote:
| Jessica Tallon's implementation of petnames and edge names
| was extremely simple within the paper davexunit linked, but
| used in-band mechanisms to communicate edge names that
| didn't require any sort of large trusted authority. You
| could retrieve them directly from fellow peers, who could
| publish their current set of edge names. This even works in
| a p2p context over ocapn, etc. The implementation was naive
| but it did work and used a publish-subscribe mechanism
| directly from other peers.
|
| That said, edge names are only one way to share contacts.
| In fact "share contact" on peoples' phones is a great way
| to have contextual sharing: "Oh, let me introduce you to my
| friend Dave. Here's Dave's contact info!"
|
| At any rate, petnames aren't a particular technology,
| they're a design space of "Secure UI/UX". However I do
| agree more research needs to be done in that space; we've
| only barely begun to scratch the surface.
| catlifeonmars wrote:
| > 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.
| woodruffw wrote:
| 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.
| catlifeonmars wrote:
| 100% agree about the difference in meaning between the two
| uses of "trust". To be frank I responded after only
| skimming over your comment, and should have read a bit more
| closely. FWIW, I think there's a way to unify those two
| realms: if you model boolean trust in terms of a random
| variable and sum over the transitive web a la binomial
| distribution.
| smatija wrote:
| 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-...)?
| gregmac wrote:
| 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 strong relation for exactly the opposite
| reason, unless maybe the first-degree contract is vouching
| for the person.
| catlifeonmars wrote:
| There's also a compounding effect. If multiple friends
| vouch for the same stranger that means something too.
| tobr wrote:
| > 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.
| dwallin wrote:
| 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.
| thomastjeffery wrote:
| > I trust my doctor and my doctor trusts their sibling, but I
| don't necessarily trust their sibling.
|
| Sure, but let's get back to the use case we are exploring here:
| Do you trust your doctor's _contact info_ for their sibling?
| Could it provide you utility? What about your doctor 's contact
| info for the front desk of their practice?
|
| What's important here is that the _subject_ of trust is
| explicit to whoever _attests_ that trust. If your doctor
| _intentionally publishes_ a list of known contacts, then it can
| be reasonably presumed that they know those contacts. This,
| along with the ability to attest falsehood, should be enough to
| replace traditional authority and moderation.
|
| I get into this more in my comment here:
| https://news.ycombinator.com/item?id=42238201
| woodruffw wrote:
| > Sure, but let's get back to the use case we are exploring
| here: Do you trust your doctor's contact info for their
| sibling? Could it provide you utility? What about your
| doctor's contact info for the front desk of their practice?
|
| Not inherently: for all I know, my doctor is technically
| illiterate and their contact book is thoroughly padded with
| spam.
|
| The problem of trust is that trust isn't a boolean; it's a
| set of policies that vary by principal and action. It's very
| hard to encode that in a truly general way, which is why
| modern cryptographic application design orthodoxy dictates
| that applications should try to solve _exactly one_ kind of
| trust at a time.
| thomastjeffery wrote:
| > Not inherently: for all I know, my doctor is technically
| illiterate and their contact book is thoroughly padded with
| spam.
|
| Sure, but that leads us to the next question: Could it
| provide you utility?
|
| > The problem of trust is that trust isn't a boolean
|
| That's also the utility of trust. Most of the information
| we want to reason about is _not_ context-free. So far, no
| one has figured out a reliable way to offload context-
| sensitive work to computation. The next best thing is to
| offload as much context-free work as possible, and provide
| the user a direct interface to the remaining context-
| sensitive work.
|
| By organizing our social networks as attestations of
| [dis]trust, we can deliver the uncomputable question of
| trustworthiness closer to the user. By delivering that
| question to many users, we can collaborate efficiently on
| that work.
| mglvsky wrote:
| I have crazy idea to produce mnemonic rules for every DID, maybe
| fancy-AI tech would help
| klabb3 wrote:
| 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".
| sneak wrote:
| I 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.
| JamesLefrere wrote:
| 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.
| fanf2 wrote:
| I have long been a fan of petnames, and graph naming systems in
| general.
|
| I like to use the term "nickname" for what they call "edge names"
| in the article: a nickname is not as personal as a petname, it's
| a name you share with others.
|
| An interesting thing that the article sort of hints at is that
| these kinds of systems have a fairly smooth range of operating
| points between globally unique and centralized vs decentralized
| petnames. The article's example of the bizdir local business
| directory is somewhere in between these extremes. It sort of
| turns Zooko's triangle into more like a fan, where the "human
| friendly" point is fixed and there's an arc describing the
| tradeoffs, from personal through local to global.
|
| How can a petname system function at the global+centralized
| point, so it could replace the DNS? It needs to pass the
| "billboard test": I type in a name I saw on a billboard and I get
| to the right place. (It might be a multipart name like a postal
| address or DNS name, with an extra "edge name" or two to provide
| enough disambiguating context.) I imagine that an operating
| system supplier might provide a few preconfigured petnames (well,
| it probably includes its own petname so the software can update
| itself securely), a lot like its preconfigured PKIX CA
| certificates. These petnames would refer to orgs like the
| "bizdir", or Verisign, or Nominet, that act as nickname
| registries. Your collection of petnames is in effect your
| personal root zone, and the preconfigured petnames are in effect
| the default TLDs. There would inevitably be something like the
| CA/Browser forum to mediate between OS suppliers and nickname
| registries: a petname ICANN.
|
| I wrote an older iteration of these ideas over a decade ago
| (https://dotat.at/@/2012-02-28-path-names-in-a-rootless-
| dns.h...). Those notes have a bit too much DNS braindamage, but I
| included some curious anti-DNS discussion: How you might make use
| of reaching names by multiple paths? What might it look like to
| have a shared context for names that is not global but is
| national or regional or local?
| RainyDayTmrw wrote:
| While watching some non-technical people use a web browser, I
| noticed that they tended to type the name of their intended
| destination - not the domain name - into the navigation bar. In
| effect, they had delegated the resolution of names to
| destinations to their default search engine - Google.
|
| How do we solve the "billboard test"? Delegating to mostly
| central, mostly trusted authorities gets us roughly on par with
| the current reality. More interesting is if we could then
| diffuse this authority by having multiple resolvers and
| combining them. The details - how to combine results, how to
| resolve divergences, and results changing over time - could be
| tricky for UX.
| skybrian wrote:
| Contact 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 want, or people are
| going to end up re-rolling until they get a "nice" number, and
| then there's competition for nice numbers just like in other
| namespaces.
| 0perator wrote:
| 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.
| skybrian wrote:
| Good answer. But I'm wondering how well this works when a QR
| code resolves to a meaningless string of digits?
|
| I suppose most people don't check URL's anyway, and for some
| URL's the domain name is fairly meaningless. Still, it seems
| like something is lost, at least for techies, when you can't
| see and recognize usernames and domain names?
|
| Consider how programming languages work. Who wants
| meaningless numbers in their import statements or
| package.json file? Package names seem decentralized enough?
| Not sure it's worth throwing out to achieve True
| Decentralization.
| jdp wrote:
| Check out Backchannel[0] if you're interested in an
| implementation of a petname system for globally-unique symmetric
| cryptographic keys.
|
| [0]: https://www.inkandswitch.com/backchannel/
| EGreg wrote:
| So, a malicious entity can poison the petnames that others see,
| but only if prefixed by their own first? So people will learn not
| to trust them, I guess... but as usual with trust, they can be
| 99% correct and poison a specific one (eg claim a certain number
| is a well-known rich guy, and impersonate them)
|
| The bigger issue is that people will need to be careful not to
| give embarrassing or compromising nicknames to people in their
| addressbooks.
|
| I had considered using these personal contact list display names
| as default names for when people accept invites, but the problem
| is that they'll know the inviting user had them as "that crazy
| pooky bob"
| snthpy wrote:
| 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
| _heimdall wrote:
| Spritely 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.
| archi42 wrote:
| Contacts 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.
| alphazard wrote:
| A contacts list is a superset of the publicly available
| connections that would make up a web of trust. Out of all my
| contacts, there are a few people that I would be willing to
| vouch for. As in: declare publicly that I know who they are,
| and reveal the name that I refer to them as.
|
| That pet name may be different from person to person, but
| that's fine. Alice might call a public key "Bobby's Public
| Key", and Charlie might call it "Robert's Public Key". I can
| make sense of those attestations when I'm trying to verify that
| I have Bob's key, and assign it my own pet name. If Alice or
| Charlie weren't willing to publicly attest to the Bob-ness of
| the same public key then I wouldn't be looking at their
| attestations.
| elbasti wrote:
| To reinforce the real-world value of contact secrecy, let me
| share an example of how WhatsApp's contact broadcasting is
| creating massive opportunities for scammers where I live
| (Mexico).
|
| In WhatsApp, when you join a "community" (sort of like a giant,
| moderated group), all members of the community are visible to
| all other members. You can see their phone numbers and their
| self-chosen nickname. Note that very frequently people will
| have their names or a shortened version of their name as their
| nickname.
|
| In emerging markets, people use WhatsApp for _everything_ and
| many people will naturally join a few communities. Things like:
|
| - A community for your kid's school
|
| - A community for your neighborhood's safety alerts.
|
| - A community for a club or hobby.
|
| So a scammer's workflow is as follows:
|
| 1. Infiltrate a community or a group.
|
| 2. Check all of the members and find those whose names are
| publicly shared or you can deduce.
|
| 3. Use their name, phone and--crucially--information about the
| community itself to craft a targeted phishing phone call.
|
| Example:
|
| Sandra is a part of a community for neighborhood safety news.
| The community is called "Hillsborough safety." Her whatsapp
| nickname is "Sandy Williams."
|
| A scammer will join the community and see her contact. They
| will then call her with a message like "Hi, is this Sandra
| Williams? Yes, I'm calling from the Hillsborough police
| department. Unfortunately there's been an accident with your
| husband...".
|
| You can imagine how the simple fact of knowing someoen's name
| and some sort of "proprietary knowledge" (they know I live at
| Hillside!) can be enought to for a victim to lower their
| defenses.
|
| An additional layer to this is that often the scammer will
| social-engineer their way into gaining access to the victim's
| Whatsapp account itself. They can then access all of the groups
| that victim was a member of, including "tight" friend groups,
| etc.
|
| IMHO contact broadcasting is an inexcusable design decision by
| WhatsApp.
| eterm wrote:
| Yes, I think this was a really bad example, and something
| without humans would have been better, so for example naming of
| cloud server resources.
|
| With real world names there's also the messy issue of name
| changes and dead-naming. If Alice changes her (his) name to
| Bob, but Eve keeps Alice in as Alice, you'd have mutual
| contacts seeing still referring to Bob as Alice.
|
| There are also of course the privacy concerns you mentioned,
| despite any optionality of sharing contacts.
|
| Here's a problem that this does potentially solve:
|
| "Two different cloud orchestrators need to be able to create
| servers which may get referenced by servers they each create.
| Coordinating unique names would be difficult".
|
| Although that's an odd problem, and it's already solved in a
| similar way by other hierarchical naming structures with
| authorities such as domains, which is essentially what this
| pattern is describing in a roundabout way.
|
| "com" names everything under it. "example.com" names everything
| under that, etc. Multiple different paths can point to the same
| resource.
| eximius wrote:
| This complaint and thinking of other simple but sliiiightly
| more advanced permission/privacy systems reminds me of G+
| circles - kinda wish it'd have taken off. I thought it was a
| pretty neat system.
| thomastjeffery wrote:
| > Else this is a privacy nightmare waiting to happen: It's easy
| to accidentially share numbers.
|
| That's a critical implementation detail, but I think it can be
| done. All we need to do is make contact-sharing an explicit
| feature.
|
| > But that's essentially re-inventing social networks with a
| narrow focus.
|
| Yes it is. That's the utility of decentralized networks: by
| removing the hierarchy from the network, we have removed the
| _explicitly drawn context_. Instead, the context is implicit
| and flexible. There are pros and cons to this feature. Instead
| of segmenting "twitterverse", "facebookverse", etc.; we simply
| have "the universe". The same boundaries can be replicated, but
| the lines are drawn by the users instead of by the platform,
| all while preserving compatibility across those lines.
|
| My answer to this change is to replace moderation with
| curation. I get into this distinction more in my comment here:
| https://news.ycombinator.com/item?id=42238201
|
| As far as privacy in curated networks goes, I think we could
| find some interesting strategies to accomplish it. One could be
| anonymous pseudonyms: publish the attestations you don't want
| traced back to you as an explicitly not-you user. Another could
| be attestation laundering: provide a publicly available user
| (that anyone can use) that publishes a collection of
| attestations as if it was the original publisher, and let
| collaborators vote on that user's overall validity via
| attestation.
|
| Essentially, we must contend with the inverted hierarchy that
| decentralized networks are made of. It's definitely a change,
| but I think can provide a lot more utility than centralized
| networks provide today.
| nonameiguess wrote:
| A contact list actually seems to me like an abnormally _bad_
| example for other reasons, or I 'm way more atypical than I
| think I am and everyone else curates their contacts far more
| carefully. For me, the proliferation of spam means I'm never
| going to answer an unrecognized phone number, and thus enter
| everyone I ever expect to receive a phone call from into the
| list. The vast majority of the time, these are things like
| contractors coming to my house, a hand surgeon I visit for one
| injury and hopefully only one injury, a shop I take my car to
| hopefully once and only once. Numbers I received a call from a
| few times, possibly more than a decade ago. The fact they're
| still in my contacts list says nothing whatsoever about my
| level of trust in them and doesn't mean other contacts,
| especially my actual friends, should assume anything about
| their presence except that I received at least one phone call
| from them at some point and I was expecting that call.
|
| That's aside from the fact that contact lists are not
| reciprocal. Adding a number to your list and giving it a name
| doesn't mean the owner of that number has added you to their
| list. There is no guarantee whoever is on the other end of that
| number has any idea who you even are.
|
| This is also aside from the fact that phone numbers can be
| reassigned. That's an argument that I and anyone else as
| cavalier about their lists as me should be removing numbers
| more often, but outside of a fairly short time horizon, there
| is no guarantee that the person who owns a number you have
| listed as "Bob" is still Bob.
|
| These issues aren't unique to digital contact lists, either. My
| wife pulled a book off the shelf a few months ago I hadn't
| opened in a very long time and found an old sheet of paper I'd
| written some phone number on, possibly 25 years ago? One was a
| very good friend from high school, a name I still knew and a
| number I still recognized as her parent's home number from the
| late 90s. The other, I have absolutely no idea. Probably some
| designated driver for a group of friends I was going to a party
| with who were going separate from me in case I needed someone
| to call if something came up. I may have never even called that
| number or received a call from it.
|
| Hell, how many contacts of people in their early 20s are
| someone you met in a club who gave you a fake phone number that
| happens to be some other person's real phone number?
|
| This bugs me to no end with all the apps out there for smart
| phones that want access to your contacts. Why? What
| significance do you think this list has? It's just a semi-
| random assortment of some sub-sample of all the people and
| organizations I have had some kind of fleeting and possibly
| one-time interaction with in the past quarter century. It
| doesn't imply I remember who they are, know them, or that I
| vouch for them in any way.
| RainyDayTmrw wrote:
| It frustrates me that domain names were designed to be a rival
| good, and that this has attracted so much attention from
| speculators, and the negative externalities that come out of
| that. I'm not sure what would be a good solution here.
|
| The existing design of domain names does have one important
| property, though. When someone successfully registers a name,
| they're guaranteed that they can pay a renewal fee - small, all
| things considered - and keep the name as long as they want -
| perhaps modulo legal and ToS concerns. This gives them assurances
| that they can invest into the branding of the name and keep the
| benefits.
|
| Compare that with search engine results. I mentioned elsewhere in
| this thread that I watched numerous non-technical users treat
| their browser nav bar as a name resolution mechanism -
| effectively delegating name resolution to their default search
| engine. Search engine results should change over time. If someone
| starts a FooBar Inc. in one industry, and someone else starts a
| bigger FooBar Corp. in another, who gets the "foobar" name?
|
| A sort of "pin on first use" would save existing users of FooBar
| Inc. New users trying to find FooBar Inc. might get confused
| though. FooBar Inc. would understandably be hesitant to print the
| "foobar" petname on their business cards and billboards.
| thomastjeffery wrote:
| This is excellent. I think it's only really missing one thing:
| curation.
|
| There is an example of _moderation_ : the bizdir business
| directory. This is really useful, since Dr. Jane Nym is able to
| find an explicitly trusted contact for Pizza Piano. The problem
| is that she isn't able to _implicitly share_ either the contact
| itself (Pizza Piano) or its source of trustworthiness (bizdir)
| with Ben Bitdiddle. In practice, this forces Ben to fallback on
| Caller ID, which is precisely the system we intend to replace!
|
| This is the failure of moderation in decentralized networks.
| Traditional moderation is founded on authoritative hierarchy,
| which is exactly what decentralization removes from the system.
| To replace it, we need a decentralized alternative to moderation.
| I propose _curation_ : each user curates their list of trusted
| contacts, and publishes it as a list of attestations. The bizdir
| business directory could actually be a good example of this, so
| long as we clarify some particulars.
|
| Consider "bizdir" as a participating user of the decentralized
| network. The bizdir user has published a list of attestations,
| including the contact for Pizza Piano. There is an opportunity
| here for Dr. Jane Nym to _replicate_ bizdir 's attestation of
| Pizza Piano, thereby solving the problem for Ben Bitdiddle
| without requiring his involvement. When Dr. Jane Nym calls Pizza
| Piano, she is implicitly validating it as a genuine contact. Why
| not make that explicit? At the end of the call, her
| petname/contacts app may ask if she trusts the number she just
| called; or she may have it configured to do so automatically. If
| she ever finds a reason to _distrust_ the Pizza Piano contact,
| then she can tell the app to publicly attest her distrust.
|
| So what's the difference here? Isn't bizdir functionally
| identical, whether presented as a curating user or an
| authoritative moderator? The difference is that, as a curator,
| bizdir is explicitly _redundant_. Ben Bitdiddle doesn 't need to
| interact with bizdir _at all_. He can benefit from it
| _secondhand_ via Dr. Jane Nym 's redundant "bizdir => Pizza
| Piano" attestation. On top of that, the validity of Pizza Piano's
| contact info has been attested to Ben _twice_ , which can only
| help to drown out any potential outdated or fraudulent Pizza
| Piano listings. This pattern can feed back into itself, such that
| Dr. Jane Nym would never have actually relied on bizdir _alone_
| as a source of trust, because many of Pizza Piano 's customers
| will have already publicly verified the same attestation.
|
| ---
|
| The utility of curation can extend anywhere we expect moderation.
| The greatest struggle for decentralized social networks is that
| they are immediately overcrowded by taboo content. Anyone who has
| been banned from traditional moderated platforms will try to
| build their home on your decentralized one; after all, one of the
| core features of decentralization is the circumvention of
| censorship. The problem is that most of the content that gets
| banned from centralized platforms is content that the average
| person is genuinely disinterested in. Just because we want to
| welcome free speech, doesn't mean we want to spend our time
| reading hate, watching trauma, or arguing with bullshitters. In
| order to make a space where regular people willingly participate,
| we must give users equal power to _not participate_. We can
| accomplish this with curation.
|
| Essentially, curation is a shift in strategy. Rather than
| demanding everyone accept the blatantly false attestation, "this
| content does not exist" (a moderator ban), we can collectively
| attest, "this content is garbage", and get back to sharing the
| rest.
| summm wrote:
| How does that differ from or relate to the already implemented
| GNS (GNU Name System)? https://www.gnunet.org/gns.html
| https://datatracker.ietf.org/doc/rfc9498/
| yamrzou wrote:
| Previous discussion:
|
| https://news.ycombinator.com/item?id=32497130 - Aug 2022 (28
| comments)
| robertlagrant wrote:
| This seems to be an explanation of what /etc/hosts is, but for
| TOR.
| graypegg wrote:
| This sort of reminds me of certificate authorities. A certificate
| authority is just a list of edges in this sense, and you
| inherently trust what the CA says are valid edges. (with some
| cryptography magic to verify it's really on the CA's list)
|
| You could make everyone their own "naming authority", so you
| could trust anyone's list if you choose to, but I would also bet
| we'd end up with a similar situation, where someone compiles the
| most names, and becomes a great default to use, so people don't
| spend much time cleaning up their own data, and things sort of
| naturally centralize.
___________________________________________________________________
(page generated 2024-11-25 23:01 UTC)