Bootstrapping decentralized discovery with WebFist

[Brett Slatkin]

Hey all,

Here are the details on bootstrapping WebFinger with WebFist:

http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html

Let us know what you think. Thanks,

-Brett

[Ryan Barrett]

exciting! nice work guys!

i'm curious about a policy question. webfist says one of its primary features is that it's opt in, and can prove it for each user. this makes sense when a user provides additional information, but i wonder if it's necessary for use cases that only need well known, publicly available data that's just not webfinger-formatted.

for example, facebook and twitter have well known public profile URLs, avatars, etc. for each user. a webfist server could conceivably serve webfinger data with that data for all facebook and twitter users, and optionally serve additional (fist-bump verifiable) info for users that have opted in.

it's technically straightforward, but i'm curious about the policy part. does it sound reasonable? or is it against some core webfinger principle?

[Nick Jennings]

This is great stuff Brett (and Brad)! Thanks for sharing. I had some similar ideas about this recently (though I didn't get as far with the concept, especially with the proofs), and I'm glad to see someone has already gotten something working.

Is this going to be up and running any time soon? I will update webfinger.js[1] to use webfirst as a fallback as soon as it's ready.

[1] http://silverbucket.github.io/webfinger.js/demo/

--
 
---
You received this message because you are subscribed to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Will Norris]

Nick, it's up and running now on webfist.org

[Brad Fitzpatrick]

It's up and running, 

http://webfist.org/.well-known/webfinger?resource=acct:brad...@gmail.com

http://webfist.org/.well-known/webfinger?resource=acct:brad...@facebook.com

but there's only one server (an EC2 instance we created Sunday) in one zone, run by one person (me).  We'd really like to see instances run by a handful of people on a handful of reliable providers in different zones first, before we declare it as "stable".

It also doesn't have an SSL cert yet.

Blaine Cook said he's interested in running a node as well, but we then need to discuss how we load balance: if we do a DNS round-robin thing, then we all need the same SSL certs, and we have to trust that I continue to pay for the WebFist DNS on Amazon's Route 53 (which is pretty cheap).  Likewise with domain renewal.

Considering that I might get hit by a bus (or crash my motorcycle, or both), it's probably best to have a group of people own the domain name & DNS account(s).  Nodes can come and go, as long as a group of people continue to update the DNS pool's IPs.  I trust Amazon's Route 53 to stay around for awhile.

We could just pay for the WebFist domain name for 10 or 20 years.

On Tue, Jun 25, 2013 at 1:28 PM, Nick Jennings <ni...@silverbucket.net> wrote:

[Nick Jennings]

On Tue, Jun 25, 2013 at 10:37 PM, Will Norris <wi...@willnorris.com> wrote:

Nick, it's up and running now on webfist.org

Ah, I tried with 'www' in front and it failed.

Thanks

 

[Nick Jennings]

On Tue, Jun 25, 2013 at 10:38 PM, Brad Fitzpatrick <brad...@google.com> wrote:

It's up and running, 

http://webfist.org/.well-known/webfinger?resource=acct:brad...@gmail.com

http://webfist.org/.well-known/webfinger?resource=acct:brad...@facebook.com

Great, I'll update webfinger.js with a configurable option to fallback to webfist.org on failure (on by default), and add your gmail account to the demo (if you don't mind).

 

but there's only one server (an EC2 instance we created Sunday) in one zone, run by one person (me).  We'd really like to see instances run by a handful of people on a handful of reliable providers in different zones first, before we declare it as "stable".

It also doesn't have an SSL cert yet.

Blaine Cook said he's interested in running a node as well, but we then need to discuss how we load balance: if we do a DNS round-robin thing, then we all need the same SSL certs, and we have to trust that I continue to pay for the WebFist DNS on Amazon's Route 53 (which is pretty cheap).  Likewise with domain renewal.

Considering that I might get hit by a bus (or crash my motorcycle, or both), it's probably best to have a group of people own the domain name & DNS account(s).  Nodes can come and go, as long as a group of people continue to update the DNS pool's IPs.  I trust Amazon's Route 53 to stay around for awhile.

We could just pay for the WebFist domain name for 10 or 20 years.

I would be willing to run an instance on my server. What kind of load are we talking about? (maybe I should run it on it's own server instead of sharing it with other services/projects?)

Cheers
Nick
 

[Paul E. Jones]

So what happens if the user’s mail provider does not use DKIM?  Is there the option to send a verification email back to prove identity?

 

Paul

 

--

[Brad Fitzpatrick]

All major email domains support DKIM.

The most common domains that don't are indie/vanity domains, which can do WebFinger directly, without the WebFist indirection.

DKIM and the proof emails we include in the lookup responses let anybody verify a claim, which isn't obvious how to do (if possible) with some email-and-click-this-link verification.

Let me make that last point more clear.  Look at this response:

     http://webfist.org/.well-known/webfinger?resource=acct:brad...@facebook.com

See that "http://webfist.org/spec/proof":"http://webfist.org/webfist/proof/8e97a02af6b6d075a912c8ced53a4653d16849aa-7d55ea58e3635f708794e542c16de7b7291cb79a?decrypt=bradfitz%40facebook.com" ?

Even if you don't trust webfist.org, or don't trust some-unknown-pool-member.webfist.org, you can at least fetch:

     http://webfist.org/webfist/proof/8e97a02af6b6d075a912c8ced53a4653d16849aa-7d55ea58e3635f708794e542c16de7b7291cb79a?decrypt=bradfitz%40facebook.com

... and verify the DKIM on your own. It doesn't even need to be https, assuming your client is doing secure DNS lookups to facebook's domain keys.

[Nick Jennings]

On Tue, Jun 25, 2013 at 10:59 PM, Nick Jennings <ni...@silverbucket.net> wrote:

On Tue, Jun 25, 2013 at 10:38 PM, Brad Fitzpatrick <brad...@google.com> wrote:

It's up and running, 

http://webfist.org/.well-known/webfinger?resource=acct:brad...@gmail.com

http://webfist.org/.well-known/webfinger?resource=acct:brad...@facebook.com

Great, I'll update webfinger.js with a configurable option to fallback to webfist.org on failure (on by default), and add your gmail account to the demo (if you don't mind).
 

I've updated the webfinger.js demo [1] to use `webfistFallback`. It automatically tries 'brad...@gmail.com' now, however the webfist.org CORS headers do not allow queries from it at this point.

[1] http://silverbucket.github.io/webfinger.js/demo/

[Brett Slatkin]

Sweet! What's the CORS header you need?

[Brad Fitzpatrick]

Right. We were talking about that the other day but forgot them.

I can push an update live when I hear what to add.

[Paul E. Jones]

Yeah,  that’s a good reason to use DKIM.  However, I’ve encountered a number of domains that do not properly sign messages.  I’m not sure if any large domains were failing, but I did see a number of domains with verification errors on my mail server.

 

You might want is to allow a domain owner (e.g., Acme, Inc.) to install a policy that disallows use of WebFist.  It might be that a company does not want to provide WF services (perish the thought!) and does not want its employees using alternative services with its domain to bypass its policy.  Perhaps an email from an address like hostm...@acme.example could be used to allow/disallow use for the domain.

 

Another thing to consider is when Acme, Inc. does decide to support WF.  If there were users that had delegated WF queries to some URI, that will break all of a sudden when Acme starts responding.

 

In the examples posted, I noted all delegation was to HTTP rather than HTTPS URIs.  Some folks who insisted on HTTPS might not like the fact that the fallback does not use HTTPS.  I understand the challenges in trying to explain that to users, but a “proper” WF client should not follow an HTTP URI.

 

Paul

[Paul E. Jones]

CORS header should be:

 

Access-Control-Allow-Origin: *

 

Paul

 

From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Brad Fitzpatrick
Sent: Tuesday, June 25, 2013 7:16 PM
To: webf...@googlegroups.com
Subject: Re: Bootstrapping decentralized discovery with WebFist

 

Right. We were talking about that the other day but forgot them.

[Brad Fitzpatrick]

Done.

[Brad Fitzpatrick]

Domains who don't properly do DKIM don't do DKIM.  I'm not concerned about those.  They (and maybe their users) have bigger problems than setting up their WebFist delegation.

Regarding Acme Inc blocking its users from using WebFinger... that's a corporate policy and social problem more than a technical problem.  Others would argue that WebFist's non-reliance on the cooperation of Acme, et al is a feature.

[Dick Hardt]

Brad / Brett

Huge kudos for hacking and deploying something!

-- Dick

[Nick Jennings]

On Wed, Jun 26, 2013 at 1:43 AM, Brad Fitzpatrick <brad...@google.com> wrote:

Done.

Great, the requests are now answered, and webfinger.js gets JSON back. Nothing to display from that query though, so it's nothing really to look at until you put in an avatar and some links to feeds/blogs or something, but it's working :)

[Will Norris]

There's not supposed to be anything to look at.  WebFist will never return anything more than the URL of the actual webfinger document for an email address.  It's not meant to replace webfinger, it only bootstraps it for domains that don't support it natively.  If you want the avatar, links to blogs, etc, then follow the rel="http://webfist.org/spec/rel" link and find it there.

--

[Nick Jennings]

On Wed, Jun 26, 2013 at 2:50 AM, Will Norris <wi...@willnorris.com> wrote:

There's not supposed to be anything to look at.  WebFist will never return anything more than the URL of the actual webfinger document for an email address.  It's not meant to replace webfinger, it only bootstraps it for domains that don't support it natively.  If you want the avatar, links to blogs, etc, then follow the rel="http://webfist.org/spec/rel" link and find it there.

Doh! I think I must have overlooked that in the article. :)

Will update webfinger.js to make this extra request after the webfist query.

[Nick Jennings]

On Wed, Jun 26, 2013 at 2:59 AM, Nick Jennings <ni...@silverbucket.net> wrote:

On Wed, Jun 26, 2013 at 2:50 AM, Will Norris <wi...@willnorris.com> wrote:

There's not supposed to be anything to look at.  WebFist will never return anything more than the URL of the actual webfinger document for an email address.  It's not meant to replace webfinger, it only bootstraps it for domains that don't support it natively.  If you want the avatar, links to blogs, etc, then follow the rel="http://webfist.org/spec/rel" link and find it there.

Doh! I think I must have overlooked that in the article. :)

Will update webfinger.js to make this extra request after the webfist query.

Hmm, actually, after re-thinking the setup again, this won't work so well for web applications (ie. requests from the browser). The problem with this method is that, for browser-based queries, all of the users will need to set store their JSON records on servers with permissive CORS headers for that URI. This is not likely possible for many users.

Is there any way around this? Here are some options I can think of off the top of my head.

(A) WebFist allows users to set their WebFinger records @ WebFist. (so the response from WebFist contains user provided info)

(B) WebFist act's as a proxy, when the client-side (app) request comes in, WebFist fetches the users JSON file and merges this with the WebFist record, returning the whole thing back to the client app.

(C) Users JSON files are stored wrapped in functions, allowing for the JSONP hack (retrieving JSON objects from foreign hosts).

(D) All users must store their JSON files on servers which set permissive CORS headers.

Options (C) and (D) are not really something we can rely on. Option (A) may add too much responsibility for the WebFist service, and turns it into a central data-store of WebFinger records. What about option (B) ?

Without some work-around though, no client apps can reliably make use of WebFist.

In the meantime, I've updated the webfinger.js anyway to follow this procedure:

1. make request to server based on email address.. -- if fails:

2. make request to webfist for email address

3. get the href for rel `http://webfist.org/spec/rel`

4. attempt request to href for users json file (fails at the moment for Brads json file)

5. process received file as if it was an original webfinger response

Cheers
Nick

[Brad Fitzpatrick]

I'm not concerned about users who can run their own server but can't set their own CORS headers.  The level of technical competence and cost between those two is so small as to be uninteresting of a niche to worry about.  That is: you can either run your own server (totally), or you can't.

I figure "most" users (especially of WebFist) will use a hosted WebFinger provider.  Just like most of us use a hosted email provider rather than running our own SMTP+IMAP servers, most users will use hosted WebFinger.  Think of WebFist as an MX record. But instead of an MX on our own domain name, it's an MX redirection from gmail/facebook to my-webfinger.com or yapalets.ru or whatever.

With this analogy, your concern could be rephrased: My DNS provider lets me pick my inbound SMTP server, but I don't know how to run my own SMTP server!

I've changed where br...@danga.com sends my email several times over my life, but it didn't affect anybody else.

If you grow skeptical of shadyfinger.info's business practices, you can always change your webfinger provider to somebody else. Or yourself, once you figure out how to set an HTTP response header.

[Nick Jennings]

On Wed, Jun 26, 2013 at 4:05 AM, Brad Fitzpatrick <brad...@google.com> wrote:

I'm not concerned about users who can run their own server but can't set their own CORS headers.  The level of technical competence and cost between those two is so small as to be uninteresting of a niche to worry about.  That is: you can either run your own server (totally), or you can't.

I figure "most" users (especially of WebFist) will use a hosted WebFinger provider.  Just like most of us use a hosted email provider rather than running our own SMTP+IMAP servers, most users will use hosted WebFinger.  Think of WebFist as an MX record. But instead of an MX on our own domain name, it's an MX redirection from gmail/facebook to my-webfinger.com or yapalets.ru or whatever.

The use case I had in mind was a user of gmail, or some other major email provider, who wants to take advantage of webfinger capabilities *without* running their own server.

If someone already runs a server, then of course I don't think CORS headers are a problem.

The use-case I was thinking of is, for instance, my girlfriend.

1. has a gmail address

2. might want to leverage webfinger for some purposes

3. could use a service to generate a WebFinger JSON file

4. dump it in her dropbox or other publicly available URL

WebFirst would be perfect for this, but there's no telling what the CORS headers will be where she puts that file.

My point is the inconsistency and user experience ("somethings don't work, some things do, and I don't know why, CORS what? The file is here <url> and I can see it fine.").

Is proxing the request bad for any specific reasons?
Perhaps an option that be set in the request? That way a web app (who obviously knows they are operating within a CORS restricted environment) can let WebFist know to send back the users JSON file directly.

Just a thought.

[Brad Fitzpatrick]

Your girlfriend probably also wants a OAuth CRUD API for 3rd-party services to append to her JRD, advertising her availability on other services.  I think "host it on Dropbox" is a red herring.  It's a cute example, but I doubt anybody really wants that.  It's both too limited (in what it could do) and too dorky (for most users... JRD wot?)

Proxying adds lots of abuse issues.  Hosting very small DKIM-signed emails is much less of a maintenance overhead.

[Nick Jennings]

3rd party services appending to the JRD is a great point.

Side note: your JSON file does not have permissive CORS headers, can you allow from * for that file? Just for proof of concept.

[Paul E. Jones]

I suspect most users will not be running their own servers, either.  However, I can’t imagine any company finding a business model where they can make money running a WF server.

 

It might fit in well with Google+, for example, making that platform more feature-rich.

 

WF would be potentially useful inside the enterprise (er,  business) and for sharing information between businesses (and the world, for that matter).  Businesses might outsource the WF server like they do email, but that would still mean a domain that can control servers and DNS records.

 

WebFist appears to be targeting individuals or smaller companies that don’t have the ability or desire to run a WF server.   Those folks will have to have some technical ability, though, as who would offer a service for them?

 

I believe Amazon S3 allows for CORS headers to be set for files and/or buckets.  I’ve not checked that out too closely, but it seems like I did see something in the documentation about that.

 

Paul

 

From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Brad Fitzpatrick
Sent: Tuesday, June 25, 2013 10:06 PM
To: webf...@googlegroups.com
Subject: Re: Bootstrapping decentralized discovery with WebFist

 

I'm not concerned about users who can run their own server but can't set their own CORS headers.  The level of technical competence and cost between those two is so small as to be uninteresting of a niche to worry about.  That is: you can either run your own server (totally), or you can't.

[Paul E. Jones]

I should also say, it’s pretty easy to set CORS headers with Apache, too.  The .htaccess file in the directory where the JRD files are located just needs to have a line like this:

 

Header set Access-Control-Allow-Origin "*"

 

Paul

[Ryan B]

i've added webfist compatibility to https://facebook-webfinger.appspot.com/ and https://twitter-webfinger.appspot.com/ . you can see their webfist endpoints in action with these examples:

https://facebook-webfinger.appspot.com/.well-known/webfinger?resource=acct:pithy....@facebook.com
https://twitter-webfinger.appspot.com/.well-known/webfinger?resource=acct:pithy....@twitter.com

they're not true webfist servers, since they don't participate in the fist-bump network (still can't quite say that with a straight face :P), but they can serve as drop-in webfist server replacements for facebook and twitter accounts for purposes of redundancy, decentralization, etc.

the key difference from webfist proper is that they serve webfinger data for *all* accounts, not just those that have opted in. by the same token, they only serve generic facebook and twitter data, not anything additional that individual users have registered.

happy interoperating! and thanks again, brad and brett!

[Melvin Carvalho]

On 25 June 2013 19:36, Brett Slatkin <bsla...@gmail.com> wrote:

Hey all,

Here are the details on bootstrapping WebFinger with WebFist:

http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html

Looks great.  Would it be possible to use webfist with the traditional plain old email address user@host, as well as the newly proposed acct: scheme?

 

Let us know what you think. Thanks,

-Brett

[Brad Fitzpatrick]

On Wed, Jun 26, 2013 at 6:43 AM, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 25 June 2013 19:36, Brett Slatkin <bsla...@gmail.com> wrote:

Hey all,

Here are the details on bootstrapping WebFinger with WebFist:

http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html

Looks great.  Would it be possible to use webfist with the traditional plain old email address user@host, as well as the newly proposed acct: scheme?

WebFist only works with email addresses, because it receives incoming email.  (Its implementation includes an SMTP server)

But you query it with "acct:user@host" because that's what WebFinger does and it speaks WebFinger, not its own thing.

[Melvin Carvalho]

Thanks brad, I should have realized that, yes :)

[Melvin Carvalho]

On 25 June 2013 19:36, Brett Slatkin <bsla...@gmail.com> wrote:

Hey all,

Here are the details on bootstrapping WebFinger with WebFist:

http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html

This is pretty impressive technology.  Signing claims to make them portable seems like the way forward.

Is webfist resistant to email spam? 

 

Let us know what you think. Thanks,

-Brett

[☮ elf Pavlik ☮]

I've forwarded your email to mailing list hosting Mozilla Persona, IMO few interesting comments for developers there: https://groups.google.com/d/msg/mozilla.dev.identity/MNyL9A-GujY/Gf9L4ft5ewsJ

Excerpts from Brett Slatkin's message of 2013-06-25 17:36:30 +0000:

> Hey all,
>
> Here are the details on bootstrapping WebFinger with WebFist:
>
> http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html
>

[Jesse Thompson]

On 6/25/13 12:36 PM, Brett Slatkin wrote:
> Hey all,
>
> Here are the details on bootstrapping WebFinger with WebFist:
>
> http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html
>
> Let us know what you think. Thanks,
>
> -Brett

I'm new here, so maybe this was discussed. I see a long term
implementation issue with webfist.

Suppose that my users begin adopting and relying on webfist, but I
intend to directly implement webfinger next year. If I have hundreds or
thousands of users depending on the results returned by webfist, then
when I enable webfinger for my domain my service will immediately begin
returning the incorrect results for all of those users. That will
result in end-user complaints. Most importantly, I won't know which of
my users will be affected by this change, so there is no way for me to
warn them ahead of time.

So, I would need to query webfist for the results for every single one
of my users in order to import the data into my service. Is that type
of mass query going to be allowed by webfist? Is webfist going to be
the only service facilitating the role of bootstrapping webfinger? If
not, I'll need to mass-query all of these bootstrapping services, right?

Jesse

[Brad Fitzpatrick]

On Thu, Jun 27, 2013 at 8:05 AM, Jesse Thompson <jesse.t...@doit.wisc.edu> wrote:

On 6/25/13 12:36 PM, Brett Slatkin wrote:

Hey all,

Here are the details on bootstrapping WebFinger with WebFist:

http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html

Let us know what you think. Thanks,

-Brett

I'm new here, so maybe this was discussed.  I see a long term implementation issue with webfist.

Suppose that my users begin adopting and relying on webfist, but I intend to directly implement webfinger next year.  If I have hundreds or thousands of users depending on the results returned by webfist, then when I enable webfinger for my domain my service will immediately begin returning the incorrect results for all of those users.  That will result in end-user complaints.  Most importantly, I won't know which of my users will be affected by this change, so there is no way for me to warn them ahead of time.

So, I would need to query webfist for the results for every single one of my users in order to import the data into my service.  Is that type of mass query going to be allowed by webfist?

Yes, that would be allowed: you'd just download a mirror of the underlying webfist data (as if you were going to run your own webfist node in the pool) and you could then query locally.

As an upper bound, if 7 billion people sent that Facebook email I linked above, that's 9 terabytes.  We're also not compressing the data right now pre-encryption.  So 9 terabytes is a very high upper bound, but also still quite sane.

Another thing we can do is allow a a much higher (or unbounded) query rate if your supply the scrypt of the email address in your query, so there's no basically no cost to the webfist pool nodes.

  Is webfist going to be the only service facilitating the role of bootstrapping webfinger?  If not, I'll need to mass-query all of these bootstrapping services, right?

Unknown. Hopefully not, but if there are more than 1, hopefully they'll be even better than webfist.  (at which point webfist can go away)

[Will Norris]

forgetting about round robining and shared private keys for the moment... any hope of getting an SSL cert on webfist.org in the short term?

On Tue, Jun 25, 2013 at 1:38 PM, Brad Fitzpatrick <brad...@google.com> wrote:

It's up and running, 

http://webfist.org/.well-known/webfinger?resource=acct:brad...@gmail.com

http://webfist.org/.well-known/webfinger?resource=acct:brad...@facebook.com

but there's only one server (an EC2 instance we created Sunday) in one zone, run by one person (me).  We'd really like to see instances run by a handful of people on a handful of reliable providers in different zones first, before we declare it as "stable".

It also doesn't have an SSL cert yet.

Blaine Cook said he's interested in running a node as well, but we then need to discuss how we load balance: if we do a DNS round-robin thing, then we all need the same SSL certs, and we have to trust that I continue to pay for the WebFist DNS on Amazon's Route 53 (which is pretty cheap).  Likewise with domain renewal.

Considering that I might get hit by a bus (or crash my motorcycle, or both), it's probably best to have a group of people own the domain name & DNS account(s).  Nodes can come and go, as long as a group of people continue to update the DNS pool's IPs.  I trust Amazon's Route 53 to stay around for awhile.

We could just pay for the WebFist domain name for 10 or 20 years.

On Tue, Jun 25, 2013 at 1:28 PM, Nick Jennings <ni...@silverbucket.net> wrote:

This is great stuff Brett (and Brad)! Thanks for sharing. I had some similar ideas about this recently (though I didn't get as far with the concept, especially with the proofs), and I'm glad to see someone has already gotten something working.

Is this going to be up and running any time soon? I will update webfinger.js[1] to use webfirst as a fallback as soon as it's ready.

[1] http://silverbucket.github.io/webfinger.js/demo/

On Tue, Jun 25, 2013 at 7:36 PM, Brett Slatkin <bsla...@gmail.com> wrote:

Hey all,

Here are the details on bootstrapping WebFinger with WebFist:

http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html

Let us know what you think. Thanks,

-Brett

--
 
---
You received this message because you are subscribed to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
 
---
You received this message because you are subscribed to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Brad Fitzpatrick]

I'll try to do it this weekend.

[Will Norris]

that'd be great, thanks!  I've got webfist support live on client.webfinger.net now... http://client.webfinger.net/lookup?resource=wnorris%40gmail.com

The SSL_CERTIFICATE_ERROR is apparently what AppEngine returns instead of "connection refused" :-(  In any event, once you've got a cert on webfist.org, I can disable the http fallback entirely.

For anyone that cares, this is using a patched version of https://github.com/ant0ine/go-webfinger; I'm working with Antoine to get these changes pushed upstream.

[Paul E. Jones]

Very cool!  Next, it would be cool to create some kind of profile-like page with the information that is discovered :-)

 

I tried using curl at the command line on the https URI that you reported to be failing and I’m getting a connection refused.  You really see cert errors?  What I see looks more like port 443 not listening for traffic.

 

Paul

 

From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Will Norris
Sent: Saturday, June 29, 2013 12:14 AM
To: webf...@googlegroups.com
Subject: Re: Bootstrapping decentralized discovery with WebFist

 

that'd be great, thanks!  I've got webfist support live on client.webfinger.net now... http://client.webfinger.net/lookup?resource=wnorris%40gmail.com

[Will Norris]

On Sat, Jun 29, 2013 at 1:21 PM, Paul E. Jones <pau...@packetizer.com> wrote:

Very cool!  Next, it would be cool to create some kind of profile-like page with the information that is discovered :-)

yep, that'd be cool as well.  I'm not sure what the right balance is between just showing the resulting JRD so that developers see what they actually have to work with, versus showing a profile page which demonstrates one possible use of the data.  I guess it's all about how it is presented.

 

 

I tried using curl at the command line on the https URI that you reported to be failing and I’m getting a connection refused.  You really see cert errors?  What I see looks more like port 443 not listening for traffic.

That's what I was referring to when I said "The SSL_CERTIFICATE_ERROR is apparently what AppEngine returns instead of 'connection refused'".  It looks like an AppEngine bug, returning the wrong error message.

[Paul E. Jones]

For those not familiar with WebFinger, it does not always immediately click.  A visual example goes a long way in producing that “Ah! Ha!” moment.  But then having the stuff you have here now is good for those who want to understand how it works.  I’m not sure how to present it, but perhaps something similar to what Nick has:

http://silverbucket.github.io/webfinger.js/demo/

 

Or, perhaps refer people to that page?