- Does the format have to look like an email address? This identifier should never appear in front of a user. At the same time, many services use email addresses as the local identifier (Facebook, Google, etc.). The current syntax is strongly biased towards email providers. Its format also makes it more likely to find its way in front of users. Why not acct://twitter.com/hueniverse (for example)? Remember, this is an internal identifier.
- Profile pages work because there is a single way to interact with them (getting an HTML page and showing the human reader). How should client interact with 'acct' URIs in the context of human interaction? The less this is defined, the more confusing it will be for users.
- Is the 'acct' URI the canonical identifier of the account holder? Do we expect other protocols using WebFinger to maintain this identifier and assert it? If an internal mapping is allowed, which identifier should be used to link to the account? The canonical one or the 'acct' one?
- How do you think WebFinger and the 'acct' URI should be aligned with OpenID Connect as currently proposed?
- How do users authenticate that an 'acct' URI belongs to them? Consider the fact that authentication can be used for both accessing private data (delegation) as well as proving ownership.
EHL
Yes, it must look like an email address. I've made this argument many
times, but fundamentally the "user at place" grammar makes more sense
to *people* than the HTTP-style "place with person" grammar.
If we want identifiers for fine-grained "things you can't communicate
with", then HTTP URIs work just fine; if we're not going to use
email-like identifiers for content, why would we use http-like
identifiers for people?
> This identifier should never appear in front of a user.
The whole point is that this identifier is exactly what appears in
front of a user. Do you mean "the unique identifier that's returned by
a hypothetical OpenID Connect provider" should never appear in front
of a user?
> At the same time, many services use email addresses as the local identifier (Facebook, Google, etc.). The current syntax is strongly biased towards email providers. Its format also makes it more likely to find its way in front of users. Why not acct://twitter.com/hueniverse (for example)?
If Twitter (the only service today that has more than ~10 million
users that know their usernames, let alone their profile URLs) wants
to support Webfinger, they're free to do so – all they'd need to do is
have a clean way of dealing with the username/email namespace overlap,
which isn't difficult (particularly if they didn't offer email
services).
For everyone else, login is universally tied to an email address. I
honestly can't think of a single counter-example (before you say "Ahh!
But what about Twitter @anywhere and Facebook Connect?", remember that
both Twitter and Facebook use email addresses as identifiers, which
means that @anywhere and Facebook Connect are both tied to email
addresses as far as users are concerned).
> Remember, this is an internal identifier.
See above. I think this is a fundamentally external identifier.
> - Profile pages work because there is a single way to interact with them (getting an HTML page and showing the human reader). How should client interact with 'acct' URIs in the context of human interaction? The less this is defined, the more confusing it will be for users.
A "webfinger address" or "acct URI" is about being able to contact
someone. When a user types in "myfr...@example.com", the working
theory is that their software will do an LRDD lookup for
"myfr...@example.com" and offer the best way to contact
"myfr...@example.com".
If no LRDD profile exists, email is a legitimate fallback. While there
are many email providers that don't support webfinger (i.e.,
LRDD-discoverable profiles), the number of webfinger providers that
don't have an effective strategy for email is safely assumed to be
zero.
There's very little to define here in the specification sense, because
it's all about user experience and interface design. We can make
helpful suggestions, of course, but beyond the base discovery process
it's up to the designer.
> - Is the 'acct' URI the canonical identifier of the account holder? Do we expect other protocols using WebFinger to maintain this identifier and assert it? If an internal mapping is allowed, which identifier should be used to link to the account? The canonical one or the 'acct' one?
The acct URI. As John mentioned regarding the conversation about
OpenID Connect we had at IIW, the flow should be:
1. User provides an email-like identifier (b...@example.com).
2. RP performs discovery against email-like identifier
(example.com/.well-known/host-meta) to find the user's OpenID Connect
server (SP).
3. RP contacts SP, asking to authenticate b...@example.com
4. SP verifies that b...@example.com is logged in (however that happens).
5. SP provides RP with an assertion that b...@example.com successfully
logged in, and optionally remembers that RP is allowed to know when
bob is logged in from now on.
Now, there are several places that "OpenID Connect" could involve HTTP
URIs in this flow:
In Step #2, the result of the discovery process could be an HTTP URI
that uniquely identifies b...@example.com. This way, the SP could
authenticate bob without knowing which identifier bob provided to the
RP (even though that's kind of dumb). Without providing
'b...@example.com' in the authentication request (#3), though, the RP
can't guarantee that the identifier discovered in #2 is uniquely
bob's, which is problematic (mostly because I can't understand the
repercussions, which means it's unlikely that users will be able to).
Alternatively, in Step #4, the SP could provide the RP with an unique
identifier to use for future authentication requests. I'm not entirely
sure why that would be desirable, especially given that OAuth tokens
are already unique identifiers used for future authentication requests
(and, they're not HTTP URIs).
As far as I can tell, the use of HTTP/S URIs in the context of OpenID
Connect is purely a hold-over from OpenID. I'm biased, though, and
think that HTTP URIs should never be used for logins.
> - How do users authenticate that an 'acct' URI belongs to them? Consider the fact that authentication can be used for both accessing private data (delegation) as well as proving ownership.
See above. I claim that if:
1. A user's Webfinger profile provides a "login-provider" <link>
AND
2. Said login provider can assert to a relying party that the
webfinger account in question is logged in
THEN
3. The user has authenticated that an acct URI belongs to them.
This is exactly the same approach used by "password reminder" emails,
and other than the fact that unencrypted email communications are
susceptible to MITM attacks, I haven't heard a single objection to
this approach insofar as it is practiced today.
b.
Because the only reason why we created this work was to bootstrap something the user was *already* familiar with and was already using as an identifier – their email address. Showing users ‘hueni...@twitter.com’ or ‘acct:er...@hueniverse.com’ takes away all the value of this effort because it either misleads the user (no such email address) or confuses them (weird ‘acct:’ prefix before what must be an email address).
Arguments about XMPP using the same email-like identifiers are irrelevant outside the tech community (actually, the subset that uses Jabber).
I am convinced that exposing email-like identifiers that are not email addressed to users is going to cause nothing but confusion. If I logged into Twitter and saw “Welcome hueni...@twitter.com” even *I* would be confused. Not to mention, if I log into the NYTimes using my Twitter account and they welcomed me like that. The only valid options are: “Welcome hueniverse”, “Welcome Eran”, or “Welcome er...@hueniverse.com" (i.e. my real email which I consider my identifier).
This work is highly biased towards email providers (and for a good reason). I am not convinced there are real use cases for email-like identifiers that are not email addresses which is the point I was trying (but clearly failed) to make.
EHL
From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Bob Wyman
Sent: Thursday, May 27, 2010 10:40 PM
To: webf...@googlegroups.com
Subject: Re: 'acct' URI survey
Eran Hammer-Lahav <er...@hueniverse.com> wrote:
I assert that the universe if interesting human+machine readable
identifiers is well covered by two patterns, x@y.z and y.z/x.
On Thursday, May 27, 2010, Eran Hammer-Lahav <er...@hueniverse.com> wrote:
> Because the only reason why we created this work was to bootstrap something the user was *already* familiar with and was already using as an identifier – their email address. Showing users ‘hueni...@twitter.com’ or ‘acct:er...@hueniverse.com <acct%3Ae...@hueniverse.com>’ takes away all the value of this effort because it either misleads the user (no such email address) or confuses them (weird ‘acct:’ prefix before what must be an email address). Arguments about XMPP using the same email-like identifiers are irrelevant outside the tech community (actually, the subset that uses Jabber). I am convinced that exposing email-like identifiers that are not email addressed to users is going to cause nothing but confusion. If I logged into Twitter and saw “Welcome hueni...@twitter.com” even *I* would be confused. Not to mention, if I log into the NYTimes using my Twitter account and they welcomed me like that. The only valid options are: “Welcome hueniverse”, “Welcome Eran”, or “Welcome er...@hueniverse.com" <er...@hueniverse.com%22> (i.e. my real email which I consider my identifier). This work is highly biased towards email providers (and for a good reason). I am not convinced there are real use cases for email-like identifiers that are not email addresses which is the point I was trying (but clearly failed) to make. EHL From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Bob Wyman
> Sent: Thursday, May 27, 2010 10:40 PM
> To: webf...@googlegroups.com
> Subject: Re: 'acct' URI survey Eran Hammer-Lahav <er...@hueniverse.com> wrote:> This identifier should never appear in front of a userWhy shouldn't users ever see WebFinger IDs? What utility is there in such a claim? bob wyman On Thu, May 27, 2010 at 7:03 PM, Eran Hammer-Lahav <er...@hueniverse.com> wrote:(I'll try this from another direction. I'm not trying to abolish the 'acct' URI, just better understand the collective wisdom, since clearly the lack of clarity on this has created a bunch of different expectations.)
>
> - Does the format have to look like an email address? This identifier should never appear in front of a user. At the same time, many services use email addresses as the local identifier (Facebook, Google, etc.). The current syntax is strongly biased towards email providers. Its format also makes it more likely to find its way in front of users. Why not acct://twitter.com/hueniverse (for example)? Remember, this is an internal identifier.
>
> - Profile pages work because there is a single way to interact with them (getting an HTML page and showing the human reader). How should client interact with 'acct' URIs in the context of human interaction? The less this is defined, the more confusing it will be for users.
>
> - Is the 'acct' URI the canonical identifier of the account holder? Do we expect other protocols using WebFinger to maintain this identifier and assert it? If an internal mapping is allowed, which identifier should be used to link to the account? The canonical one or the 'acct' one?
>
> - How do you think WebFinger and the 'acct' URI should be aligned with OpenID Connect as currently proposed?
>
> - How do users authenticate that an 'acct' URI belongs to them? Consider the fact that authentication can be used for both accessing private data (delegation) as well as proving ownership.
>
>
> EHL
--
--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer
When I conceived the 'acct' URI scheme, I modeled it after email addresses to make normalization or *email addresses* trivial (just stick 'acct:' in front of it). But I also clearly stated that I consider 'acct:er...@hueniverse.com@facebook.com' a perfectly valid account URI (which happens to be my Facebook account). This is why I explicitly defined it using the *right-most* '@' as the separator with the local part being any legal URI path character.
I'm sure we can all agree that 'acct:er...@hueniverse.com@facebook.com' doesn't look at all useful when presented to a web user. I am also willing to bet that Blaine will have a fit if he saw that anywhere (in human or machine documents) :-).
I don't have any data to back my usability assertions, but we can ask Blaine to ask his Grama what "Welcome blaine...@twitter.com" means to her.
EHL
> -----Original Message-----
> From: webf...@googlegroups.com
> [mailto:webf...@googlegroups.com] On Behalf Of John Panzer
> Sent: Thursday, May 27, 2010 11:29 PM
> To: webf...@googlegroups.com
> Subject: Re: 'acct' URI survey
>
> Do you have any data to back these usability assertions up?
>
> I assert that the universe if interesting human+machine readable identifiers
> is well covered by two patterns, x@y.z and y.z/x.
>
> On Thursday, May 27, 2010, Eran Hammer-Lahav <er...@hueniverse.com>
> wrote:
> > Because the only reason why we created this work was to bootstrap
> > something the user was *already* familiar with and was already using
> > as an identifier - their email address. Showing users
You must be joking. Of course you are not confused by your *email address* showing at the top of your *email program*! There is nothing out of context there. But how should the NYTime welcome a user using their Twitter account to log into the site?
The only way Grama will be able to grasp “blaine...@twitter.com” is if it was actually an email account. Why? Because what else could it be?! Ask anyone you want, it *is* an email address. Now, users on other microblogging sites might be used to this hack by now because they really want to interact with Twitter users, but that’s an insignificant number of mostly geeks.
I’m not trying to burst your utopian federated social web vision. I think my work speaks for itself. But expecting people to suddenly get that something@somewhere isn’t always an email address (and that there is no real way of knowing other than trying to send it a message) is unrealistic.
EHL
Demonstrably false.
is unrealistic.
>
So we now have two opposing assertions with the same amount of ux data
provided for each.
By the way, at AOL for years they believed nobody would understand
more than a simple 'screen name'. Then they believed nobody would
understand using a full email address to log in. These fears proved
unfounded. Grandma gets it.
You must be joking. Of course you are not confused by your *email address* showing at the top of your *email program*! There is nothing out of context there. But how should the NYTime welcome a user using their Twitter account to log into the site?
The only way Grama will be able to grasp “blaine...@twitter.com” is if it was actually an email account. Why? Because what else could it be?! Ask anyone you want, it *is* an email address.
I agree 100% with Dan's and John's statements here.
Dan's suggestion here is exactly what I was getting at when suggesting
that Twitter could add Webfinger support without necessarily adding
email support.
It works in reverse, too – let's assume for a moment that in addition
to returning a message that says "this is not the email account you're
looking for", Twitter is able to identify friends of the addressed.
For example, b...@example.com is friends with sa...@example.com. Sally
sends an email to bobex...@twitter.com, and Twitter replies "Oh,
sorry! This isn't an email address. But, you can contact bob at his
canonical address of b...@example.com."
That same approach can be applied to an "authenticated webfinger
lookup" (/me waves hands, but only slightly).
b.
(I'll try this from another direction. I'm not trying to abolish the 'acct' URI, just better understand the collective wisdom, since clearly the lack of clarity on this has created a bunch of different expectations.)
- Does the format have to look like an email address? This identifier should never appear in front of a user. At the same time, many services use email addresses as the local identifier (Facebook, Google, etc.). The current syntax is strongly biased towards email providers. Its format also makes it more likely to find its way in front of users. Why not acct://twitter.com/hueniverse (for example)? Remember, this is an internal identifier.
- Profile pages work because there is a single way to interact with them (getting an HTML page and showing the human reader). How should client interact with 'acct' URIs in the context of human interaction? The less this is defined, the more confusing it will be for users.
I honestly don't care what they look like, improbable as that may
sound. I want something that works.
Remember when another, totally different, unnamed gigantic social
networking site added support for the x.y/z format[1]? Yeah, me
neither.
b.
[1] http://techcrunch.com/2009/06/09/you-have-three-days-to-pick-your-facebook-vanity-url/
How do you feel about allowing both formats (@ and /) since they are trivial to detect and convert?
EHL
From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Brad Fitzpatrick
Sent: Friday, May 28, 2010 11:43 AM
To: webf...@googlegroups.com
Subject: Re: 'acct' URI survey
Replying to this survey late, as I was out yesterday, but...
Hey, slow down! that's a big leap. Forwarding was mentioned as one
possible scenario, but my original proposal was careful to say that
making the identifier email-capable could be as basic as having a
'vacation message'-style responder saying "this is not the email
address you're looking for. Many people have multiple email accounts
for multiple purposes. Some maintain a work / non-work distinction, or
a webmail / pop distinction, or just accumulate a collection over time
as they come free with various services. Having another potentially
emailable address as a side effect isn't too complex a concept to
communicate. And even if it is effectively de-activated in many cases,
they would still be email-ish enough to count as email accounts rather
than "something completely different but identified with email-style
IDs".
> Given that WebFinger ids are
> going to be useful in a wide variety of situations other than email, this
> means that the more I use WebFinger, the more susceptible I am to email
> spam.
Only if your service provider or yourself configure mail send to the
webfinger ID to redirect it to your real acount. Only those folk with
robust spam filtering and whose real/main email addresses are public
would likely want this.
> The linkage between what will increasingly become my "name" on the
> Internet and the ability to send me unsolicited and unwanted mail is not a
> good one...
Agreed.
> Ideally, we'll see a move away from application specific names and an
> acceptance of globally useful names. Thus, in the ideal world, my "name" on
> Facebook, Twitter and Buzz would all be the same. I would be globally
> recognizable in a vast number of contexts yet exposing my identity in all
> these environments would not necessarily expose my email inbox as a side
> effect.
Yup. And ideally ownership/control of the dns names used would be more
widespread, but that's another matter.
> If we don't have globally useful names, and if the use of a name implies the
> presence of an inbox as a side-effect, then I'm going to be hesitant about
> using new services since they will be compelled to create
> "yet-another-inbox" for me.
Something being an email address does not guarantee that mail sent to
it will end up in a user-facing inbox.
For eg. dan...@w3.org is an email address; W3C are still good enough
to forward it to me, but at some point they'll probably stop. Unless
you consider /dev/null an inbox, even in the purely email world
(forgetting webfinger for a second) this doesn't follow.
Now how "bad" can an email service be before the ID stops counting as
a 'real' email address? I don't know. It's kind of an angels/pinheads
question, but also a practical question to leave to implementors. The
main thing is that nothing in webfinger should depend on it being used
for email, or on SMTP-based services. But to users we can explain it
as a special extra email address that's only used for [explanation of
webfinger etc goes here].
> I wonder what the implication might be of having lots of email inboxes lying
> around that I don't use. Whether or not it is the case today, I think it
> doesn't take too much imagination to see that in the future (near or far)
> sending an email will probably be considered a legal form of "adequate
> notification" for a variety of purposes.
The more people online and sending emails, the less plausible it is
that any mortal human can keep up with their inboxes.
> (Remember, the standards we make
> today must/will last for a long time.) Thus, we're likely to see that the
> resistance to inbox proliferation which exists today simply because of
> nuisance issues (need to maintain forwarding, etc.) will one day be
> strengthened by legal concerns.
The reminder of long-term impact of standards is fair enough. I'm not
buying the other argument, but since we're already talking past each
other somewhat (nobody says this needs to be a real user-facing email
account, just emailable) I don't see an issue here. It's
not-being-their-main-inbox-ness could always be made explicit via
webfinger anyway, so the legally minded didn't accidentally send
things into a black hole.
> Today's email "forwarding" system is completely broken. While it often
> works, the problem is that creating an email account establishes an
> essentially permanent relationship between an addressee and an email
> provider (i.e. lock-in) and creates tremendous resistance to mobility.
Yup. I think we'll only see progress on that when domain name
ownership and management becomes a more user-friendly business.
cheers,
Dan
I don't think anyone's insisting that everything that looks like an
email address is or must be an email address; just that, for now,
users will be more comfortable with using addresses that ARE email
addresses.
Keep in mind that spam is largely enabled by the fact that the
deployed infrastructure of SMTP servers has no reliable way of
establishing the identity of a sender. Exhibit 1:
_spf.google.com descriptive text "v=spf1 ip4:216.239.32.0/19
ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18
ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16
ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all"
Google's SPF record has, at the end, "?all", which means "Ignore all
that spam prevention stuff you just parsed, basically it's meaningless
because anyone could be sending email with this from address."
With an LRDD infrastructure, we get DNS for People. Which means we get
SPF and DomainKeys for people. Which means we can drop messages with
forged headers. It also means we can reliably move to whitelist-based
systems (which we've already done, essentially - facebook and twitter
are both whitelist-based systems).
We can also augment SMTP systems to authenticate the *user*, rather
than the *server*. So I see this sort of discoverability as a net win
for email.
b.
Pick one. This fucking bullshit in specifications giving users and
developers the choice is retarded.
http://37signals.com/svn/posts/2335-the-art-of-taking-things-away
How are we going to explain to users "well, you can use @ or /, so
your twitter address is either bob/twitter.com or b...@twitter.com,
y'know, take your pick."?
Seriously, this stuff matters.
It's about cognitive psychology, not ease of parsing.
It's about linguistics and pattern recognition, not purity of the holy
altar of the URI.
Pick one and be done with it. But do so knowing that "x@y.z" is a
widely-recognised format that is parsed as "person @ brand" – "y.z/x"
is a virtually never-used format that is parsed as "brand". If you're
dealing with someone really smart, it's parsed as "brand with some
shit at the end".
To clarify my point on this:
- I *don't* care what the identifier looks like.
- I *do* care that the identifier is successful.
- I have not seen *any* proposals that are not problematic in some way.
- Email-like identifiers are, in my opinion for the reasons stated
above, the least problematic.
- We need to pick ONE. Users will not adopt MANY.
b.
While I don't think this is a major consideration for the use-case at
hand, I just wanted to draw attention to the fact that example.com/foo
and f...@example.com are both valid XMPP identifiers, as is
f...@example.com/bar.
Since the focus for acct: is identifying people, and the example.com and
example.com/foo forms are generally for addressing bits of software,
this is probably okay.
Just to clarify here, xmpp:example.com/foo != xmpp:f...@example.com
xmpp:example.com/foo means "the temporary resource or connection
instance 'foo' associated with the bare JID at host 'example.com'"
xmpp:f...@example.com means "the user 'foo' at host 'example.com'"
xmpp:f...@example.com/bar means "the temporary resource or connection
instance 'bar' associated with the user 'foo' at host 'example.com'"
> Since the focus for acct: is identifying people, and the example.com and
> example.com/foo forms are generally for addressing bits of software, this is
> probably okay.
The XMPP people would hunt down anyone who started promoting
"example.com/foo" as an identifier for a person. You *could* do it
[with heavy modification of existing xmpp servers], it would work, but
it would [severely] break their security and permissions model. No
XMPP client would be able to log in a server that did such things,
though.
b.
Federated cross-domain mentions using Webfinger was, for me, the most
inspiring part of the social web talks I saw at Google I/O. If we
need to start blurring the one-to-one relationship between @ symbols
and email addresses, so be it. I would strongly recommend we also not
ask Webfinger providers to support SMTP, even for an auto-responder
functionality, if only so that the barrier to participating in our
utopian federated social web vision is as low as possible.
-- Eric
And I'm clearly not being clear. Let's try to fix that.
> Can you say a bit more about what it means to have an email address that is
> "emailable" but that isn't a "real user-facing email?" What are the
> attributes of an "emailable" email account? How is such an account different
> from an "real user-facing email account?"
It's emailable in the sense that you can connect and send stuff via SMTP.
The idea of having multiple email addresses is not new or strange.
Even multiple addresses from the same higher-level user account. The
idea of email addresses being configured as 'disabled' / 'bounce
everything' / 'send everything straight to trash' is not particularly
hard for users to grasp.
So all I'm saying is that we don't need to say mysteriously to users
"Webfinger IDs look like email addresses, but they aren't really,
they're something different". We just say "Webfinger IDs are a special
kind of email address that are designed just to use as identifiers;
they don't replace your main email address, since you may want to keep
those private".
This is mostly spin / narrative, and in practice if a provider didn't
turn on SMTP nothing would break since Webfinger ignores it. But it
allows us to replace an "it's like an email but it isn't an email"
explanation with "it's an extra email address". I think there are some
interesting ways in which this kind of social Web infrastructure could
help fix the email / spam situation (Blaine touched on some of that),
and the approach I'm suggesting would leave the door nicely open for
such things, without requiring them.
>> we'll only see progress on that when
>> domain name ownership and management
>> becomes a more user-friendly business.
> One of the reasons I *really* like WebFinger is that it will, in fact,
> provide much of the benefit that we might get from a more user-friendly
> system of domain name ownership and management... As Blaine suggests in
> another email, WebFinger + Friends can be seen as a form of "DNS for
> People." What am I missing? Why do we need to modify DNS if we can
> accomplish, one level lower, much the same via WebFinger, etc.?
I'd rather be dan...@danbri.org than dan...@twitter.com or
@facebook.com, even if I love those services. If I don't buy and
manage my own domain, I end up entangled with services that might go
bad in a few years. I can't see how to avoid DNS there...
cheers,
Dan
I also recommend an SMTP reject with a Webfinger advertisement in it
for people who don't want their IDs to be emailable. I volunteer to
set up a cloud service anyone can point an MX record at.
On Friday, May 28, 2010, Bob Wyman <b...@wyman.us> wrote:
> Dan Brickley <dan...@danbri.org> wrote:> This is mostly spin / narrative, and in
>> practice if a provider didn't turn on SMTP> nothing would break since Webfinger ignores
> What displeases me is the suggestion that if I were to provide a WebFinger service to all "Wyman"s in the US, I would have to provide SMTP service and/or mail forwarding for all of those people. I can't afford it and don't want the hassle of running such a service. I'd rather just host the profiles and XRDs that could be used to discover Wyman's actual email addresses. But, if you're saying that it is "ok" to have SMTP turned off or disabled, then I think we have no conflict. It is just spin. Sometimes an id is useful as an email address and sometimes it isn't.
>
>> I'd rather be dan...@danbri.org than dan...@twitter.com <dan...@twitter.com>> or @facebook.com, even if I love those services. If I don't
>> buy and manage my own domain, I end up entangled> with services that might go bad in a few years.Too bad your last name isn't "Wyman"... If it was, I'd be able to offer you a nice, service-independent WebFinger/OpenId solution...
--
Would the response be flatly identical across the service, or custom per ID?
(I kind of like idea of XHTML+RDFa emailed responses, but won't push
that for now)
> I volunteer to set up a cloud service anyone can point an MX record at.
Great :)
Do you have any sense for the volume of spam you'd have to deal with
with, and what level of commitment it's feasible to take on?
cheers,
Dan
cheers,
Dan