Re: Finding user profiles on a Social Net

Hi Melvin

There's two problems to be solved.

1. How to find the responsible server for a domain's social network. (Which
server runs the social network functions for EXAMPLE.COM?)
2. How clients find their API endpoint (user@EXAMPLE.COM is trying to
log-in on a new mobile-social-app, what API endpoint do I use for
EXAMPLE.COM)

The first problem is solved using SRV records or webfinger or whatever

The second problem is solved using DNS-SD. The lookup is "magically"
simple. In buddycloud's case the mobile client will do the following query:

dig -t TXT _buddycloud-api._tcp.EXAMPLE.COM. +short

and get back the following easily parseable content:

"v=1.0" "host=demo.buddycloud.org" "protocol=https" "path=/api" "port=443"

To make this work you just need to add something like the following to your
zone file.
_buddycloud-api._tcp.EXAMPLE.COM. IN TXT "v=1.0" "host=
buddycloud.EXAMPLE.COM" "protocol=https" "path=/api" "port=443"

So for your app, just change _buddycloud-api to whatever you would
like (and if you are creating new protocols, be nice and register them with
IANA).

S.


On 11 June 2013 12:13, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

>
>
>
> On 6 June 2013 16:41, Simon Tennant <simon@buddycloud.com> wrote:
>
>> I generally dislike /.well-known because it makes lots of assumptions
>> about the web-root being available.
>>
>> Three problems with this:
>> 1.  Others might run hosted personal pages like those hosted on about.me.
>> For example my sister runs a hosted store on her domain. Short of getting
>> the eCommerce provider to change their code, she would never be able to
>> implement anything social.
>>
>> 2.Often times an organization will have their web-root maintained by
>> another company. Page updates could easily overwrite a nice /.well-known
>> hierachy.
>>
>> 3. I don't know the answer to this, but how long should /.well-known be
>> considered authoritative? What kind of refresh interval?
>>
>> When you start thinking about it, this is all a hack to accomplish what
>> DNS already does. DNS-SD has already solved this, and has caching, and with
>> zone signing, authority.
>>
>
> Hi Simon, I got a reply from stuart re this:
>
> "DNS-SD is not magical. It really just does one simple thing -- where a
> user would have to type in an IP address, instead they can select from a
> list. So if you have something where today the users would have to set it
> up by typing in addresses, then DNS-SD can simplify that step."
>
> It's quite interesting.  I'm still trying to get my head around how this
> could be used, though ... :)
>
>
>>
>> S.
>>
>>
>>
>>
>> On 6 June 2013 16:22, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>>
>>> I was thinking about the issue of finding user profiles on a social net,
>>> and it's not always easy to know where a user's data will be located.
>>> There seems to be no well known place to get user information from a
>>> profile.  Which means it's harder for HTTP based social web users to talk
>>> to each other.
>>>
>>> One increasingly popular method is to use the /.well-known/ directory.
>>> The disadvantage of this approach is that is it pretty rigid and people say
>>> it amounts out of band hard coding.  However one advantage is that it can
>>> save a round trip, compared with follow your nose, and it can client
>>> implementations more straight forward.
>>>
>>> Taking the well known directory a logical pattern might be to register:
>>> *
>>> *
>>> */.well-known/user/bob*
>>>
>>> For the FSW?
>>>
>>>
>>> *Would it allow redirects* -- I would say yes.
>>>
>>> *What would it return* -- I would suggest linked data.  Ideally a
>>> browser would see html and an ajax request would see JSON, but you could
>>> start with just one of the two, say JSON only.
>>>
>>>
>>> Good idea / bad idea / too hard to implement ... thoughts?
>>>
>>
>>
>>
>> --
>> Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
>> goo.gl/tQgxP
>>
>
>


-- 
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
goo.gl/tQgxP