Text

· · zu lesen

Der Begriff POSH (ein Acronym für Plain Old Semantic HTML) geistert ja schon eine ganze Weile durch die Microformats-Community, aber dass es für POSH eine richtige Definition gibt und dass man zwischen POSHFormats und Microformats unterscheidet wahr mir neu…

Der Unterschied:

poshformats are data formats constructed from the use of semantic class names.

microformats are the proper subset of poshformats which have been developed via the microformats process and principles.

POSHFormats sind also alle Formate die zwar auf semantischem HTML basieren, aber nicht den Microformats-Prozess durchlaufen haben. Beispiele: Pavatar, hDOAP oder die MicroID.

Für diese armen Formate, die zwar teilweise echt großartig sind trotzdem aber keine Microformats sein dürfen, hat Toby Inkster jetzt mit poshformats.org ein eigenes Zuhause geschaffen.

(Ich musste schon ein klein wenig schmunzeln 🙂 )

Text

· · zu lesen

Vor ungefähr drei Monaten hatte ich mir schon mal Gedanken zu den Schwierigkeiten der MicroID-Verifizierung gemacht:

Eine URL kann man auf zu viele verschieden Weisen schreiben, als dass sie eine valide ID abgeben könnte.

Schwierigkeiten bereiten die Seiten, die unterschiedliche URLs zulassen…

  • http://example.com
  • http://www.example.com
  • http://example.com/

…da sie zusammen mit der E-Mail – Adresse drei unterschiedliche Hash-Werte ergeben.

Ein möglicher Lösungsansatz wäre eine URI-Normalisierung, wie sie z.B. OpenID vorschlägt, einzusetzen.

Eine viel einfachere und fehlerunanfälligere Lösung ist das dynamische zusammenbauen der MicroID über die direkt aufgerufenen URI als Identifier:

  • http://example.com -> 19358536d8c443614bc7d861f4b050ee34a549b9
  • http://www.example.com -> 05c732700bfa89cd234bb7fc08cb673f7c0d88b8
  • http://example.com/ -> 9275b4dcd7cc2c997b2a5249420b422e937d36e0

(Benutzte E-Mail – Adresse: mustermann@example.com)

Beim verifizieren bräuchte man sich also nur noch auf die E-Mail – Adresse konzentrieren anstatt alle in Frage kommenden URI/E-Mail – Kombinationen durchspielen zu müssen.

Text

· · zu lesen

Nach den Ankündigungen, dass myBlogLog MicroID für die eigenen Profilseiten einsetzt (bsp.: www.mybloglog.com/buzz/members/pfefferle/) habe ich mich gefragt, warum myBlogLog MicroIDs nur anbietet, nicht aber für die Verifizierung der Blogs verwendet.

Aber zuerst mal eine kurze Einführung. MicroID ist eine einfache Möglichkeit, den Besitz von Webseiten zu validieren.

MicroID enables anyone to claim verifiable ownership over content hosted anywhere on the web (social networking sites, discussion forums, blogs, etc.).

Das Prinzip ist einfach, es wird ein Hash-Wert aus zwei unterschiedlichen URLs (auch Pseudo-URLs wie z.B. „mailto:“ oder „xmpp://“ sind möglich) gebildet und als Metatag in die Webseite eingebunden.

hash = sha1(
    sha1( "mailto:mustermann@example.com" ) 
    + 
    sha1( "http://www.example.com/" ) 
  )Code-Sprache: JavaScript (javascript)

Alternativ zu sha1 kann z.B. auch MD5 verwendet werden. Der Aufbau des Metatags sieht folgendermassen aus uri+uri:algo:hash

<meta name="microid" 
  content="mailto+http:sha1:
    ba37d92454792b65838c9827a8d75171c7241924" />Code-Sprache: HTML, XML (xml)

Der Vorteil eines proprietären Formats im Gegensatz zu MicroID

Was die genauen Gründe dafür sind, dass myBlogLog ein eigenes Format verwendet weiß ich natürlich nicht, aber schaut man sich MicroID etwas genauer an, findet man doch einige kleine Problemchen.

Eigentlich ist es ja nur ein wirkliches Problem, und zwar die URL… Eine URL kann man auf zu viele verschieden Weisen schreiben, als dass sie eine valide ID abgeben könnte:

  • http://example.com
  • http://www.example.com
  • http://example.com/

Zusammen mit der E-Mail – Adresse mustermann@example.com bekommt man drei verschiedene Hash-Werte:

  • 19358536d8c443614bc7d861f4b050ee34a549b9
  • 05c732700bfa89cd234bb7fc08cb673f7c0d88b8
  • 9275b4dcd7cc2c997b2a5249420b422e937d36e0

Das heißt, es kommt immer darauf an wie der Benutzer seine URL bei einem entsprechenden Service angibt. Ist für den Metatag der Webseite http://example.com verwendet und beim Service http://www.example.com/ angegeben worden, kann die Webseite nicht verifiziert werden, da sich die Hash-Werte unterscheiden.

Lösungsvorschläge

Eine mögliche Lösung wäre alle denkbaren URLs auszuprobieren, was nicht sehr performant wäre und eine menge Zeit beanspruchen würde. Die (meiner Meinung nach) bessere Lösung wäre eine Art „service catalogue“ an, in dem festgelegt ist wie z.B. die von myBlogLog verwendete MicroID-URL aussieht.

Ein Beispiel: http://www.mybloglog.com/buzz/members/Username/

Das Problem bezieht sich natürlich nur auf Services/Communities, bei denen man keinen Einfluss auf die MicroID hat. Bei persönlichen Weblogs ist das natürlich was anderes, da die URL und der Matatag vom Benutzer selbst angelegt werden.

Falls jemand noch nen tollen Lösungsvorschlag hätte wäre ich sehr dankbar, weil ich MicroID trotz allem gerne einsetzen würde… Das Prinzip ist einfach so schön simpel 🙂