identifying accounts (was Re: Webfinger)

On 02/02/2015 12:11 PM, Evan Prodromou wrote:
> So you're saying you don't want to /require/ Webfinger, correct?
>
> I agree. I don't think we should require Webfinger. I think we should 
> support multiple different URI types for identities, both existing 
> ones and future ones.
>
> Some I think are possible are:
>
>   * Profile pages (http, HTML encoding)
>   * Activity Streams profile URI (http, Activity Streams encoding)
>   * RDF/XML
>   * Webfinger
>   * Just a domain
>   * Email address (mailto:)
>   * URNs (may especially be useful for proprietary namespaces, like
>     "urn:x-twitter:evanpro")
>   * tag: URIs
>

I'm feeling a little fuzzy about what this is used for.   Let me take a 
guess, and you can tell me if I've got it.

I'm thinking primarily, we just need an *opaque* string that 
unambigously identifies an account.   (Several of the above would do 
fine.   By being opaque, the client needn't know which it is.   For this 
purpose, the server could just use uuids or sequence numbers if it wanted.)

I figure clients would be given these account-identifier strings in some 
API operations (such as a list of accounts which have currently 
expressed a "like" of some photo) and use them in others (such as adding 
them to a contact-list, or asking for the associated name and profile 
photo).  For the purposes of the API, they are just strings.

But we'd also like to be able to use them outside this API.   So we make 
these identifier strings be URLs/URIs/IRIs.   This gives some ideas 
about how they can be used in general.

In fact, in the cases where they http(s) URLs, there are a bunch of cool 
things we can do.  (more below)


> How you go from e.g. mailto:user@example.com to a collection of user's 
> friends or the stream of the user's activities is dependent on that 
> URI system. Some will have well-defined systems for discovering them; 
> others won't.
>

(I have some questions about this, but they're probably a distraction 
for now.)

> For at least a few of these, we can provide link relation URIs that 
> will help in the path for discovery. "If you are looking for friends, 
> find the link relation 'http://example.com/social-api/friends'."
>
> That's the extent to which we should define discovery mechanisms.
>

I guess this is the cool thing.   As long as the account is identified 
by an http(s) URL, there are many ways the client can obtain information 
regardless of our API, or as part of our API.

In fact there are too many ways....   For example, we can express that link
   - in XRD
   - in JRD
   - in Turtle embedded in HTML
   - in Turtle served via con-neg
   - in JSON-LD (embedded or con-neg)
   - in some made-up JSON dialect
   - in a microformat
   - in RDFa
   - in Link: headers
   - in some made up XML dialect
   - in one of the other RDF formats like RDF/XML or Trig (embedded or 
con-neg)
   - ...  in impressionistic paintings on the head of a pin, probably

How are we going to pick amongst those?   Hopefully we can narrow down 
the list to a handful that we consider particularly 
popular/useful/well-designed.   For the sake of illustration, I'll 
nominate Link: headers and JSON-LD (both embedded in HTML and directly 
via con-neg).

Even if we can agree on three like that, then we have the question of 
who bears the burden of having more than one.  Does every server have to 
implement all of them, so that clients only have to implement one, or 
can servers just pick one, in which case every client has to implement 
all of them?

        -- Sandro

> -Evan
>
> On 2015-02-02 11:20 AM, ☮ elf Pavlik ☮ wrote:
>> On 02/02/2015 03:05 PM, Evan Prodromou wrote:
>>> I don't understand your objection.
>> I think JRD may but on us some unnecessary constraints. I'll take a look
>> at it and will highlight any possible issues I may notice!
>>
>>> Link relations are a great way to express relationships between
>>> entities, whether expressed as HTML or JRD. It's even supported as part
>>> of HTTP headers.
>> Sure, they may even become soon better aligned with Linked Data
>> https://github.com/mnot/I-D/issues/39
>>
>>> -Evan
>>>
>>> On 2015-01-31 10:50 AM, ☮ elf Pavlik ☮ wrote:
>>>> On 01/31/2015 04:33 PM, Evan Prodromou wrote:
>>>>> I think it's sufficient to define one or more link relations for Social
>>>>> API endpoints.
>>>>>
>>>>>       outbox
>>>>>       inbox
>>>>>       following
>>>>>       groups
>>>>>       lists
>>>>>
>>>>> That way different discovery mechanisms for different kinds of URI
>>>>> identifiers (http, Webfinger, etc.) will work fine.
>>>> -1
>>>>
>>>> I would prefer not to put limitations of JRD upon our work, and use
>>>> webfinger *only* as a way to get equivalent http: / https: URI for URIs
>>>> using other schemes acct: , mailto: , xmpp: etc.
>>>>
>>>> Then stating the actual relations (links/predicates) in JSON-LD document
>>>> representing particular resource.
>>>>
>