Single user domains discovery
Laurent Eschenauer
Tantek Çelik
<laurent.e...@gmail.com> wrote:
> Hi all,
> Looking for feedback on another detail in the flow: since Tantek has his own
> domain name (I'm in the same situation with @eschnou.com), it seems strange
> for Dave to tag the picture with @t...@tantek.com, he would rather tag it with
> @tantek.com only. Resulting in an "acct:tantek.com" in the salmon link. This
> is what Tantek call 'supporting the indie web' and I like the term :-)
Viva la indie web!
> But then.. what happens with discovery of the salmon endpoint? We currently
> have two proposals on the wiki:
> http://federatedsocialweb.net/wiki/SWAT0_-_strawman_protocol_flow#2._Dave_tags_the_photo_with_Tantek
> 1. Tantek's approach is to use hcard for domain only identifier, and
> webfinger for the others:
> @tantek.com -> http://tantek.com/ -> representative hCard discovery ->
> display name "Tantek Çelik" etc.
> @tantek: I do not see how you discover the salmon endpoint in this case. You
> add a <a rel="salmon" href="..."> in the hcard ?
Short answer:
representative hCard == page is the person, perform any/all page-level
discovery.
Once you find that a page has a representative hCard, you know the
page represents that person.
Thus all head link rels apply etc.
In my case, I already have this on the page:
<link rel="hub" href="http://pubsubhubbub.appspot.com/"/>
and can easily add another such link rel for Salmon once I have Salmon
figured out (assuming it's necessary for the use case).
> 2. I proposed to use webfinger for everything, and make sure that if the
> domain is a single user domain, the host-meta document already contains the
> various user links (no LRDD link in this case).
> Any thoughts ? What do the webfinger guru thinks on this ?
In general, I have found WebFinger too complex for simple/easy/indie cases.
Thus so far I have rejected "use webfinger for everything" and instead prefer:
* use the domain itself with simple microformats and link rels
* else if nothing found, then fallback to webfinger / host-meta / XRD
/ LRDD et al.
I realize this biases for the indie-web, but I think that's the right
bias to have.
Thanks,
Tantek
indie-web first, oligarchies second.
--
http://tantek.com/
I made an HTML5 tutorial video/book! http://tantek.com/html5
SocialRiver Team
On 07/23/2010 01:58 PM, Laurent Eschenauer wrote:
> Hi all,
>
> Looking for feedback on another detail in the flow: since Tantek has his
> own domain name (I'm in the same situation with @eschnou.com
> <http://eschnou.com>), it seems strange for Dave to tag the picture with
> @t...@tantek.com <mailto:t...@tantek.com>, he would rather tag it with
> @tantek.com <http://tantek.com> only. Resulting in an "acct:tantek.com
> <http://tantek.com>" in the salmon link. This is what Tantek call
> 'supporting the indie web' and I like the term :-)
That won't always work because most people don't have their own domain -
there needs to be an account identifier associated with the domain to
keep the mechanism uniform and reliable. Or at least that's my perspective.
Scott
Blaine Cook
> Looking for feedback on another detail in the flow: since Tantek has his own
> domain name (I'm in the same situation with @eschnou.com), it seems strange
> for Dave to tag the picture with @t...@tantek.com, he would rather tag it with
> @tantek.com only. Resulting in an "acct:tantek.com" in the salmon link. This
> is what Tantek call 'supporting the indie web' and I like the term :-)
No offense, but I hate this idea. :-)
I'm sorry I sound like a broken record on this, but I really do think
that it's important. Two core reasons that we should use email-like
addresses is because they are simple AND consistent.
There is an important train of thought in design circles that suggests
that *fewer* choices often lead to *better* experiences. Here's Aza
Raskin on the subject:
http://www.shmula.com/408/humane-interface-ask-aza-raskin-anything -
many more references can be found.
When we're talking about this behaviour, we need to be thinking about
what the user is doing, which is what Laurent is doing here, and by
providing two paths, we create complexity for the user. For example:
Add A Friend: __________________ [ Add Them! ]
What should a user enter there? Is it a URL? A bare domain? A name? An
email address?
- What is the answer that gives the user the least chance of getting
the wrong thing?
- What is the answer that is most predictable for users?
- What is the answer that most closely represents what people already
do on the web?
Now, I agree with Tantek – *IF* we could convince everyone to just use
domains, this would all be simpler - we would have short, globally
routable names. We'd get more TLDs to deal with namespace pollution,
and everyone would *own* their own identifier, no question.
BUT, that's simply not going to happen. There is no way that my mother
will EVER have her own domain, unless the following things change:
1. Domains must not cost anything.
2. Domains must not expire annually.
3. The domain registration process must be drastically simplified.
4. The business of squatters must be drastically reduced.
5. End-users must be able to manage their own SSL certificates.
6. End-users must be able to easily delegate control of their DNS and
hosting services to third parties.
Basically *none* of those things has any hope of changing in the
5-year view of things, possibly much longer, and since *all* of those
things need to change for domains to be a viable option for end-users,
I just don't see it happening, so I reluctantly decline to support
this vision of the "indie web".
Furthermore, webfinger comes under constant criticism because it's
currently unlikely that Facebook and Twitter will deploy support for
it. Now, it's *way* more likely that facebook would adopt a
username-based naming scheme (whether facebook.com/user, which they
already support, or us...@facebook.com, which they *could* support, but
don't have plans to currently) than for facebook to allow their users
to host their own personal domains with facebook.
We need an indie web that's compatible with the corporate web. I'm
totally committed to the indie web, but I also strongly value the fact
that I don't have to spend my time fucking around with servers to host
my own content. Any future of the web needs to take that into account
– "cloud" is a load of shit, except that it actually reflects
something that's happening, and not stopping anytime soon.
> But then.. what happens with discovery of the salmon endpoint? We currently
> have two proposals on the wiki:
> http://federatedsocialweb.net/wiki/SWAT0_-_strawman_protocol_flow#2._Dave_tags_the_photo_with_Tantek
> 1. Tantek's approach is to use hcard for domain only identifier, and
> webfinger for the others:
> @tantek.com -> http://tantek.com/ -> representative hCard discovery ->
> display name "Tantek Çelik" etc.
> @tantek: I do not see how you discover the salmon endpoint in this case. You
> add a <a rel="salmon" href="..."> in the hcard ?
> 2. I proposed to use webfinger for everything, and make sure that if the
> domain is a single user domain, the host-meta document already contains the
> various user links (no LRDD link in this case).
> Any thoughts ? What do the webfinger guru thinks on this ?
To answer the actual question: ;-)
I think that valid addresses should always be in the form
"us...@domain.com". To get around the syntax-ugliness of
"@t...@tantek.com" (which is absolutely ugly), we should promote these
two alternatives:
"t...@tantek.com <message>"
OR
"@t <message>"
where "t" is a local alias for the user "t...@tantek.com". Perhaps
there's an opportunity to encode "preferred nicknames" in webfinger
profiles, so that when users add their friends in new networks, they
can refer to them by their friends' preferred nicknames, rather than
having to come up with new nicknames for each of their friends (unless
they want to... ;-) ).
Having written the parser for the original @-reply code, I can safely
say that the first variant is trivial to parse correctly, and will be
understood as an @-reply. The @-reply syntax is only required on input
on limited devices – once you have a "real" data-interchange format
(whether it's a rich UI, or an Atom stream), the reply-ness is encoded
as side-band data, and the formatting becomes irrelevant (for example,
if my alias for "t...@tantek.com" is "tantek", and your alias for
"t...@tantek.com" is "t", when I "@tantek", you should see "@t".
b.
bear
> On 23 July 2010 20:58, Laurent Eschenauer <laurent.e...@gmail.com> wrote:
>> Looking for feedback on another detail in the flow: since Tantek has his own
>> domain name (I'm in the same situation with @eschnou.com), it seems strange
>> for Dave to tag the picture with @t...@tantek.com, he would rather tag it with
>> @tantek.com only. Resulting in an "acct:tantek.com" in the salmon link. This
>> is what Tantek call 'supporting the indie web' and I like the term :-)
>
> No offense, but I hate this idea. :-)
As do I. If someone wants the can map "m...@tantek.com" or
"*@tantek.com" to the appropriate person, but like Blaine says below,
it should always be us...@tld.com as that is the simplest, most common
used and easiest way to describe a single person we have now.
just as the most common user interface for html hides the
http://foo.com/blah when presented with an anchor tag and insteads
shows the title or alt-text, so should our next generation social web
apps present "Tantek" when presented with t...@tantek.com!foo#blah or
whatever other constructed method ends up being used to identify
someone.
>
> b.
>
yes, i'm basically saying "+1" to what Blaine said :)
--
Bear
be...@xmpp.org (email)
bea...@gmail.com (xmpp, email)
be...@code-bear.com (xmpp, email)
http://code-bear.com/bearlog (weblog)
PGP Fingerprint = 9996 719F 973D B11B E111 D770 9331 E822 40B3 CD29
Tantek Çelik
> On 23 July 2010 20:58, Laurent Eschenauer <laurent.e...@gmail.com> wrote:
>> Looking for feedback on another detail in the flow: since Tantek has his own
>> domain name (I'm in the same situation with @eschnou.com), it seems strange
>> for Dave to tag the picture with @t...@tantek.com, he would rather tag it with
>> @tantek.com only. Resulting in an "acct:tantek.com" in the salmon link. This
>> is what Tantek call 'supporting the indie web' and I like the term :-)
>
> No offense, but I hate this idea. :-)
No offense, but I don't care that you hate the idea, I'm coding it anyway. :)
And I'm not the only one.
> I'm sorry I sound like a broken record on this, but I really do think
> that it's important. Two core reasons that we should use email-like
> addresses is because they are simple AND consistent.
Today's email clients don't force people to type in email addresses
(your idea of simple AND consistent).
Every modern email client (dare you to name an exception) gives the
user the CHOICE:
* start typing a person's display name, autocompleting to a name
(*sometimes* showing the underlying address)
* directly type in an email address
They used to only allow:
* directly type in an email address
So you're just plain empirically wrong with your assertion of "simple
and consistent" and forcing/saddling everyone with a "must type in
something that looks like an email address" mindset.
> There is an important train of thought in design circles that suggests
> that *fewer* choices often lead to *better* experiences. Here's Aza
> Raskin on the subject:
> http://www.shmula.com/408/humane-interface-ask-aza-raskin-anything
You're right about *items* in a *menu* which is what Aza is talking about.
You're wrong about natural language like UIs which involve typing
something in, for those, more
flexibility/forgiveness/autocompleting/inferring = better.
Just as people are ok with typing in shorter email addresses, people
are ok with shortening all the way to the domain.
> When we're talking about this behaviour, we need to be thinking about
> what the user is doing, which is what Laurent is doing here, and by
> providing two paths, we create complexity for the user. For example:
>
> Add A Friend: __________________ [ Add Them! ]
>
> What should a user enter there? Is it a URL? A bare domain? A name? An
> email address?
The answer is: yes.
And the evolution of today's UIs prove it.
To today's users, text box = search/autocomplete.
They expect to be able to type anything meaningful in and get
something that works.
Go ahead and implement with email-address-only syntax blinders.
I'm going to implement with name (lookup in local contacts), domain,
domain user, and email-like IDs.
We'll see which the users accept as more usable.
> Now, I agree with Tantek – *IF* we could convince everyone to just use
> domains, this would all be simpler
No, that's not my point, that's a straw-man misrepresentation of my point. :)
The point is, for those that *do* choose to use domains, let's keep it
simple and not force additional complexity or syntactic vinegar upon
them.
> I just don't see it happening, so I reluctantly decline to support
> this vision of the "indie web".
Fine, there's plenty of folks that want to support it that we'll
implement it regardless.
> Furthermore, webfinger comes under constant criticism because it's
> currently unlikely that Facebook and Twitter will deploy support for
> it.
No, it comes under constant criticism because it is "too geeky"
(email-address syntax blinders, nevermind the dependencies on special
directories and XML side-files).
http://twitter.com/timoreilly/statuses/12762778906
Oh and since you brought up support, let's take your examples of
Facebook and Twitter:
* both support rel-me to a personal URL
* both support hCard profiles
So how about we build upon what open *web* standards *are* getting
adoption, in large sites and small indie sites, rather than
brainstorming new hand-waving out of a misplaced sense of nostalgia
for us...@example.com, and a misinterpretation of what "choice" means
in user experience design?
> Now, it's *way* more likely that facebook would adopt a
> username-based naming scheme (whether facebook.com/user, which they
> already support, or us...@facebook.com, which they *could* support, but
> don't have plans to currently) than for facebook to allow their users
> to host their own personal domains with facebook.
Great. So let's accept input of the form facebook.com/user then. Done.
Works today.
> We need an indie web that's compatible with the corporate web.
Backwards.
We'll build/grow the indie-web, and the corporate web will have
sufficient profit motive to become compatible with it. Just as AOL
added support (later) for interop with "internet mail".
Not worried about it. And not worried about putting the corporate web second.
> I'm
> totally committed to the indie web, but I also strongly value the fact
> that I don't have to spend my time fucking around with servers to host
> my own content.
I don't want to be a server admin either. Nor database admin. It's
why I gave up on WordPress for my own site. And why I politely
decline to use Statusnet on my server.
But I (and every web designer/developer I know) can handle copying
files. FTP. Even scp.
That's the minimum bar I'm using for Falcon.
And since you brought up mothers, my mother can/does upload files to a
web server.
So no Blaine, I don't believe you when you say you are committed to
the indie web when you make the indie web use-case a second class
afterthought at best.
Indie web = domain-only identifiers are first class and preferred in the design.
Tantek
indie web first, oligarchies second
bear
> On Fri, Jul 23, 2010 at 5:41 PM, Blaine Cook <rom...@gmail.com> wrote:
>> On 23 July 2010 20:58, Laurent Eschenauer <laurent.e...@gmail.com> wrote:
>>> Looking for feedback on another detail in the flow: since Tantek has his own
>>> domain name (I'm in the same situation with @eschnou.com), it seems strange
>>> for Dave to tag the picture with @t...@tantek.com, he would rather tag it with
>>> @tantek.com only. Resulting in an "acct:tantek.com" in the salmon link. This
>>> is what Tantek call 'supporting the indie web' and I like the term :-)
>>
>> No offense, but I hate this idea. :-)
>
> No offense, but I don't care that you hate the idea, I'm coding it anyway. :)
>
> And I'm not the only one.
When I replied earlier I thought the discussion was what format to
present within the protocol/wire view, not how to present it to the
user.
Are you talking about using that for the wire or only the UX?
(and please do say "google the archive" if i'm re-hashing old arguments :) )
Markus Sabadello
No seriously, isn't it as simple as saying both URIs and email addresses are supported in the "indie web"?
- If URI -> LRDD
- If E-Mail address -> Webfinger
So different social networks could choose what identifiers to issue to their users, they just need to support LRDD and Webfinger to talk to others.
This is pretty much what I had been assuming since the summit..
(And the i-name maniacs among us can still hack their way into the "indie web" by using something like http://xri.net/=markus, which of course has the advantage that your identifier is fully portable and bound to a non-reassignable i-number blablabla ok I stop now).
Markus (of the Personal Data Store Project..)
--
blog: http://danubechannel.com
phone: +43 664 3154848
Markus Sabadello
> * else if nothing found, then fallback to webfinger / host-meta / XRD / LRDD et al.
Markus
Laurent Eschenauer
On 23 July 2010 20:58, Laurent Eschenauer <laurent.e...@gmail.com> wrote:No offense, but I hate this idea. :-)
> Looking for feedback on another detail in the flow: since Tantek has his own
> domain name (I'm in the same situation with @eschnou.com), it seems strange
> for Dave to tag the picture with @t...@tantek.com, he would rather tag it with
> @tantek.com only. Resulting in an "acct:tantek.com" in the salmon link. This
> is what Tantek call 'supporting the indie web' and I like the term :-)
I'm sorry I sound like a broken record on this, but I really do think
that it's important. Two core reasons that we should use email-like
addresses is because they are simple AND consistent.
BUT, that's simply not going to happen. There is no way that my mother
will EVER have her own domain, unless the following things change:
To get around the syntax-ugliness of
"@t...@tantek.com" (which is absolutely ugly), we should promote these
two alternatives:
[edited]
Mike (DFRN)
just use LRDD.
First thing I'm going to do when I grab a locator is look for an @ and
split off the LHS and run webfinger. If the LHS is empty I'm going to
assume you're an idiot or a hacker and I'll spit out a stupid error
message and send you on your merry way - but without whatever you came
for. It's OK to have a location (tantek.com) instead of an email-style
address. I can live with that. But if it''s got an '@', there better
be a person on the LHS.
As for post @ tags, '@Full Name'. We're communicating with humans. You
can link to locators/profiles behind the scenes so the machines can
talk their own language. Probably need a local nickname override or a
unique locator in a title hover in case you know more than three Bill
Smiths, but that's just a simple matter of programming.
Peter Saint-Andre
> Problem is, most of the guys around here coding this thing, have their
> own domain name. They want this to work for them as well, and not look
> like a presumptuous idiots with something like "m...@eschnou.com"
> or "esc...@eschnou.com".
>
> So... now that we agreed (and we always did I think) on how to solve the
> problem for 99.9999% of the world (email + webfinger), what solution can
> we find for the few lost souls like me... who love so much their domain :-)
Why do we care about .0001% of the world, even if they are cool indie
web folks? (So much for the 80/20 rule, now we're down to the 99/1 rule
or worse.) And don't you guys have email addresses at your domains? Mine
is stp...@stpeter.im, yours might be m...@eshnou.com, etc. Special casing
for .0001% seems utterly unnecessary.
Peter
--
Peter Saint-Andre
https://stpeter.im/
Laurent Eschenauer
Mark Smith
> implementers (status.net, diaspora, etc..). What are you implementing today
> and why ?
In my experience with users, they almost always see URLs as "things"
and emails as "people".
For Dreamwidth, I don't want users to have to try to refer to their
friends by some URL. It's hard to figure out exactly which URL to use
for most people, but almost everybody understands email addresses.
WebFinger seems reasonably straightforward for our usage. Every user
has a unique username, so their email is either "us...@dreamwidth.org"
or if the user chooses to be discoverable by their actual email
address, "what...@whatever.com" would redirect to their account
appropriately.
--
Mark Smith / xb95
ma...@dreamwidth.org
Drummond Reed
1) In June 2004 OASIS XRI TC put out a paper called The Social Web that proposed using XRIs as as way of unifying and mapping all other types of identifiers (email addresses, URIs, phone numbers, etc.) as social web identifiers.
2) In 2005, OpenID 2.0 merged support for both URLs and XRIs using XRDS discovery, and the debate began about supporting email addresses.
3) In 2006, the debate continued to rage in the OpenID community about supporting email addresses.
3) In 2007, the debate continued to rage in the OpenID community about supporting email addresses.
3) In 2008, the debate continued to rage in the OpenID community about supporting email addresses.
3) In 2009, the OASIS XRI TC published XRD (the new, even-more-simplified version of XRDS), the open web community created Webfinger to provide support for (among other things) email addresses as discoverable identifiers, and the debate continued to rage in the OpenID community about supporting email addresses.
3) In 2010, the debate continued to rage in the OpenID community and spread to the federated social web community about supporting email addresses ;-)
********
Points being:
1) The debate about "what's the best form of address to support for a federated social web" will rage for many more years.
2) The debate can be largely overcome by one simple decision: adopt a common discovery format (XRD), and define discovery for each standard identifier type (email address, telephone number, URI, XRI) using that format.
3) Those of us who have learned the hard way that social web links MUST for security and privacy reasons be based on persistent, non-recyclabe identifiers (to which recyclable identifiers like email addresses, phone numbers, 99.9% of URLs, or reassignable XRI i-names are mapped), will be able to build those solutions in complete harmony with those who choose to run the risks of using recyclable identifiers for everything.
If folks on this list are not up to speed with the identifier recycling issue, just google "OpenID identifier recycling" and start reading the 317,000 results.
Seriously, this issue has been pounded to death in the OpenID community. The last thing I'd like to see is for the last five years of debate there to be rehashed for another five years here.
=Drummond
James Walker
<laurent.e...@gmail.com> wrote:
> Thanks all for the feedback. It would be nice to hear from other
> implementers (status.net, diaspora, etc..). What are you implementing today
> and why ?
We (status.net) have implemented both webfinger identifiers
(f...@status.net) *as well as* URLs (which should work). The reason?
StatusNet is a free download, runs on dreamhost, PHP + MySQL package.
We want anyone with some webspace (i.e. cheap hosting) to be able to
run our software.
This means (potentially) - they will not have access to
http://example.com/.well-known/host-meta. If you can not write /
control the top level directories of your webhost - you can't use
webfinger. period. So - for us http://example.com/statusnet/user needs
to be an acceptable identifier.
Sure, I believe (personally) that webfinger (aka email-like)
identifiers make more sense to people (because they're well-formed -
user @ host), but at the end of the day I believe that a "person" has
several identifiers - and they should be able to use (and software
should accommodate) whatever feels comfortable / works for them.
Discovery *should* be about finding info / capabilities about a user.
FYI - host-meta discovery should totally work with http://tantek.com/
in my reading of the spec.
> My (attempt) at summarizing the feedback and the sentiment of the 'majority'
> (at least of the voices expressed here):
> Identifiers should be in the form user@domain (and no 0 length left hand
> side). The discovery is done using webfinger. The main reason that we are
> using email like identifiers is that it is simple and consistent. This is a
> user experience driven decision.
> If an implementor would also like to support lookup on domain or URL, the
> proposed approach is using hcard (or should it be LRDD on the URL ? Or is
> that in fact equivalent ?). They should however be aware of the potential
> user experience impact and that the majority of implementers today are using
> email like identifiers.
> Please keep feedback and ideas coming, I'll try to summarize it in the
> wiki.
> Cheers,
> Laurent
--
James Walker :: http://walkah.net/ :: http://james.status.net/
Martin Atkins
It's often asserted that users see email addresses as for people and
URLs as for companies and other things. (It is unfortunate that email
seems to have become essentially a one-way channel where companies are
free to email you all the junk they want, but they always do it from
blackhole email accounts that prevent you from emailing them. But I
digress.)
With this in mind, I wonder if it makes sense to support bare domains
primarily for representing companies and other non-person websites.
If I want to follow, say, the latest activity from Apple, might I follow
apple.com or instead figure out that I have to follow ne...@apple.com?
Supporting bare domains for companies does of course open the door to
certain individuals deciding that they want to have bare domains too;
any usability difficulties that follow are of course down to them.
On 07/25/2010 10:32 AM, Laurent Eschenauer wrote:
> Thanks all for the feedback. It would be nice to hear from other
> implementers (status.net <http://status.net>, diaspora, etc..). What are
Blaine Cook
>
> It's often asserted that users see email addresses as for people and URLs as
> for companies and other things. (It is unfortunate that email seems to have
> become essentially a one-way channel where companies are free to email you
> all the junk they want, but they always do it from blackhole email accounts
> that prevent you from emailing them. But I digress.)
>
> With this in mind, I wonder if it makes sense to support bare domains
> primarily for representing companies and other non-person websites.
>
> If I want to follow, say, the latest activity from Apple, might I follow
> apple.com or instead figure out that I have to follow ne...@apple.com?
>
> Supporting bare domains for companies does of course open the door to
> certain individuals deciding that they want to have bare domains too; any
> usability difficulties that follow are of course down to them.
I was also thinking about this thanks to this thread – I completely
agree; this is a use-case that I think provides a compelling reason to
support bare-domain addressing as well as email-style addressing, so
yay, I for one welcome our new bare-host-address overlords. *hell
freezes over*
b.
ps: I also welcome the new "host:" uri scheme :-p