On 6/18/06, Colin Davis <Colin at sq7.org> wrote: > Hrmm.. > > For one, keep in mind that these names are for the User's beneifit, not > the node's... In reality, "Charles"'s nodelist is a unique USK, at > USK at XCVNDFJGGSSDGSDG... > > So that means that the User might get confused, but the node knows the > difference between them. > > Because the node knows the difference between them (the node knows teh > difference between the charles that Alice added, and the charles Bob > added, since the File includes the original USK), you can prioritize- > You can tell the name resolver to draw from the lists in in order of > their place in the file.. So if you have > > > Alice USK at SDASD > Charles USK at BBBBBB > Charles USK at SDGSDGSDGSDG > Bob USK at SDFBJISDG > > > Your name resolver will trust the top one more than the second, and so on. > > Doing it that way automatically passes the order on to the people > subscribed to your list.. They inherit your trust relationship, and your > priority by default. > > > I think in practice, link pages would end up being uniquely named. > Do you have a better suggestion, without giving each node a user-facing > generated number?
Nope. Propogating prioritizations was the best I could come up with on short notice. Or expose directory structures, like Alice/Charlie/somesite and Bob/Charlie/somesite, but that seems worse. Prioritization does mean that different people will have Charlie/somesite resolving to different locations, though. Which means I can't necessarily assume I can give it to someone on a business card... In the extreme case, this enables a redirection attack if people high up in the list decide they don't like someone. And most users would never notice it in all likelihood, so it's hard to police. I don't see a good answer to these problems, unfortunately. Keep thinking, though, it's well worth pursuing. (Actually I do have one idea on it, I'll give it some thought and post if I still like it). Evan
