Voir la source de Rel-me

https://indieweb.org/rel-me 


à traduire sur [[iwc:rel-me-fr]]

{{stub-fr}}

Utiliser '''<dfn>rel=me</dfn>''' sur un hyperlien indique que sa destination représente la même personne ou entité que la page en cours, ce qui est une [[building-block|brique de construction]] clé de la [[web-sign-in|connexion web]] et d'[[iwc:IndieAuth-fr|IndieAuth]]. [[indieauth.com]] utilise les liens <code>rel=me</code> pour activer la connexion à l'intérieur de sites web tels que IndieWebCamp.com.

Voir la [http://microformats.org/wiki/rel-me spécification rel-me] pour plus de détails.

== Pourquoi ==
You should add <code>rel="me"</code> to hyperlinks on your home page to your other profiles to enable [[web-sign-in]] and [[IndieAuth]] using your domain as your identity, rather than depending on [[silo sign-in]] methods,

It also allows distributed verification - proof that an account on one site is under the control of the same person as another site. For example, [[Huffduffer]] will follow rel="me" links to show your connected social accounts without you having to enter them individually. Another good example of this is a [http://www.kevinmarks.com/distributed-verify.html browser plugin] built by {{kevinmarks}} which allows for this same kind of distributed verification.

== Comment ==
=== Comment utiliser rel me ===
See:
* [[How to set up web sign-in on your own domain]]
==== How to on WordPress ====
See:
* [[Getting_Started_on_WordPress#Rel-me|Getting Started on WordPress: rel-me]]

=== How to consume rel me ===
See: 
* [https://indieauth.com/developers IndieAuth for Developers: Using IndieAuth.com to sign users in to your website]

== FAQ ==
=== Should my rel-me be inside my hCard? ===
'''A:''' Another way of restating that is, should your <code>rel="me"</code> hyperlink also have <code>class="u-url"</code> and be inside your [[h-card]]? And the answer is:

'''A2:''' Yes it should, because it will enhance your h-card, and make it into a [[representative h-card]], but it is not necessary for rel=me to work with [[indieauth]].

'''Follow-up Q:''' This on my blog but it’s not actually what I use for my main indieauth, should it still be setup like that?

'''Follow-up A:''' Because it is on your blog, you're likely using that URL as your p-author h-card URL. Thus making sure it has a good representative h-card is a good idea

=== Can I add rel-me to non-profile pages?  ===

You should not add rel-"me" to pages that doesn't represent the same user as the profile the rel-"me" links to. 

One should only add rel-"me" to pages that is seen as representing the same user as the profile it links to. Such pages can be the home page of a single user site or the author pages of a multi user site.

[[rel-author]] is often what one wants instead when linking to a profile page from non-profile pages.

== Implementations ==
* '''PHP''' [https://github.com/indieweb/rel-me indieweb/rel-me] package has functions for getting rel=me URLs on a site, securely deriving profile URLs and securely matching silo backlinking URLs against profile URLs
* '''Ruby''' [https://github.com/aaronpk/IndieAuth/blob/master/lib/relparser.rb relparser.rb] (part of IndieAuth) contains functions for doing the same sort of stuff
* '''Python''' [https://github.com/bear/ronkyuu/blob/master/ronkyuu/relme.py relme.py] (part of Ronkyuu) contains functions to discover rel=me URLs on a site, generate normative URLs for both profile and resource URLs and to confirm that a resource URL is authoritative for a given profile URL.

== Connecting the dots between rel=me and relmeauth ==

This is my current interpretation - so people can correct and critique
it rather than assert any truthiness to this.

rel=me is intended to mean that the destination represents "the same
person as" the current page.

However, it also serves a dual purpose when used for [[RelMeAuth]]
based authorization. Here, a rel=me link really wants to mean the
destination "can claim control over" the current page. You could
instead pretend there's a "rel=is-controlled-by" tag to distinguish
the two contexts.

'''Why does this distinction matter?'''

A page such as github.com/kbsriram cannot (legitimately) claim a
rel=me link to github.com. Clearly, the site "github.com" does not
represent a "person who is the same as" github.com/kbsriram

However, the root domain on every website does control all its sub
pages, so in fact, github.com/kbsriram has an implicit
"rel=is-controlled-by" to github.com, but it does not have a rel=me
link to github.com

This distinction matters when finding rel=me closures in the two
contexts of identity consolidation and relmeauth based authorization.

To make this concrete, let's assume we have these three pages, with
these rel=me links on them.

    myfamily.example.com/tommy [rel=me] -&gt; {plus.google.com/+tommy}
    myfamily.example.com [rel=me] -&gt; {plus.google.com/+tommy}
    plus.google.com/+tommy [rel=me] -&gt; {myfamily.example.com/tommy}

=== Context 1: Consolidating Identities ===

Given a page, find me all the pages who are "the same person as" the
current page.

The approach is to recursively follow all the rel=me links from the
starting page, and return only that subset which is within any loop of
rel=me links that include the starting page.

This is so that only a group of mutually verifying pages are
returned, or anyone could simply claim they were
https://plus.google.com/+LinusTorvalds by putting a rel=me link on their page.

If we started from myfamily.example.com/tommy, we'd get back
    {myfamily.example.com/tommy, plus.google.com/+tommy}
as the pages who "are the same person as" myfamily.example.com/tommy

And If we started from myfamily.example.com, we'd get back just
    {myfamily.example.com}


=== Context 2: relmeauth based login ===

Given an page, find me all the pages "who can control" the current
page. The "current page" is used as the username, and one of the
controlling pages is used to login the user, say through OAuth.

In principle (though implementations don't necessarily do this) the
approach is still similar, but now there is an implicit assumption
that any subpage of a domain is controlled by the bare domain.

In particular, the set of all pages "who can control" myfamily.example.com is

    {myfamily.example.com, plus.google.com/+tommy, myfamily.example.com/tommy}

because of the implied link that myfamily.example.com/tommy is-controlled-by
myfamily.example.com


== Edge Cases ==
Edge cases are questions or issues brought up typically by only one (or a small number) of people, and in practice affect very few people. We document them anyway in the hopes of helping out those few, yet apart from the broader [[#FAQ]], keeping the FAQ focused on ''frequently'' asked questions (applicable to more people in general).

=== What About RDFa Problems ===
If you use RDFa and are having problems, note that RDFa redefines 'rel' attribute processing that is incompatible with the HTML(5) standards thus rel=me may produce unexpected results inside RDFa.[http://microformats.org/wiki/rel#RDFa_Incompatibility]

There is a solution available in RDFa WG mail archives http://lists.w3.org/Archives/Public/public-rdfa/2014Oct/0005.html

<blockquote>
Any non-CURIE (e.g. "me") will be ignored in a @rel if
there is a @property attribute in the same element. Here is what I
recommend to use, which simplifies your markup as you don't need to repeat
the mailto:. Drop the @rel from the ul, and use something like this:

<pre>
<ul vocab="http://schema.org/">
  <li>
    <a rel="me" property="contactPoint" typeof="ContactPoint" href="mailto:
perpetual-tripper@wwelves.org"><span
property="name">email (smtp)</span></a>
  </li>
</ul>
</pre>
</blockquote>

== See Also ==
* [[microformats]]
* [[web-sign-in]]
* [[IndieAuth]]
* [[verify-me]]
* [[verified]]


[[Category:building-blocks]]
[[Category:microformats]]