New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Webfinger for Actors #20

Closed
evanp opened this Issue May 3, 2015 · 40 comments

Comments

Projects
None yet
10 participants
@evanp

evanp commented May 3, 2015

No description provided.

@cwebber

This comment has been minimized.

Collaborator

cwebber commented May 3, 2015

I thought we agreed that this group would not be using webfinger, and would instead take a "follow your nose" type approach?

@aaronpk

This comment has been minimized.

Member

aaronpk commented May 8, 2015

I also thought we were going to follow-your-nose and use discoverable endpoints.

http://socialwg.indiewebcamp.com/irc/social/2015-03-18/line/1426710400225

@erincandescent

This comment has been minimized.

erincandescent commented May 8, 2015

Distributed social systems in the wild using user@domainname IDs:

  • E-Mail
  • XMPP/Jabber
  • SIP
  • OStatus/RStatus/Status.Net/GNU Social/Friendica
  • pump.io
  • Diaspora
  • Many more

I think it's quite telling that so many social networks have been designed using the same broad user-ID syntax. It's also exceedingly common for centralized networks to offer E-Mail address based "bootstrap" functionality.

I understand that there is a rather strong opposition to non-dereferencable URIs from some quarters of the working group, but I'm also quite certain that telling everybody to change their ID scheme to suite the requirements of our protocol will win us no friends. It should be considered that this protocol is "as simple as possible, but no simpler". I think the removal of support for user@domain IDs is a simplification too far. That said, they should not be mandatory - we should not mandate that sites use or expose such URIs - just permit them to do so.

Now, with regards to Webfinger, I'm ambivalent. There have been complaints about the need to parse a second JSON serialization format (though I'm of the opinion that said complaints are overblown - compared to the complexities of managing a distributed social network or accurately scraping tags out of HTML, parsing JRD is trivial), but I'm not deeply attached to it. I certainly don't think we have to use WebFinger for translating such names, but I certainly think we should have some support for such names.

My original ActivityPump drafts had the compromise that:

  • All objects must have https "id"s, except for users/actors, which MAY have acct URIs
  • In any case where a user object is represented, and its' ID is an acct: URI, then it MUST contain a link rel="self" to the URI at which said user object can be obtained

This leaves the one case in which it is necessary to dereference an acct: URI to be the case where a user enters a user@domain ID into the user interface.

I myself would prefer my URI to be "https://owenshepherd.net" - perhaps shortenable to "owenshepherd.net" by some normalization rules. On the other hand, contemplate a corporate deployment. Are their staff really supposed to remember their ID is "https://social.example.corp/john.smith"? In the unlikely event that a company like Google were to deploy ActivityPump, are they supposed to give people addresses like "https://user.name.gmail.com"?

For such cases, aren't user@domain IDs just easier? Aren't they what people already know and use?

user@domain IDs are preferred in some areas for very deliberate reasons. We should absolutely minimize their impact on the spec. We should absolutely use "follow your nose" and dereferencable URIs for the vast, vast majority of cases.

But, in my opinion, we absolutely should support them,

@kevinmarks

This comment has been minimized.

kevinmarks commented May 8, 2015

Google used to support http://profiles.google.com/{gmail id} e.g. http://profiles.google.com/kevinmarks (which still works because they added redirects for those who registered them).

@erincandescent

This comment has been minimized.

erincandescent commented May 8, 2015

Sure. Are you really expecting Real People (TM) to remember that their "ID" is http://profiles.google.com/myname?

@kevinmarks

This comment has been minimized.

kevinmarks commented May 8, 2015

They remember twitter handles and Facebook names, both of which are URLs https://twitter.com/kevinmarks https://www.facebook.com/kevinmarks and maybe even https://plus.google.com/+KevinMarks They remember the urls of their blogs: http://epeus.blogspot.com or http://kevinmarks.tumblr.com
they're as likely to forget their emails, as seen in https://xkcd.com/1279/

@erincandescent

This comment has been minimized.

erincandescent commented May 9, 2015

Nobody remembers their twitter or Facebook URI; they're "@oshepherd" on twitter and on Facebook (Seriously, nobody has ever given me a Twitter or Facebook link except for in the rare case they're copy and pasting it because we are interacting by PC). As for Google+, nobody has ever sent me a Google+ link (Sure, I've seen links on websites, but people who run their own websites tend to be the kind of people who remember technical arcana anyway).

As for Tumblr, I have no idea there but I suspect people remember that "I'm myname on tumblr", not that their URI is "http://myname.tumblr.com/".

The fact that people have so much trouble remembering their E-Mail address should be good argument for not making them remember yet another arcane address. Actually, more arcane: Now I have to remember if they are "site.com/name", "name.site.com", or something even more arcane like "site.com/~name", "site.com/+name", "site.com/user/name" or "social.corp.com/name".

The triumph of the E-Mail address is that everyone to a very, very good approximation is "name@domain.tld". That still leaves a lot of margin for error (what was the TLD again? etc), but it's about as good as we can get it.

@xray7224

This comment has been minimized.

Collaborator

xray7224 commented May 11, 2015

I'm inclined to agree that the email address format is much easier for people to remember as it's ubiquitous, every site (Tumblr, Facebook, Google, etc.) either ask you to provide one or provide you one with your account. I would say email is the lowest common denominator as it's required virtually everywhere.

People however, do seem to find Tumblr and Facebook works just fine, I suspect that is because they are centralized networks and I wonder how easy people would find URIs opposed to just their username on a federated network, which this must work for.

The Working Group however has said that we are going a follow your nose style like @aaronpk linked to. If you would like to have Webfinger supported again it would seem to me that that decision needs to happen in the WG.

@evanp

This comment has been minimized.

evanp commented May 11, 2015

I'm confused; I think Webfinger should count as "follow your nose", since you can discover all the endpoints using Webfinger.

@akuckartz

This comment has been minimized.

akuckartz commented May 11, 2015

Mail addresses are very important for onboarding purposes. That alone is enough reason to have a close look at how they can be integrated. (I suppose there is a user story for that.)

@xray7224

This comment has been minimized.

Collaborator

xray7224 commented May 11, 2015

@evanp I believe in the F2F in Boston it was explicitly a decision for "follow your nose" over webfinger, those being mutually exclusive. My interpretation was that with "follow your nose" a dereferenceable URI is used that allows you to discover the user's endpoints.

It would be great if this could be clarified by the WG to what was meant by that proposal.

@evanp

This comment has been minimized.

evanp commented May 11, 2015

The difference was between "follow-your-nose" and having fixed URL patterns (like "/user/{nickname}/following").

@cwebber

This comment has been minimized.

Collaborator

cwebber commented May 11, 2015

Okay, we should talk about this on the call. I think I'm beginning to understand the confusion though.

This was made more clear to me by reading this email thread:

Remember, this is about using the URI as a name rather than
data locator or access mechanism. That's the reason my acct: is required.
Basically, follow-your-nose linked data traversal (with alternative URI
resolvers hooked in via host-metadata pattern usage) without unintended
consequences i.e., de-reference the next chunk of data etc...

and

It uses a combination of "follow your nose" and the "well known" pattern.

Okay, so... a good portion of this group kind of thinks that "http/https URIs are the only URIs" and starting from that assumption, what can and can't be Follow Your Nose is pretty restricted to just HTTP/HTTPS URIs. But that's not necessarily everyone's assumption or interpretation, and with "acct:" as being an alternative URI resolver, webfinger being "follow your nose" makes sense.

Should we talk about this on the call tomorrow?

@cwebber

This comment has been minimized.

Collaborator

cwebber commented May 11, 2015

Also, @evanp, do you think that sounds about right, both for your reason of why webfinger is FYN (and also maybe why there's confusion)?

@akuckartz

This comment has been minimized.

akuckartz commented May 11, 2015

@evanp What exactly is meant with "Allow Webfinger for Actors" ?

@bblfish

This comment has been minimized.

Member

bblfish commented May 11, 2015

There is really no need to fight this out. These authentication methods are not exclusive. In fact one can tie together all the indentifiers: one just needs to notice that there are direct and indirect identifiers.

  • Direct Identifiers such as WebID
  • indirect identifiers, such as e-mail addresses, account profiles, blogs, home pages, telephone numbers, and public keys.

You can do this using inverse functional properties ( eg. :openid, :mbox, :homePage, :account, cert:key ) like this

@prefix : <http://xmlns.com/foaf/0.1/> .
@prefix cert: <http://www.w3.org/ns/auth/cert#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://bblfish.net/people/henry/card#me> 
     :openid <http://bblfish.net/>;
     :mbox <mailto:henry.story@bblfish.net> ;
     :homePage <http://bblfish.net/> ;
     :account [ :accountName "bblfish";
                :accountServiceHomepage <http://facebook.com/> ] ;
      cert:key [ a cert:RSAPublicKey;
                 cert:exponent 65537 ;
                 rdfs:comment "KeyChain OSX laptop";
                 cert:modulus "DAB9D1E941F6F85A0863169D0DB6328D1D4A15A71DFFE3D4F4D08752A52FB1454D7358E4A5ECF3501E3924BC0252F3004B0BB21A0D6B64CA053F0FBCB5A54EC93EBE2DC9B91E4C432B827884C4CC2AD8A102B46D2A2017BF45D9D4C88A564D420234484A1B2E446DBB4CD438E79C2466CE310F327773A779D24ED7B60A05A618B984757B946D67BA79F2E064E6AED38BD6559CE7FC9502720823D56DB1C034099367D7DB27B6BDAFDA8CC48347133F4A14675F675FB484CE32DF66C11A3638FA84D5BE69B1A6F238115DEF9B0F79BB25C0CB7E4A39459A0829B1FD35C0D1DBDD60F9C679D89415ED7EA41EB02FBC016FC0E792CB9698C9F4DB842CDAD5B5F5C9"^^xsd:hexBinary;
                ] .

All of these different systems can be tied together declaratively, without breaking RDF semantics.
A <mailto:henry.story@bblfish.net> address directly identifies a mailbox - as per mailto: rfc spec. But it indirectly identifies my in the graph

[] :mbox <mailto:henry.story@bblfish.net>

because mbox is a relation that for the same object can only have one subject. ie you can think of the inverse of foaf:mbox as a function. Call that mbInv. Then

mbInv(<mailto:henry.story@bblfish.net>)= me 

It's very handy, because that for example allows one to write access control rules declaratively, and allow different authentication methods:

  • E-mail addresses by sending an e-mail
  • facebook by using their system
  • openid by using the OpenId protocol, etc...
  • public key by using WebID over TLS for example, though others methods are possible too here.
@evanp

This comment has been minimized.

evanp commented May 12, 2015

@bblfish sorry, we're talking about specific issue in the current version of ActivityPump. Here's the text:

All Objects in [ActivityStreams] should have unique global identifiers. ActivityPump extends this requirement; all objects distributed by the ActivityPump protocol MUST have unique global identifiers; these identifiers must fall into one of the following groups:

    HTTPS URIs with their authority belonging to that of their originating server.
    An ID explicitly specified as the JSON null object, which implies an anonymous object (a part of its parent context)

Webfinger URIs are used by pump.io for identifying persons and other actor-type objects, and I think it makes sense to continue supporting that.

https://tools.ietf.org/html/rfc7033

It's a dereferenceable URI format that has a familiar username@domain format.

@bblfish

This comment has been minimized.

Member

bblfish commented May 12, 2015

from rfc7033

  This specification defines the WebFinger protocol, which can be used
   to discover information about people or other entities on the
   Internet using standard HTTP methods.  WebFinger discovers
   information for a URI that might not be usable as a locator
   otherwise, such as account or email URIs.

email URIs of the form <mailto:...> addresses refer to mail boxes. Account URIs of the form <acct:...> refer to accounts. So neither of these refers to a person. Therefore they cannot be used as direct identifiers for people. It is therefore in-appropriate to use them in @id positions to refer to people (ie. in the json-ld below in the first @id position). You can use them as explained above to refer to people indirectly via the respective properties ( that is all the other "@id" positions ).

To make this clearer, here is the isomorphic json-ld graph to the turtle one I posted above:

{
  "@context": {
   "@base": "http://bblfish.net/people/henry/card",
    "cert": "http://www.w3.org/ns/auth/cert#",
    "foaf": "http://xmlns.com/foaf/0.1/",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
  "@id": "#hjs",
 "@type": "foaf:Person",
  "foaf:account": {
      "foaf:accountName": "bblfish",
      "foaf:accountServiceHomepage": {
        "@id": "http://facebook.com/"
      }
  },
  "foaf:homePage": {"@id": "http://bblfish.net/"},
  "foaf:mbox": {"@id": "mailto:henry.story@bblfish.net"},
  "foaf:openid": { "@id": "http://bblfish.net/"},
  "cert:key": {
      "@type": "cert:RSAPublicKey",
      "cert:exponent": 65537,
      "cert:modulus": {
        "@type": "xsd:hexBinary",
        "@value": "DAB9D1E941F6F85A0863169D0DB6328D1D4A15A71DFFE3D4F4D08752A52FB1454D7358E4A5ECF3501E3924BC0252F3004B0BB21A0D6B64CA053F0FBCB5A54EC93EBE2DC9B91E4C432B827884C4CC2AD8A102B46D2A2017BF45D9D4C88A564D420234484A1B2E446DBB4CD438E79C2466CE310F327773A779D24ED7B60A05A618B984757B946D67BA79F2E064E6AED38BD6559CE7FC9502720823D56DB1C034099367D7DB27B6BDAFDA8CC48347133F4A14675F675FB484CE32DF66C11A3638FA84D5BE69B1A6F238115DEF9B0F79BB25C0CB7E4A39459A0829B1FD35C0D1DBDD60F9C679D89415ED7EA41EB02FBC016FC0E792CB9698C9F4DB842CDAD5B5F5C9"
      }
    }
}
@evanp

This comment has been minimized.

evanp commented May 12, 2015

Thanks, and I appreciate the clarification you're doing, but I disagree that WebID is the be-all end-all of identity, and I'd like to be able to continue to use Webfinger IDs for people in Activitypump as I already do in pump.io.

@bblfish

This comment has been minimized.

Member

bblfish commented May 12, 2015

@evanp I did not say that WebID is the "be-all end-all of identity". I showed how all these identifiers can work together. You don't have to use any of them. Here is a correct usage without WebIDs.

{
  "@context": {
   "@base": "http://bblfish.net/people/henry/card",
    "cert": "http://www.w3.org/ns/auth/cert#",
    "foaf": "http://xmlns.com/foaf/0.1/",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
 "@type": "foaf:Person",
  "foaf:account": {
      "foaf:accountName": "bblfish",
      "foaf:accountServiceHomepage": {
        "@id": "http://facebook.com/"
      }
  },
  "foaf:homePage": {"@id": "http://bblfish.net/"},
  "foaf:mbox": {"@id": "mailto:henry.story@bblfish.net"},
  "foaf:openid": { "@id": "http://bblfish.net/"},
  "cert:key": {
      "@type": "cert:RSAPublicKey",
      "cert:exponent": 65537,
      "cert:modulus": {
        "@type": "xsd:hexBinary",
        "@value": "DAB9D1E941F6F85A0863169D0DB6328D1D4A15A71DFFE3D4F4D08752A52FB1454D7358E4A5ECF3501E3924BC0252F3004B0BB21A0D6B64CA053F0FBCB5A54EC93EBE2DC9B91E4C432B827884C4CC2AD8A102B46D2A2017BF45D9D4C88A564D420234484A1B2E446DBB4CD438E79C2466CE310F327773A779D24ED7B60A05A618B984757B946D67BA79F2E064E6AED38BD6559CE7FC9502720823D56DB1C034099367D7DB27B6BDAFDA8CC48347133F4A14675F675FB484CE32DF66C11A3638FA84D5BE69B1A6F238115DEF9B0F79BB25C0CB7E4A39459A0829B1FD35C0D1DBDD60F9C679D89415ED7EA41EB02FBC016FC0E792CB9698C9F4DB842CDAD5B5F5C9"
      }
    }
}

I just removed that first @id: "#hjs" . Everything else remains the same. You can use all the other indirect identifiers.

The turtle equivalent is:

@prefix : <http://xmlns.com/foaf/0.1/> .
@prefix cert: <http://www.w3.org/ns/auth/cert#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

[]   :openid <http://bblfish.net/>;
     :mbox <mailto:henry.story@bblfish.net> ;
     :homePage <http://bblfish.net/> ;
     :account [ :accountName "bblfish";
                :accountServiceHomepage <http://facebook.com/> ] ;
      cert:key [ a cert:RSAPublicKey;
                 cert:exponent 65537 ;
                 rdfs:comment "KeyChain OSX laptop";
                 cert:modulus "DAB9D1E941F6F85A0863169D0DB6328D1D4A15A71DFFE3D4F4D08752A52FB1454D7358E4A5ECF3501E3924BC0252F3004B0BB21A0D6B64CA053F0FBCB5A54EC93EBE2DC9B91E4C432B827884C4CC2AD8A102B46D2A2017BF45D9D4C88A564D420234484A1B2E446DBB4CD438E79C2466CE310F327773A779D24ED7B60A05A618B984757B946D67BA79F2E064E6AED38BD6559CE7FC9502720823D56DB1C034099367D7DB27B6BDAFDA8CC48347133F4A14675F675FB484CE32DF66C11A3638FA84D5BE69B1A6F238115DEF9B0F79BB25C0CB7E4A39459A0829B1FD35C0D1DBDD60F9C679D89415ED7EA41EB02FBC016FC0E792CB9698C9F4DB842CDAD5B5F5C9"^^xsd:hexBinary;
                ] .

Nobody looses, everybody gains. We can all work together in a consistent manner without loss, and with interoperability.

@evanp

This comment has been minimized.

evanp commented May 12, 2015

@bblfish Great.

@xray7224 I'd really like to see the WebFinger option added back in; I'm not sure why it has to be decided by the whole group, but I'll put it on the agenda for today.

@akuckartz

This comment has been minimized.

akuckartz commented May 12, 2015

Can the result of this discussion become a component of the FPWD ? (I hope it is in scope. If not: a non normative component could still be helpfull ;-)

(If anyone is interested in creating a JSON-LD version of Webfinger: please contact me)

@bblfish

This comment has been minimized.

Member

bblfish commented May 12, 2015

If we used the foaf vocabulary my guess is that we could integrate the acct: scheme very easily like this:

@prefix : <http://xmlns.com/foaf/0.1/> .
@prefix cert: <http://www.w3.org/ns/auth/cert#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

[]   :account <acct:bblfish@identica.ca> .
 <acct:bblfish@identica.ca> 
         :accountName "bblfish";
          :accountServiceHomepage <http://facebook.com/> .

in JsonLD this looks better

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/"
  },
 "@type": "foaf:Person",
  "foaf:account": {
    "@id": "acct:bblfish@identica.ca",
    "foaf:accountName": "bblfish",
    "foaf:accountServiceHomepage": {"@id": "http://identica.ca/"}
  }
}

I am sure JSON-LD gurus can make that even more beautiful.

@erincandescent

This comment has been minimized.

erincandescent commented May 12, 2015

One possibility that occurs to me i that we can prohibit acct: IDs for objects, but permit them as aliases. That is to say, my ID might be "http://example.com/~oshepherd" but if somebody enters "[acct:]oshepherd@example.com" into the "Follow somebody" box, you need to do a Webfinger (or so) lookup for "acct:oshepherd@example.com", which will give you the actual ID of my account

@bblfish

This comment has been minimized.

Member

bblfish commented May 12, 2015

Why try to prohibit when you can get them to work nicely together in a logically consistent way through good modelling?

@erincandescent

This comment has been minimized.

erincandescent commented May 12, 2015

You still haven't told me how I take "acct:oshepherd@example.com" and actually get a dereferencable resource for that.

@bblfish

This comment has been minimized.

Member

bblfish commented May 12, 2015

@oshepherd I think the account scheme defines that. I am not too keen on accnt urls myself: I don't think there is a need for that indirection. But that does not stop the JSON-LD written above would be correct, if my understanding of how the acct url scheme works and what it refers to is correct. If in doubt one could have a webfinger relation relating an account to a string like this:

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "as": "http://www.w3.org/ns/activitystreams",
  },
 "@type": "foaf:Person",
  "foaf:account": {
    "as:webfinger": "bblfish@identica.ca",
    "foaf:accountName": "bblfish",
    "foaf:accountServiceHomepage": {"@id": "http://identica.ca/"}
  }
}

since the webfinger folk is about simplicity of use to the end user, it makes sense to have this as a string. It is then quite similar to the account name. But not so similar that it does not justify having another relation.

It's no more work writing than the "@id" and fits the follow your nose principle.

@akuckartz

This comment has been minimized.

akuckartz commented May 12, 2015

@bblfish I suppose that @oshepherd would like to know what happens when a LDP server tries to dereference acct:bblfish@identica.ca. How would that be implemented ? Or would that happen somewhere else ? (Where?)

@bblfish

This comment has been minimized.

Member

bblfish commented May 12, 2015

@akuckartz is that not solved by my second proposal?
In Turtle:

@prefix : <http://xmlns.com/foaf/0.1/> .
@prefix as: <http://www.w3.org/ns/activitystreams> .

[]   :account [ :accountName "bblfish";
                :accountServiceHomepage <http://facebook.com/>;
                as:webfinger "bblfish@identica.ca" ] 
@akuckartz

This comment has been minimized.

akuckartz commented May 12, 2015

@bblfish We would simply parse acct:bblfish@identica.ca and build those triples? That sounds simple. Can we put that in the FPWD ? :-)

@bblfish

This comment has been minimized.

Member

bblfish commented May 12, 2015

@akuckartz ( what is "FPWD" ? ) I am not sure what you mean by "simply" . All of my proposals above are simple. How would you model it? Where would you put it in the model? Can you give me an example Turtle or JSON-LD?

@akuckartz

This comment has been minimized.

akuckartz commented May 12, 2015

@bblfish "First Public Working Draft" (FPWD). Harry mentioned it on the mailing list today.

@bblfish

This comment has been minimized.

Member

bblfish commented May 12, 2015

You meant the to-be-written document? Can you just tell me which of the modelling proposals I put forward you'd want to put in the FPWD or if you had another one? ( that was the point of the three questions above - sorry if that felt like much, just wanted to avoid a long to and fro like we are having now ). Otherwise I can't really answer your question about whether "it" should go into FPWD.

Clearly I think that there is space for acct URIs or account strings. But it very much depends how you write them out in JSON-LD or Turtle. They can't go in any position, and I don't think they should be mandatory.

LDP user agents can ignore <acct:> urls or they can dereference them using the acct specification and follow the protocol there. What the acct url should probably point to is the document in which the JSON-LD we are talking about happens to be.

If you are interested in writing a json-ld spec to replace the xml format they have for the XSD thinggy me bob, that would certainly be an improvement as far as learnability of the whole system goes.

@cwebber

This comment has been minimized.

Collaborator

cwebber commented Dec 12, 2015

So if we agree that acct: can be a type of URI scheme, I don't see any problem with supporting webfinger IDs and accepting that as FYN. I know some of the group would prefer all FYN to be http or https, but oh well, accepting acct: solves this problem and allows us to preserve backwards compatibility.

@melvincarvalho

This comment has been minimized.

melvincarvalho commented Dec 14, 2015

-1 to using webfinger. I also thought it was out of scope for the group, and legacy. It's JSON format also conflicts in a breaking way with the JSON format of this group.

Let's stick to HTTP identifiers and follow your nose.

Well known locations are not follow your nose.

@cwebber

This comment has been minimized.

Collaborator

cwebber commented Dec 14, 2015

How about moving it to a "MAY support webfinger via acct"? There is a recent proposal to the IETF to formalize acct: which would qualify it as FYN, I think.

@melvincarvalho

This comment has been minimized.

melvincarvalho commented Dec 15, 2015

Minting a new URI scheme is almost always a sign of desperation. Even the guy that invented it said

Getting consensus for new URI schemes is often more difficult than solving American healthcare.

http://hueniverse.com/2009/08/19/making-the-case-for-a-new-acct-uri-scheme/

There was some debate during WF standardization whether it should exists at all. And I think it's failed to get widespread adoption.

The acct URI scheme was much misunderstood. It was created because the systems didnt have a syntax that said

Given an email address give me more information

This can certainly be done with activity stream type JSON, but cant be done with JRD style JSON, hence the need to invent a scheme. Over time it served a dual purpose as an "easy" way to denote users/accounts on services, which arguably didnt get the adoption it had hoped.

The acct: URI scheme does not achieve anything that cannot be readily done with current JSON standards used in this group, so I would -1 putting it in the spec. Of course where there is a data structure that accepts a URI, which is true of activity streams, any URI can go in there including mailto:, tel: etc. But generally such things should be out of scope of the spec wording, and be left to legacy systems implementation specifics.

The other major problem is that creating a parser for JRD is another high barrier and non compatible with the parser for AS. This makes a larger implementation barrier. Let's not promote URI schemes that have failed to gain widespread adoption unless we have to, and stick to those that have had great success ie HTTP and HTTPS

@cwebber

This comment has been minimized.

Collaborator

cwebber commented Dec 16, 2015

Okay, how about this as a compromise.

We put in mentions of using HTTP and HTTPS, and give clear information about how they are used, and not mention (but also not exclude) the acct: schema. How about that?

@melvincarvalho

This comment has been minimized.

melvincarvalho commented Dec 17, 2015

Works for me...

@cwebber

This comment has been minimized.

Collaborator

cwebber commented Jan 12, 2016

I adjusted the wording in fa38a67 making HTTPS URIs the only scheme explicitly mentioned, but it does not block the possibility of Webfinger or HTTP URIs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment