Den 5 jan 2015 15:47 skrev "Vincent Breitmoser" <<a href="mailto:valodim@mugenguild.com">valodim@mugenguild.com</a>>: > > > (This mail is a follow-up to its replied-to mail :) > > As mentioned, a user attribute packet is certified the same way a user id > is. This means we get certification including a timestamp for free, so the only > actual content we need in the user attribute is *where* the resource is located, > and possibly parameters on *how* to access it. > > An important aspect here is that a client will in most cases require specialized > support for a resource type, like parsing a tweet from twitter, a gist from > github, or reading a dns record. One way to refer to different resources would > be by introducing a type registry and have a parametrized packet structure for > each. This would be inflexible and difficult to standardize though, I think > having human readability for unsupported resource types will aid ease of > implementation, extensibility and lead to more transparent de facto standards. > > The established way to refer to a resource on the web is a URI. A generic URI > will not do in this case though, because that does not include the required > semantic implication about specialized client support. A good example is the > direct uri to a tweet on twitter, where the user only has partial control since > replies are shown on the page as well - a generic "parse page and look if the > data I want is there" mechanism will not suffice. My proposal is a new URI > scheme which bears this exact semantic, and supports additional parameters: > > pgpid = "pgpid" ":" [options] "@" <absolute-URI> > options = ( option / flag ) [";" options] > option = key "=" value > flag = key > key = *(ALPHA / DIGIT) > value = *(<unreserved> / <percent-encoded> / ",") What about data in locations without a defined URI format? I'm mainly thinking of profile entries in the Namecoin blockchain here, and other such lookup systems.