Domain-identifiers

From Federated Social Web Incubator Group
Jump to: navigation, search

This article is a stub. You can help the federatedsocialweb.net wiki by expanding it.

domain identifiers

In common practice since blogs took off in the early 2000s, numerous individuals (both technical and non-technical) use their blogs (effectively their domains) as their identities.

In SWAT0, we deliberately want people to be able to identify themselves by this common practice. This page is for exploring how.

representative hCard discovery

Starting with "tantek.com" or "@tantek.com":


  • but how do you get a salmon endpoint from the hcard ? --Eschnou 19:44, 23 July 2010 (UTC)
    • representative hCard == page for that person, use page-level discovery. e.g a link rel=salmon (per Salmon section 3.1) to the endpoint would suffice. — Tantek 22:57, 23 July 2010 (UTC)


In short, since WebFinger currently doesn't allow for domain level only identifier, we can do this instead:

  1. if given a domain level identifier, retrieve the representative hCard from that domain and use it.
  2. else do WebFinger
  • ^^^ I don't like this. Why introduce a secondary flow ? I'd rather use only one flow ...
    • It is more important to keep simpler user scenarios simple for the (indie-web) user, than "use only one flow" as a coder/parser/consumer. Also, WebFinger folks are welcome to adopt/incorporate step 1 and then again you have one flow.
  • and webfinger will become key later anyway when we'll have to discover PoCo profiles,
    • no need for a PoCo profile - you already have the hCard
  • public keys
    • hCard has a 'key' property that can be used to publish public keys
  • In fact, I think that if the domain is a single user domain, then hostmeta XRD could directly contain the user specific data (e.g. salmon link).
    • Why prefer a more complex XML side-file solution when the page itself can contain the user specific data (e.g. salmon link)?
  • I would discuss this on the webfinger mailing list. --Eschnou 19:44, 23 July 2010 (UTC)
    • From having discussed the indie-web single user domain scenario with Blaine and others who seem to dismiss it in preference to oligarchy account scenarios, I'm not optimistic about the return on time investment of participating in the webfinger mailing list. So instead, we can work around the complexity of webfinger by doing the simple solution first, complex webfinger second. — Tantek 22:57, 23 July 2010 (UTC)
    • Agreed - webfinger is horrid and ugly. It also fails when the social software is installed in a sub-domain and perhaps one doesn't control the top level domain. I've already implemented a fallback which is much more lenient and allows the service endpoints to exist as link relations on the profile/identity page - where they belong. Webfinger support was only for interoperability. But I also allow service locators such as "mike@example.com/subdir". Might wish to consider pushing these edge cases in webfinger, but like Tantek, it will have to be somebody else pushing it. Macgirvin

related