[wp-hackers] [WP 2.0 RC1] WP API Key ... Follow the google/amazon/ebay path ...

[Roy Schestowitz]

Interesting thoughts...

_____/ On Fri 02 Dec 2005 18:01:01 GMT, [Douglas Daulton] wrote : \_____

> I was a little confused about the WP API key requirements in WP 2.0 RC1.  So
> I had a chat with Matt about it.  I now understand how it works with WP.com.
> While I understand it, I think it may prove an administrative nightmare in
> the long run.  Not for me, but for the admins at WP.com.  Mainly, I think
> folks like me who run their own server, will end up creating a lot of dead
> wp.com sites just to get an API key.  So dead.wp.com will be just that ...
> An empty ill-maintained site which will slowly clog up the works as wp.com
> grows.

Void wp.com blogs should be cheap (in terms of space and traffic), but the
namespace  is  negatively affected (namely depleted), which  makes  wp.com
less desirable to potential subscribers.

I  suspect  that splog prove to be the far more detrimental  artefact.  As
Wordpress.com  matures,  it could (just /could/) become a victim  of  blo-
galanches.  It only needs some scripting, thus time. Purging those invalid
blogs,  which only serve SEO purposes, is harder. Blogs which function  as
API key placeholders will most likely embed no content. Splogs are intend-
ed  to look as much as possible like real blogs and they are often active,
not dormant.


> So, I shared with Matt what I thought might be a more efficient way of doing
> it.  Basically, we learn from established pros like Amazon, Google and eBAY.
> Create a new sub-domain called dev.wordpress.com (or something similar).
> Have devs register there.  Once registered, one dev gets a single API key.
> If, for some reason, (tracking, stats, etc.), we need an individual API key
> for every site we create, then have devs register new sites as part of their
> account and then append some unique number or string to the end of the
> existing API key.  Viola!  Unique, trackable API keys by domain or even
> subdomain.


This   would  be  an  excellent  solution,  but  only  if  you  assume   a
hacker/development  community.  If Average Joe's blog, which resides on  a
separate  domain,  needed a key, the steps above would be  daunting.  Then
again,  registering a blog just for an API key is adverse to common  sense
too. I assume it is a temporary solution.


> So in practice, it might looks something like this ...
>
> 1) I sign up at devs.wordpress.com and am asked if I also want a blog on
> wp.com.  In all cases, my requested user name is checked against the general
> account list for *.wp.com.  If it is available, I get it if not, I choose a
> new one.  If "I want a blog" is checked, then I am provisioned for
> username.wp.com as well.  If not, then I get no website, just an dev
> account.
>
> 2) I fill out some info about myself and my dev abilities which might be
> useful for folks looking for help on a project and could become an extension
> to the dev marketplace that Matt kicked off a while back.
>
> 3) I am taken to a "Register Sites" page where I list the site(s) I
> maintain.
>
> 4) Upon completion of the form and email confirmation of the account, I am
> assigned a WP API key.  And each site I register is given an
> appended/extended key.  The keys might look like this:
>
> Username:       monkeyman
> Base API Key:   monkeyman-1934567989909
> Site Key 1:     monkeyman-1934567989909-monkeyman.net
> Site Key 2:     monkeyman-1934567989909-monkeyman.com
> Site Key 3:     monkeyman-1934567989909-monkeyman.org


You  probably need a 2-way verification process. This helps in  prevention
of  spam,  which can exploit that openness and trust. Would it be  putting
some code/key in the main directory of the blog to indicate ownership?


> 5) Every time I add a new site to my portfolio, I login to my WP dev account
> and add it.  Or, even cooler yet.  On the new site, I enter my Base API Key
> and it auto posts the new site to my account on dev.wp.com.


That would be ideal.


> 6)  This could open up a whole new slew of cool, centralized WP-driven
> services like statistics and performance analysis, SPAM Blacklists (like
> Akismet), dev directory and ranking. Common tag libraries, etc.  None of it
> should squelch ideas and new project.  Just the opposite, it should drive
> them.
>
>
> So there it is.  Thoughts?


What  you propose is using the seminal WordPress site as a  root/authority
of  all sites that are driven by it. You can create a network of WordPress
bound/associated  sites, which I think is excellent. Statistics and analy-
sis,  for example, can be optimised and tailored to the very nature of the
sites  (which are all blogs). This has the advantages that Google  Analyt-
ics, for instance, still lacks.


Roy